We are building a Java GUI to talk to a Java server. The GUI mostly displays information streaming from the server and occasionally gives the server commands. We control the code on both sides. Full deployment is about 10 clients, each talking to 1-3 servers that are in a different state.
I’m having trouble finding information about modern Java client-server best practices.
I’d like to hear architectural or library recommendations that address:
- 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.
- Serialization of objects. Protocol Buffers vs native Java serialization?
- Recovery when the network hiccups
Take a look at gRPC: https://grpc.io
The reason are having problems finding info is that most people don't use java clients these days other than android.
You could try teavm.org or gwtproject.org if you really have your heart set on a java client, but I think most people would probably write the client in javascript, probably using react or vue.
If you just want to push the changed data, that sounds like one of the open source operational transform libs on github might be worth looking into.
First for a bit of background.
How much data will you be pushing across? Things are easier if you can send full objects instead of partial objects.
How much does latency matter? If this has to be as close to real time as possible (ie. stock prices etc), or can this be 1 second updates?
Using Protocol Buffers works well if you need to be very optimized, JSON is really nice for being extremely widely supported but special care needs to be taken for having API versions if you make drastic changes to the API
I think what would be nice would be to know a little bit more about your intended use case, I would say I typically like to build web apps more than native apps because then the server code and client code can be updated as a single unit, instead of having older native clients out in the wild and having to support then until the users decide to update, but some use cases it's better to have a native client.
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.