That is still complicated. To maximally reduce complexity you need less. After all the word complexity literally means many.
1. Use a single traffic receiver at both the browser application and the terminal application. This thing works like a load balancer. It receives messages from a network and sends them where they need to go. There is only 1 place to troubleshoot connectivity concerns. You can still choose between monolith and multi-service applications and have as many micro services as you want.
2. Reduce reliance on HTTP. HTTP is a unidirectional communication technology with a forced round trip. That is a tremendous amount of unnecessary overhead/complexity. I prefer a persistent websocket opened from the browser. Websockets are bidirectional and there is no round trip. This means no more polling the server for updates. Instead everything is an independent event. The browser sends messages to the server at any time and the server independently sends messages to the browser as quickly as it can, which is real time communication happening as quickly as your network connection has bandwidth and your application can process it.
Your first sentence was my primary takeaway from this article. Rather than dealing with complexity, I feel like these ideas create more. Issue has already been taken with "overfetching is not an option". It certainly is an option, albeit a non-optimal one. In this business, non-optimal is probably optimal for now, for most of us.
I would like for there to be solutions to the problems identified in this article. I don't have them, and I also would like for the solutions to not be the ones laid out in this article. Better to build something new (?) than to put these band-aids on the existing framework.
1. Use a single traffic receiver at both the browser application and the terminal application. This thing works like a load balancer. It receives messages from a network and sends them where they need to go. There is only 1 place to troubleshoot connectivity concerns. You can still choose between monolith and multi-service applications and have as many micro services as you want.
2. Reduce reliance on HTTP. HTTP is a unidirectional communication technology with a forced round trip. That is a tremendous amount of unnecessary overhead/complexity. I prefer a persistent websocket opened from the browser. Websockets are bidirectional and there is no round trip. This means no more polling the server for updates. Instead everything is an independent event. The browser sends messages to the server at any time and the server independently sends messages to the browser as quickly as it can, which is real time communication happening as quickly as your network connection has bandwidth and your application can process it.