I'm currently designing the communication for around 10 internal Java services that are part of a monorepo with separate deployments and daily changes. I'm weighing the options between JSON-RPC, gRPC, and REST. My main requirements include:
- Compile-time type safety with shared interfaces
- Ability to handle API evolution and maintain backward compatibility
- Use of Java Records as DTOs
- Static service discovery
So I have a couple of questions:
1. Is anyone using JSON-RPC libraries for internal service communication? If so, which ones do you recommend?
2. I've noticed that many libraries seem to be outdated or stagnant (like jsonrpc4j from 2021, and simple-json-rpc from 2020). Does that mean this space is dead?
3. Is it worth building a custom solution, or should I go with gRPC or stick to REST?
I personally prefer JSON-RPC for its simplicity and RPC semantics compared to gRPC's complexity with proto mappings, while REST doesn't feel like a perfect fit for method-call style APIs.
5 Answers
For machine-to-machine communication, I highly recommend gRPC. The setup for protobufs can be tricky, but if your services are all in one repo, you only have to deal with it once. After that, the benefits like strong typing and speed make the hassle worth it.
I've worked with JSON-RPC, gRPC, and REST. In my opinion, REST isn’t ideal—it lacks the standardization you might want. JSON-RPC is a great option if you don’t control both sides of a service. It's easy to implement servers and clients across different platforms.
gRPC is super efficient and can handle a lot of requests with minimal resource use. The downside, however, is its build environment complexity—getting your proto files compiled correctly can be a pain. But once it's set up, it’s amazing for speed and development. Plus, you can have features like bidirectional streaming, which is pretty handy!
Just a heads up, gRPC's http/2 isn’t easily supported in browsers if you’re planning on doing any front-end work.
If you don’t need features like full duplex streaming, consider using Twitch’s Twirp. It avoids the issues typically associated with gRPC while still offering protobuf compatibility, service generation, and error handling. You won't find many libraries yet, but it's generally easy to write your own generator which can be beneficial, too.
If your services are internal, you might want to consider a fast serialization library instead of JSON. Using JSON restricts you to a limited set of types, whereas a better library can offer you more flexibility.
However, if interoperability is key, a straightforward wire protocol might be the better route to take.
In our experience with massive applications like ERP systems, JSON-RPC has been more effective than REST. gRPC feels like overkill for our needs. With SSL and compression via Jetty, we've handled up to 30,000 requests per second on a single server!
I definitely see the appeal of gRPC's performance. The build complexity is a concern for me, though!