gRPC for Microservices Communication
techdozo.dev
gRPC for Microservices Communication
1–10 of 73 posts
Re: gRPC for Microservices Communication
#2I've been seeing gRPC support in the various api-gateway solutions for a decent while now, was always interested in its use in the abstract, but having a human readable interface would be very difficult to give up, and something I personally probably wouldn't do unless I was bumping against some hard efficiency limits.
Re: gRPC for Microservices Communication
#3Is this the path to a tightly coupled distributed monolith?
Re: gRPC for Microservices Communication
#4I've been seeing gRPC support in the various api-gateway solutions for a decent while now, was always interested in its use in the abstract, but having a human readable interface would be very difficult to give up, and something I personally probably wouldn't do unless I was bumping against some hard efficiency limits.
Depends on what your goals are. Protos give a nice API definition if you want to make sure you don't screw up that data that's on the wire (field name misspelled or something similar). Obviously JSON has OpenAPI (swagger), but I'm still a fan of protobufs (probably stockholm syndrome).
Re: gRPC for Microservices Communication
#5Is this the path to a tightly coupled distributed monolith?
Yeah imagine if instead of just using plain text JSON for your web application you could use a proprietary binary format that web browsers know nothing about and require a translation layer to talk to. It's awesome.
Re: gRPC for Microservices Communication
#6I've been seeing gRPC support in the various api-gateway solutions for a decent while now, was always interested in its use in the abstract, but having a human readable interface would be very difficult to give up, and something I personally probably wouldn't do unless I was bumping against some hard efficiency limits.
Depends on what your goals are. Protos give a nice API definition if you want to make sure you don't screw up that data that's on the wire (field name misspelled or something similar). Obviously JSON has OpenAPI (swagger), but I'm still a fan of protobufs (probably stockholm syndrome).
How do you replace Postman? I feel like it's pretty easy to test text encoding formats that are human readable, but not sure how I'd do that with gRPC.
Re: gRPC for Microservices Communication
#7How do you test gRPC? E.g. a gRPC microservice.
Re: gRPC for Microservices Communication
#8Earlier quoted context omitted.
Depends on what your goals are. Protos give a nice API definition if you want to make sure you don't screw up that data that's on the wire (field name misspelled or something similar). Obviously JSON has OpenAPI (swagger), but I'm still a fan of protobufs (probably stockholm syndrome).
How do you replace Postman? I feel like it's pretty easy to test text encoding formats that are human readable, but not sure how I'd do that with gRPC.
I personally use BloomRPC — just point it at your protos and go. (plus it supports grpc-web)
Re: gRPC for Microservices Communication
#9Is this the path to a tightly coupled distributed monolith?
Yeah imagine if instead of just using plain text JSON for your web application you could use a proprietary binary format that web browsers know nothing about and require a translation layer to talk to. It's awesome.
Agreed. Use JSON, proprietary binary formats are terrible, and 99% of the time the bandwidth savings aren't worth it. For messaging, I really like NATS (incubating in the K8S landscape - probably graduating soon). My fav thing is the wildcard usage in NATS.
Re: gRPC for Microservices Communication
#10Earlier quoted context omitted.
How do you replace Postman? I feel like it's pretty easy to test text encoding formats that are human readable, but not sure how I'd do that with gRPC.
I personally use BloomRPC — just point it at your protos and go. (plus it supports grpc-web)
+1 for Bloom. The only thing it’s missing is support for the gRPC introspection API. It’s not bad if you have all of your organizations protos in one repo (which is what we do), but otherwise annoying to have to clone a repo and point Bloom at the .proto file just to talk to the API. Other tools (grpcui I believe is one) support introspection but aren’t as polished at Bloom.