Looking for advice on software architecture

JoK

Weaksauce
Joined
Feb 24, 2017
Messages
97
I am about to start developing a new desktop app and I am considering some options on how to build the design.

First, I am thinking of a typical standalone desktop app which handles everyhting.

Then, the other option is to build a client server app with the server running on the same machine as the client. At the moment there is no need to introduce a web based server but in the future (in fact in the very remote future) I may offer a web service. The downside of it I can see now is that I need to reserve a port on Windows and this may create issues when people install the app.

What I was thinking is to write a client-server app with the server embedded in the app itself (in-process server). This will allow for easy future migration.

I am not sure which approach to follow and I would like to hear some thoughts.

Thanks
 
What would need to be on a server to be accessed not in the app?
 
From what I am getting, if it's a stand alone app that just uses its own DB I don't think that needs to be pulled out into a server.

Sure keep in mind a potential webservice need in the future when you are creating your abstractions and classes to keep things loosely coupled, but if it's not a now-now thing I wouldn't go too far around the bush to accommodate something that may not happen.
 
From what I am getting, if it's a stand alone app that just uses its own DB I don't think that needs to be pulled out into a server.

Sure keep in mind a potential webservice need in the future when you are creating your abstractions and classes to keep things loosely coupled, but if it's not a now-now thing I wouldn't go too far around the bush to accommodate something that may not happen.
Yes it is a standalone app.

I always keep logic and UI separate as much as possible. I try to follow MVVM approach.

But I think you are right. Sounds like I am overly concerned about this given that it may not happen as you say
 
Several options come to mind here if i was going to QnD something simple: the React / Spring Boot, React/Redux implementation with Redux playing "service layer", or just pure React with some logical apportionment of to said 'front-end/back-end".

Either way, it is a good exercise in thought/design/implementation to keep best practices in play no matter how simple or complex your objective is.

As they say, train as how you'd fight
 
If you have a C# background, my vote is for Blazor. It checks all the boxes you mentioned. You can design it as a self-contained desktop app (Blazor PWA tech) and then later migrate everything to a proper client->server model (with security, authentication, etc.). Blazor is basically, an alternative to Electron. It has a relatively easy to use js interop layer, so you can reuse existing javascript libraries (if you must). You will be building a UI that uses modern web standards (HTML5, Bootstrap, etc.), so when you make the jump to actually running your client in a browser, it will practically be seamless. EntityFramework makes db design rather trivial, with much of the SQL abstracted away (less prone to bugs). SQLite support is, in my experience, excellent. But you can pick a different flavor for your db backend. Blazor is cutting edge (at least for MS) leaning heavily on .NET Core 3.1 (soon to be .NET 5).

But if you're not afraid of javascript, then the others already mentioned (React, Electron, etc.) aren't bad ways to go.
 
Last edited:
Back
Top