What's the correct way to provide same functionality for a desktop and a web application?

Question

I work on a GIS-based Network Inventory software. There are two versions of it available: a desktop and a web application.

Currently any feature must be implemented separately for desktop and web. The only common element of both systems is the database.
E.g. if I want to add an entry in the context menu for some type of map object, I need to do it in both codebases (along with whatever happens when that menu entry is interacted with).

I would like to define and implement a feature once for both applications in order to simplify maintenance. I could serialize a very high-level version of the implementation and store it in the database. On program startup I would fetch it from the database and deserialize it. The high-level instructions would still need to be implemented separately, but they could be reusable.

While I believe this could be a solution to my idea, I am worried it would simply change one kind maintenance hell to another. Furthermore, it could limit performance, because usage of high-level instructions might not allow for task-specific optimizations.

Should I be trying to pursue the goal of having a common implementation for both applications? What's a better design or approach for providing same functionality for both desktop and web applications which only share a database?

Answer 1

A good pattern to follow is to migrate code which doesn't involve any user interface into either a library, or web-services (if the desktop app will always be IP connected to where it can access the web services).

And then build the GUI using html. How the html-based application works for the web case doesn't need explanation. But in the case of the desktop app, there are a variety of good approaches (e.g. embed web-browser in the app and have it just run local web pages; use a toolkit designed to do that sort of thing like electron; but there are many variations on this).

This doesn't quite mean you write the GUI once. You will want to structure your html app slightly differently for a true web based delivery and in the desktop version. But they will be able share an overwhelming amount of code and keep feature-in-sync straight-forwardly. Supporting the 'desktop' version of your UI becomes almost like supporting Chrome and Firefox, and MSIE.

Answer 2

When you have the desktop application and web application providing the same functionality and they share only the database, there will be lot of duplication of code. So we need to change with the architecture a bit.

Step 1: The first step would I would prefer is make you web application have end points that serve json or html content based on the content type of the request. This was you would reduce duplication of business code. The duplication will be only in the UI code.

Step 2: The you could implement the UI part of the web application using modern javascript frameworks such as angular, react, vue, etc... as a separate ui application that gets the business data from the existing current web application. Now you convert the UI web application as desktop application using techonologies such as electoron

When you do it this way, there duplication will be zero. However the downside would be the need to familiar with the recent technologies such as angular (or react or vue) and electron.

Answer 3

Think of the web application and the desktop application as two different views of the same thing.

If I were you (and it may not be possible to rework at this point), I'd implement the logic as a HTTP API, and integrate both the desktop client and the web client with it. Just restrict the usage of any write ability for requests from the web client.