
Ask HN: Library recommendations for a Client / Server project (all Java) - HockeyPlayer
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.<p>I’m having trouble finding information about modern Java client-server best practices.<p>I’d like to hear architectural or library recommendations that address:<p>-	Pushing just the data that changed seems nicer than polling the servers every second<p>-	Several of the clients are requesting the same information from the same server; minimizing the load on that server would be nice.<p>-	Serialization of objects.  Protocol Buffers vs native Java serialization?<p>-	Recovery when the network hiccups
======
BjoernKW
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.

~~~
HockeyPlayer
We are all experienced Java programmers who don't know web programming. (we
are an HFT shop finally getting around to expanding the primitive GUI that
controls the trading machines; we have been using Excel for 10 years).

All the clients are running in our Colorado office and we can upgrade them at
will.

I think JMS or similar would probably work very well but we don't know
messaging so we are having trouble knowing how best to use it.

~~~
BjoernKW
Getting a basic messaging bus up and running is easy enough if you’re using
Spring Boot for example.

Modelling distributed asynchronous processes can cause headaches though.

Messaging helps with decoupling and scaling components but messaging systems
can be difficult to test and debug.

If you need any help with that (or any other part of your software) just drop
me a note (see my profile for contact details).

------
kevinherron
Take a look at gRPC: [https://grpc.io](https://grpc.io)

~~~
imauld
Came here to say the same thing.

You get the benefit of bi-directional streaming for free as well as the
ability to generate clients in a dozen or so languages should you come to your
senses and move off of Java :-P

------
grizzles
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.

------
abra_kadabra
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.

