Ask HN: Library recommendations for a Client / Server project (all Java)

3 points by HockeyPlayer 8 years ago | 8 comments

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

BjoernKW 8 years ago |

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.

tudelo 8 years ago | |

There also is the option to use http://www.gwtproject.org/overview.html. To be honest I do not really recommend it unless one of the driving factors of NOT using angular and the like are that you want to avoid javascript. It works, but something about it just feels wrong... It's not slow or hard to use but you run in to the common problem of extremely unhelpful errors such as null pointers with nonsensical names in the generated javascript when you make a code mistake.

HockeyPlayer 8 years ago | |

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 8 years ago | | |

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 8 years ago |

Take a look at gRPC: https://grpc.io

imauld 8 years ago | |

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 8 years ago |

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 8 years ago |

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.