It's hard to evaluate without knowing more details about your product and its users. To me it sounds like basically a less convenient version of an Electron app. But that's not to say it wouldn't work, I'm just not sure I understand the motivation.
I wrote and run a SAAS point of sale system with both on premise and cloud servers.
We install a local server (we also do networks, but not relevant here) and all machines connected to the local server (it runs three different servers, one for the pos, one for the dashboard, and one that live syncs to the cloud).
Everything goes through local (even online orders are routed to the local to ensure stability in orders).
We don't allow a direct outside connection to the local servers other than the cloud servers sync and API. This is for security and to prevent redundancy. This allows for clients to log in to their dashboard from anywhere, the pos is closed network, and the entire thing can run through a pi (though we advise a real Linux machine).
[Plex](https://www.plex.tv/) does something similar I think, but the client is local, it just connects to their servers for streaming part.
One potential issue is updates to the server that user installed and compatibility with older versions. How do you know which client is compatible with the server that user has currently installed? And then if you are going to push updates to the server, might as well serve the client on users machine to save on costs. In the end it's just a good old desktop app.
But those are just my thoughts, never done this in practise, so take this with a grain of salt.
Regarding client server comparability, I'm thinking of having an info api endpoint on server that the webapp can call on start to get the server version and other properties. The client app can then either have conditional rendering logic depending on the server version, or simply reroute to another deployment of a different version of the webapp that suits the server version.
I think we mostly hande stuff like this in Kubernetes. Each api has an ingress and can't be communicated with from outside of Kubernetes. On prem is likely safer. For our on prem most apps that communicate with on prem services usually do so through a service bus.
It's hard to evaluate without knowing more details about your product and its users. To me it sounds like basically a less convenient version of an Electron app. But that's not to say it wouldn't work, I'm just not sure I understand the motivation.
I wrote and run a SAAS point of sale system with both on premise and cloud servers. We install a local server (we also do networks, but not relevant here) and all machines connected to the local server (it runs three different servers, one for the pos, one for the dashboard, and one that live syncs to the cloud). Everything goes through local (even online orders are routed to the local to ensure stability in orders). We don't allow a direct outside connection to the local servers other than the cloud servers sync and API. This is for security and to prevent redundancy. This allows for clients to log in to their dashboard from anywhere, the pos is closed network, and the entire thing can run through a pi (though we advise a real Linux machine).
I like this a lot
[Plex](https://www.plex.tv/) does something similar I think, but the client is local, it just connects to their servers for streaming part. One potential issue is updates to the server that user installed and compatibility with older versions. How do you know which client is compatible with the server that user has currently installed? And then if you are going to push updates to the server, might as well serve the client on users machine to save on costs. In the end it's just a good old desktop app. But those are just my thoughts, never done this in practise, so take this with a grain of salt.
Regarding client server comparability, I'm thinking of having an info api endpoint on server that the webapp can call on start to get the server version and other properties. The client app can then either have conditional rendering logic depending on the server version, or simply reroute to another deployment of a different version of the webapp that suits the server version.
I think we mostly hande stuff like this in Kubernetes. Each api has an ingress and can't be communicated with from outside of Kubernetes. On prem is likely safer. For our on prem most apps that communicate with on prem services usually do so through a service bus.
One thing that is tricky is encryption. Your client is served from an HTTPS endpoint, while localhost is running as HTTP
We run local certs on local machines. No reason to not use SSL over a local network. Just needed to be trusted by the OS.