2

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?

Improve this question
6
  • 2
    What does the desktop version offer that the web version doesn't?
    – svidgen
    Oct 17, 2019 at 2:40
  • Are the high-level instructions specific to the operations of GIS or database, or are they generic such as those written in scripting languages?
    – rwong
    Oct 17, 2019 at 2:41
  • Have you looked at Electron and other similar means of packaging web apps as desktop apps?
    – GrandmasterB
    Oct 17, 2019 at 2:51
  • @svidgen Web version works mostly in a read-only mode, it's very much different from desktop version.
    – M. Underhill
    Oct 17, 2019 at 10:21
  • @rwong A high-level serializable instruction could e.g. execute a procedure in the database with some parameters, or open a form with some parameters, or disable or enable some visual element, or jump to some position on the map. So unfortunately, not really generic. It would be kind of like my own scripting language.
    – M. Underhill
    Oct 17, 2019 at 10:24

3 Answers 3

Reset to default
4

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.

Improve this answer
1

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.

Improve this answer
0

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.