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:

  • Why do you need REST? Are your users going to access this server over the Internet? – Robert Harvey Jan 26 '18 at 19:16
  • 2
    Here's some additional fodder for your thought process: joost.vunderink.net/blog/2016/01/03/… – Robert Harvey Jan 26 '18 at 19:23
  • 6
    Is there a reason such an approach is not used more often (I hardly couldn't find anything). Having a server for a single client (itself) is utterly unecessary and overkill. – Laiv Jan 26 '18 at 19:26
  • 2
    Yeah, you kinda need a justification for a server, like multiple clients connecting to it. – Robert Harvey Jan 26 '18 at 19:32
  • 1
    So why do you need a server then? – Robert Harvey Jan 26 '18 at 20:08

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.

  • 2
    +1 Those 2 separate processes might not even talk over http. Could use a local socket, COM, or some other RPC mechanism. – RubberDuck Jan 26 '18 at 22:47
  • 1
    Side note, the XServers where always intended to allow the GUI to be run on a terminal separated from the central machine. – Doc Brown Jan 27 '18 at 9:45
  • What would be a motivation for splitting a desktop application into parts that communicate via API? Could one be if parts of the application are built in different frameworks/languages? – stevec Dec 22 '20 at 4:23

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.

  • 1
    I agree with the caveat that if you wanted to be able to run the app purely locally and/or from a remote backend, you might want to structure it this way. Although, I would question using HTTP for local interactions. It adds needless IO. A good REST implementation should work when used normal library. – JimmyJames Jan 26 '18 at 22:21

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 **
  • My backend is platform independent and the REST approach is the only one that comes to my mind which would allow a platform and language independent GUI. – Manuel Schmidt Jan 26 '18 at 19:37
  • 1
    So you want the library interface to be platform independent. Are installations of the library platform independent now? Or do you have multiple installations (one per OS)? – Worrystone Jan 26 '18 at 20:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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