3

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:

10
  • Why do you need REST? Are your users going to access this server over the Internet? Jan 26, 2018 at 19:16
  • 2
    Here's some additional fodder for your thought process: joost.vunderink.net/blog/2016/01/03/… Jan 26, 2018 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, 2018 at 19:26
  • 2
    Yeah, you kinda need a justification for a server, like multiple clients connecting to it. Jan 26, 2018 at 19:32
  • 1
    So why do you need a server then? Jan 26, 2018 at 20:08

3 Answers 3

8

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.

4
  • 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, 2018 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, 2018 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, 2020 at 4:23
  • @stevec well, in this case, OP said the original library is built in a low level programming language. And the aim is to allow third parties to write their own GUIs. So that's the motivation.
    – Daniel F.
    Aug 20, 2023 at 21:55
9

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
  • 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, 2018 at 22:21
2

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 **
2
  • 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. Jan 26, 2018 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, 2018 at 20:17

Your Answer

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

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