If you're communicating between two systems, gRPC has a few benefits:
* keeps a socket open between them (HTTP/2) and puts all your method calls on that connection. So you don't have to set up connections on each call or handle your own pooling.
* comes with builtin fast (de &)serialization using protobuf.
* uses a definition language to generate SDKs for a whole bunch of languages.
* makes testing super easy because your testing team, if you have a separate one, can make an SDK in their preferred language and write tests.
Much better developer experience and performance writing HTTP services and code to call them.
Cons are
* not being able to use Postman / firebug, nothing on the wire is human-readable
* load balancer support is sketchy because of the use of HTTP trailers and full path HTTP/2. That's why AWS ALB supporting it is news.
* The auth story isn't very clear. Do you use the out of band setup or add tokens in every single RPC?
> The auth story isn't very clear. Do you use the out of band setup or add tokens in every single RPC?
I think it's actually quite well documented. [1]
You can have out-of-band authentication data per-connection ('per-channel') and per-RPC ('per-call'). SSL certificates can be used per-connection, while token-based authentication (eg. bearer tokens, or anything else that can fit in metadata) can be either.
If you want the list items to render on separate lines, you need to either add an extra newline between list items, or indent the list items by 4 spaces.
Much better developer experience and performance writing HTTP services and code to call them.
Cons are * not being able to use Postman / firebug, nothing on the wire is human-readable * load balancer support is sketchy because of the use of HTTP trailers and full path HTTP/2. That's why AWS ALB supporting it is news. * The auth story isn't very clear. Do you use the out of band setup or add tokens in every single RPC?