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:
Best Answer
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.