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