I prefer another CNCF incubating project, NATS. (nats.io)

It decouples the service addresses via a pubsub architecture.

So if I want service A to send a request to service B, then it is done by subscribing to a shared topic, there is no service discovery.

It kind of replaces GRPC and Istio.

I like the “static typing” and code generation you get from grpc so a hybrid of the 2 would be my preference.

I actually solved the code generation part for NATS though by using AsyncAPI (like Open API but for messaged based systems). Would be better if baked in.

Nats is a message bus/queue though, which is different from the serialisation format and rpc framework offered by protobufs +grpc.

I love a good queue, but these are “orthogonal” to borrow a favourite HN term.

Yeah completely different tech but it can solve the same problem—connection and communication between services. Implementation details.

If you don’t think about the tech between services, at the end of the day my service is using some protocol to send and receive data, using grpc or otherwise.

NATS has a clean request/reply paradigm built in that makes this simpler.

Orthogonal is a math term fwiw. Most SWEs are math majors by way of CS/CE. Hence it shows up here a lot.

Nats is probably one of the most underappreciated pieces of software. It solves so many problems and I think makes grpc a thing of the past.

There's a proto service implementation from NATS folks that I think does what you want - https://github.com/nats-rpc/nrpc

Nice! We don’t use Go though :) we use F#, Rust, and C.

Would love to see this work supported by the core Nats team. A standard spec so others could make clients.

Story below is about java experience.

The proto files format is ok, because it has nullability defined in the type.

However everything else is bad. I had to use grpc on a project and it was a pain and created problems.

Want to use postman to test locally? Forget it, you have to use some grpc client, and all of them are not ideal.

Want to write automation tests? Good luck finding a tool that supports grpc.

Want to add distributed tracing to calls? You have to use some unofficial code, and better learn the grpc implementation details if you want to be sure that the code is good.

Use json over http, or json over http2 if possible. You will have a much better and less frustrating experience.

Grpc is good for servers moving petabytes of data and for low latency needs (compressed json over http2 would be the same performance in terms of low latency, maybe a few percent slower). I guess 99% of it's users would do much better with a json over http interface.

Nowdays it is very easy to make an http call. In java it can be done with an annotation over an interface method, ex: https://docs.spring.io/spring-cloud-openfeign/docs/current/r... It is also recomended to store the data types used in the interface externally, similar to how proto files work, so that you don't have code duplication on the client and the server.