I'm currently working on the setup for communication between around 10 internal Java microservices in a monorepo with separate deployments and frequent updates. I'm weighing my options between JSON-RPC, gRPC, and REST. My main requirements include compile-time type safety with shared interfaces, managing API evolution and backward compatibility, using Java Records as DTOs, and having static service discovery.
I'm curious if anyone else has experience with JSON-RPC libraries for service communication and which ones are recommended. Many libraries appear to be outdated (like jsonrpc4j from 2021 and simple-json-rpc from 2020) — is this framework still viable? Should I consider building a custom solution, or would it be better to switch to gRPC or stick with REST? I'm particularly drawn to JSON-RPC's straightforward RPC style compared to gRPC's complexity and the limitations of REST for method-call APIs.
8 Answers
We created an internal RPC framework using Java interfaces and DTOs, managing them with a message broker between services. It's seamless for developers, and exceptions are handled gracefully. Nowadays, though, I’d lean towards gRPC since it's more familiar for onboarding new developers.
I've worked with JSON-RPC, gRPC, and REST. Honestly, REST can be pretty frustrating if you're looking for something standardized. JSON-RPC is great for quick setups, especially when you can't control both sides. It's super easy to implement a server in almost any language and even use curl for the client side.
On the other hand, gRPC is really impressive! It's fast and can handle a ton of requests without heavy CPU usage. The downside is the build process can be quite tricky since you need to convert proto files into language-specific objects. Once that’s out of the way, though, it’s smooth sailing, and it even supports features like streaming, which is useful for certain use cases.
Also, keep in mind that gRPC relies on HTTP/2, which isn’t directly supported by browsers. That could complicate things if you're trying to use it in a frontend framework like React or Angular.
If full-duplex communication isn't a priority, I can't recommend Twirp enough. It offers versioning, service generation, and JSON interoperability without the usual complexities of gRPC or HTTP/2 headaches.
Consider using client libraries that you can import into your microservices. This way, you can change how they communicate without a significant overhaul. It gives you flexibility and allows for potential mixed communication methods.
Why jump straight into microservices? Building a scalable monolith could simplify things. There's no need for inter-service communication; you just call internal methods. You can always scale parts of it later.
If your services are going to remain internal, I’d suggest looking into a fast serialization library instead of sticking with JSON. JSON’s type limitations might restrict you when you already have shared types. However, if you prioritize observability and interoperability, a simple wire protocol can work wonders.
For machine-to-machine communication, gRPC really outshines the others. Setting up the build system for protobufs can be a pain, but if all services are in the same repo, you only have to set it up once, which makes the hassle worth it.
We’ve used JSON-RPC for large-scale applications like ERP systems and find it outperforms REST significantly. gRPC can feel like overkill for us. With Jetty handling SSL and compression, our JSON-RPC implementation manages over 30,000 requests per second on a single server!
Yeah, I hit that same snag with the build process when I tried to move to gRPC. I had to tell my manager that we needed more service instances because our tools didn't support the required setup.