| JavaFX is the obvious choice if the client (for whatever reason) has to be a Java desktop client. For distributed client-server applications like yours using a Java back-end that provides REST endpoints and a web UI consuming those endpoints in many cases is a better choice: A web front-end affords you more rapid, easier roll-outs and an environment that's amenable to distributed network environments out of the box. Two options for such a web front-end would be Angular (if you front-end has to behave very interactively, basically like a desktop app) or Thymeleaf. As for the specifics: > - Pushing just the data that changed seems nicer than polling the servers every second
> - Several of the clients are requesting the same information from the same server; minimizing the load on that server would be nice. You could use a messaging protocol like JMS or AMQP for that. Messaging can very quickly become quite complex though. So, consider this very carefully before going down that road. > - Serialization of objects. Protocol Buffers vs native Java serialization? I'd suggest using JSON and Jackson for processing that JSON on the server. Native Java serialisation certainly works but it can become a problem should you ever decide to use another technology in either layer. Additionally, all by itself object serialisation is more of a low-level technique for storing object state. It can be used for distributing that object state but you'll have to work with byte streams and similar implementation details, which can at times also lead to compatibility issues. > - Recovery when the network hiccups Depending on your architecture using the circuit breaker pattern (for example with Netflix' Hystrix) might be an option here. Again, this might be more than what you need right now and hence a bit over the top. So, caveat emptor. |