REST-based desktop application

Question

We have a highly efficient library written in a low-level programming language. We would like to allow third parties to implement a GUI for it.

The approach we would like to take is to write a REST server. The GUI (written in whatever language) needs to start the server and is then able to use the library.

As said, the goal is to create a local desktop application, so the server should only listen to the localhost and the GUI (the latter may be solved via auth).

Is there a reason such an approach is not used more often (I hardly couldn't find anything)? The only place it is mentioned seems to be The Modern Application Stack – Part 3: Building a REST API Using Express.js as "... MERN (MongoDB, Express, React, Node.js) Stacks, why you might want to use them, and how to combine them to build your web application (or your native mobile or desktop app)."

Are there tutorials or special architectural patterns?

I found the following resources:

• https://www.fyears.org/2017/02/electron-as-gui-of-python-apps-updated.html
• https://www.reddit.com/r/rust/comments/49c95n/nativelooking_ui_with_rust/d0quiia/

Answer 1

Splitting desktop application into server and client is not that common. But it is also not unheard of. Linux's X Server might be good example of that.

The reason why it is not used more often, is that API between the client and server is heavily rigid and strict. The question is if the advantages of that approach: running in separate processes, ability to use different languages, frameworks or development approaches on either side, improved security, etc.. outweigh inflexibility stemming from hard separation between the client and server. In the majority of cases, those advantages do not outweigh. But in some specific cases it might.

In your case, it could make sense, as it would allow to develop the UI in completely separate system than the computation library. And keeping them in separate processes would shield each from possible stability issues in the other side.

Also, I would stop focusing so much on "REST". The core issue here is separation of UI and background logic into separate processes. How those processes communicate is secondary.

Answer 2

Platform independency of the GUI is not dependent on the platform independency of the library's API, it is dependent on the platform independency of the GUI's implementation. And your GUI will not be "language independent", one has to pick a programming language for implementing it.

I assume your "low-level programming language" in which the lib is written provides already classic C API? So for such a GUI, using one of the mainstream ecosystems for desktop development which provide platform independency (like Java or C++ with a framework like Qt) will immediately allow you to include the lib (in Java by JNI, in C++ by directly linking it). There is no need to build a REST layer around it, which would require

• an additional networking layer for the client and the server
• to map the libraries' API artificially to the CRUD-like paradigm of REST, even if your lib has nothing in common with CRUD operations

Using a REST layer, or maybe another kind of web communication layer, makes only sense if one wants to have the option of running the GUI on a different machine apart from the server where the library functions are executed. For a one-machine desktop application, it makes things overly complicated.

Answer 3

REST is a web nomenclature. Yet you are targeting this to run locally, with a desktop app. Why aren't any of the well established desktop solutions acceptable?

You don't mention any specific implementation technology you're targeting (i.e. .Net, Node.js, etc.). On Windows, what you are describing would typically be exposed as one of the following:

1. A simple DLL reference
2. A COM+ component (in the old days)
3. A service with an exposed endpoint and embedded web server
4. ** An assembly registered in the GAC and referenced in your desktop app **