Return to Answer

Improved wording and spelling.

Source Link

edit approved Feb 27, 2021 at 7:54

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 processprocesses, ability to use different languages, frameworks or development approaches on either side, improved security, etc.. outweightoutweigh inflexibility stemming from hard separation between the client and server. In the majority of cases, it those advantages do not outweightoutweigh. 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.

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 process, ability to use different languages, frameworks or development approaches on either side, improved security, etc.. outweight inflexibility stemming from hard separation between the client and server. In majority of cases, it those advantages do not outweight. But in some specific cases it might.

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.

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.

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.

Source Link

answered Jan 26, 2018 at 22:29

Euphoric

38.2k
6
82
120

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 process, ability to use different languages, frameworks or development approaches on either side, improved security, etc.. outweight inflexibility stemming from hard separation between the client and server. In majority of cases, it those advantages do not outweight. But in some specific cases it might.

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.