6 ms·
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 reque
by devmunchies 3y ago
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.
- dilyevsky 3y agoThere's a proto service implementation from NATS folks that I think does what you want - https://github.com/nats-rpc/nrpc https://github.com/nats-rpc/nrpc
- devmunchies 3y agoNice! 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.
- FridgeSeal 3y agoNats 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.
- devmunchies 3y agoYeah 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.
- kodah 3y agoOrthogonal is a math term fwiw. Most SWEs are math majors by way of CS/CE. Hence it shows up here a lot.
- shaklee3 3y agoNats 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.