10 ms·

Can somebody please explain to me why we would use gRPC?

deleted 6y ago
[deleted]
jruroc 6y ago
Serialization/deserialization speed and reducing transfer size are good reasons for large throughput service-to-service communication. Also a decent ecosystem around code generation from .proto files and gateways to still support some level of JSON-based calls.
weitzj 6y ago
It makes it really nice to define APIs (like with Openapi of swagger). There is a bunch of code generators out there to produce code for your definitions to have a native swift , objective , Java, Go api stubs for either clients or servers. It is a joy to work with in cross functional teams and define your APIs whilst taking into account what Api versioning would mean, how to define enums, how to rename field names whilst being compatible with the transport protocol and other things. Also if you were to route a payload from service A via B to C and each service is deployed independently and gets new Api changes, gRPC supports you in how to handle ther Szenarios. Sure enough openapi can do all of this I guess but grpc definitions in Protobuf or Google artman are just way quicker to understand and work with. (At least for me)
- k__ 6y ago
  I see, cool. So the spec already includes versioning?
  - q3k 6y ago
    No, gRPC/protobuf instead provides you with ways to evolve your schema easily in the IDL and the result on the wire, without breaking either side. You can rename fields (but keep the tag number and therefore wire format compatibility), add fields (which will be ignored by the other side), remove fields (as all are explicitly optional so every consumer explicitly checks for their presence anyway), ignore unset fields (as the wire encoding is to a certain-degree self-describing), etc.
    - weitzj 6y ago
      Also context propagation is part of gRPC which supports you in thinking about tracing, request cancellation, deadlines so that you actually have a chance to employ SLOs
    - gravypod 6y ago
      Another important part about forward-and-backward-compat is that protos support passing unknown fields. If I add a new field into a shared proto that A, B, and C all use if A and C have been updated but B was never updated as long as B uses the proto correctly it will have the new field delivered to C. I use this at my current job where our client is a hardware appliance that we are not at all allowed to update so, if we need to add new data for our backend to handle that the client downloads locally we can and we don't need to worry about pushing new client code to do it. This is magic for anyone who has been using Retrofit or something similar and sees fields dropping as normal.
- fulafel 6y ago
  Not familiar with gRPC, questions: how does the tooling compare to HTTP? Browser devtools lets you look what's on the wire, replay requests with slight alterations for debugging, have timelines and visualizations for the history of communication, extract and send self contained scriptlets (like you can do with curl) to someone else, etc. Which of these have some equivalents in generally available gRPC tooling?
  - thinkharderdev 6y ago
    In general, not nearly as mature. In general though, gRPC is not for browser->server calls (grpc-web notwithstanding) but is designed for server<->server communication. There is some tooling out there for development (https://github.com/fullstorydev/grpcurl https://github.com/fullstorydev/grpcurl and https://github.com/fullstorydev/grpcui https://github.com/fullstorydev/grpcui are pretty nice) but it's still much less mature than the massive amount of mature tooling available for HTTP-based services. And that is both an artifact of gRPCs relative youth compared to REST and also for some more fundamental reasons (binary wire format, mutual TLS based authentication, etc). All that said, I've been working with gRPC over the past 6 months or so and overall the development experience is much nicer on net I think.
  - q3k 6y ago
    There's grpcurl and other similar tools for when you just want to run a simple gRPC request against a server. If you server runs the reflection service, it will also let you inspect the schema of whatever is running on a given endpoint. For in-browser use with gRPCweb, if you use test-proto-on-XHR, things continue to work as with REST/JSON. For inter-server debugging, you usually defer to opentracing or similar, and capture request data there.
  - weitzj 6y ago
    There is also Charlesproxy which supports Protobuf. But from my experience you use the code generator and trust the deserializer and serializer since they are unit tested. So you can just unit test your methods and don’t have to look at the actual binary blob payload. You trust that gRPC is battle tested and you can just test your code. You would probably wrap the generated methods/objects/structs in your own domain model and unit test the mapping between them. Using the objects from gRPC throughout your code directly does work but sometimes is not what you want to work with. So I rather would introduce another boundary to the transport. But that is personal preference (in case I want to get rid of gRPC and don’t want to touch my business logic)
q3k 6y ago
Sure. You would use gRPC when: - You want to have inter-service RPC. - You want not only unary calls, but also bidirectional streaming. - You want a well-defined schema for your RPC data and methods. - You want a cross-language solution that guarantees interoperability (no more JSON parsing differences! [1]) [1] - http://seriot.ch/parsing_json.php http://seriot.ch/parsing_json.php
- wnevets 6y ago
  >Parsing JSON is a Minefield and there are people who complain it's too simple, i.e no comments
  - q3k 6y ago
    It's one of those 'simple at first glace' standards. If you want to confuse someone who advocates for JSON's 'simplicity' as a feature, ask them what happens when their favorite JSON deserializer receives repeated dictionary keys (yes, that's valid JSON per RFC 7159).
    - deckard1 6y ago
      there is no standard so simple that humans won't make a mess of it. You think "CSV, comma-separated-values, it's right in the name!" And then you write a parser for it and realize it won't read CSV files Excel generates. Years ago I was porting an r5rs Scheme app from Guile to other Scheme systems. The entire standard is 50 pages of fairly readable basic English. You would not believe the amount of differences different interpreter/compilers have on their agreement as to what a symbol can be. Or under-specified cases such as integer->char (one system goes out of its way to be a dick about it and purposely not use ASCII, trading pragmatics for pedantry)
    - jeffbee 6y ago
      % echo '{"a": 5, "a": 42}' | jq { "a": 42 } Pretty much what I expected and also what you would get if you saw two instances of the same optional non-repeated field in a protocol buffer message. What were you expecting or wanting?
didip 6y ago
The biggest benefit is when your company supports multiple programming languages. All RPC calls can still stay uniform regardless language backend.
coder543 6y ago
Things I "love" about REST APIs: - How should I pass an argument? Let me count the many ways: 1. Path parameters 2. Query parameters in the URL 3. Query parameters in the body of the request 4. JSON/YAML/etc. in the body of the request 5. Request headers (yes, people use these for API tokens, API versions, and other things sometimes) - There's also the REST verb that is often super arbitrary. PUT vs POST vs PATCH... so many ways to do the same thing. - HTTP response codes... so many numbers, so little meaning! There are so many ways to interpret a lot of these codes, and people often use 200 where they really "should" use 202... etc. Response codes other than 200 and 500 are effectively never good enough by themselves, so then we come to the next part: - HTTP responses. Do we put the response in the body using JSON, MessagePack, YAML, or which format do we standardize on? Response headers are used for... some things? Occasionally, responses like HTTP redirects will often just throw HTML into API responses where you're normally using JSON. - Bonus round: HTTP servers will often support compressing the response, but almost never do they allow compressing the request body, so if you're sending large requests frequently... well, oops. I don't personally have experience with gRPC, but REST APIs can be a convoluted mess, and even standardizing internally only goes so far. I like the promise of gRPC, where it handles all of the mundane transport details for me, and as a bonus... it will generate client implementations from a definition file, and stub out the server implementation for me... in whatever languages I want. Why wouldn't you want that?
- kbar13 6y ago
  Also writing bespoke REST clients for every single endpoint is just a huge waste of time and error prone since there’s so many ways of doing everything. One of my biggest gripes with REST APIs is having identifiers in url path instead of in query params or the request body
  - spockz 6y ago
    Honestly, swagger and OpenApi have existed for ages. Who still creates bespoke rest clients? It took me one day to create a template for generating code that links our http client of choice to api specifications. These also exist out of the box for many clients like ribbon.
sudhirj 6y ago
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?
- q3k 6y ago
  > 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. [1] https://grpc.io/docs/guides/auth/ https://grpc.io/docs/guides/auth/
- coder543 6y ago
  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.
hagsh 6y ago
I work in a startup which is ~10 months old where we've decided to go all in on gRPC for all communications, both inter-service and client (Web SPA and a CLI) to service. Although investment in tooling had been significant in the beginning it has truly paid off its dividends now as we can develop in Golang (micro services, CLI), Javascript (SPA) and Python (end to end testing framework), and have a single definition for all our API endpoints and messages in the form of Protobufs. These protobufs automatically generate all client and server code and give us out-of-the-box backward and forward compatibility, increased performance due to binary format over the wire and more.. Our Architect which put together most of this infrastructure has written an entire series of blog posts about how we use gRPC in practice, detailing our decisions and tooling: https://stackpulse.com/blog/tech-blog/grpc-in-practice-introduction/ https://stackpulse.com/blog/tech-blog/grpc-in-practice-intro... https://stackpulse.com/blog/tech-blog/grpc-in-practice-directory-structure-linting-and-more/ https://stackpulse.com/blog/tech-blog/grpc-in-practice-direc... https://stackpulse.com/blog/tech-blog/grpc-web-using-grpc-in-your-front-end-application/ https://stackpulse.com/blog/tech-blog/grpc-web-using-grpc-in...
- balfirevic 6y ago
  My, oh my! From the first article: "About 2 months ago I started working at StackPulse. When I joined there was not a single line of code written yet. We’ve had to decide on many different things. One of those things was choosing a “protocol” for communication both between our micro services and externally".
wbl 6y ago
When you don't want to deal with the portmapper anymore and think distributed reference counting is a bad idea. Seriously binary RPC has been around for ages.
jwatte 6y ago
HTTP is super great for loosely coupled, request-based services. RPC is more lightweight for persistent connections to stateful services. RPC makes broadcast easier than HTTP. Individual RPC requests have (much) less overhead than HTTP requests, which is very helpful when tight coupling is acceptable. Trying to run, say, MMO gaming servers over HTTP is an exercise in always paying double for everything you want to do. (Also, trying to run a FPS gaming server over TCP instead of UDP is equally not the right choice!)
gravypod 6y ago
My main reasons: 1. It's standardized all the implementation for each language is roughly similar and has the same feature sets (middlewares, stubs, retry, hedging, timeouts, deadlines, etc). 2. High performance framework/webserver in "every" language. No more "should I use flask or the built in http server or gunicorn or waitress or..." 3. Tooling can be built around schemas as code. There's a great talk that I highly recommend about some of the magic you can do [0]. 4. Protos are great for serialization and not just over a network! Need to store configs or data in a range of formats (json, prototxt, binary, yaml)? 5. Streaming. It's truely amazing and can dramatically reduce latency if you need to do a lot of collection-of-things or as-soon-as-x processing. 6. Lower resource usage. Encoding/decoding protos is faster then encoding and decoding json. At high throughput that begins to matter. 7. Linting & standards can be defined and enforced programatically [1] 8. Pressures people to document things. You comment your .c or .java code, why not comment your .proto? [0] - https://youtu.be/j6ow-UemzBc?t=435 https://youtu.be/j6ow-UemzBc?t=435 [1] - https://google.aip.dev/ https://google.aip.dev/

deleted 6y ago

[deleted]

Serialization/deserialization speed and reducing transfer size are good reasons for large throughput service-to-service communication. Also a decent ecosystem around code generation from .proto files and gateways to still support some level of JSON-based calls.

weitzj 6y ago

It makes it really nice to define APIs (like with Openapi of swagger). There is a bunch of code generators out there to produce code for your definitions to have a native swift , objective , Java, Go api stubs for either clients or servers. It is a joy to work with in cross functional teams and define your APIs whilst taking into account what Api versioning would mean, how to define enums, how to rename field names whilst being compatible with the transport protocol and other things. Also if you were to route a payload from service A via B to C and each service is deployed independently and gets new Api changes, gRPC supports you in how to handle ther Szenarios. Sure enough openapi can do all of this I guess but grpc definitions in Protobuf or Google artman are just way quicker to understand and work with. (At least for me)

k__ 6y ago
I see, cool. So the spec already includes versioning?
- q3k 6y ago
  No, gRPC/protobuf instead provides you with ways to evolve your schema easily in the IDL and the result on the wire, without breaking either side. You can rename fields (but keep the tag number and therefore wire format compatibility), add fields (which will be ignored by the other side), remove fields (as all are explicitly optional so every consumer explicitly checks for their presence anyway), ignore unset fields (as the wire encoding is to a certain-degree self-describing), etc.
  - weitzj 6y ago
    Also context propagation is part of gRPC which supports you in thinking about tracing, request cancellation, deadlines so that you actually have a chance to employ SLOs
  - gravypod 6y ago
    Another important part about forward-and-backward-compat is that protos support passing unknown fields. If I add a new field into a shared proto that A, B, and C all use if A and C have been updated but B was never updated as long as B uses the proto correctly it will have the new field delivered to C. I use this at my current job where our client is a hardware appliance that we are not at all allowed to update so, if we need to add new data for our backend to handle that the client downloads locally we can and we don't need to worry about pushing new client code to do it. This is magic for anyone who has been using Retrofit or something similar and sees fields dropping as normal.
fulafel 6y ago
Not familiar with gRPC, questions: how does the tooling compare to HTTP? Browser devtools lets you look what's on the wire, replay requests with slight alterations for debugging, have timelines and visualizations for the history of communication, extract and send self contained scriptlets (like you can do with curl) to someone else, etc. Which of these have some equivalents in generally available gRPC tooling?
- thinkharderdev 6y ago
  In general, not nearly as mature. In general though, gRPC is not for browser->server calls (grpc-web notwithstanding) but is designed for server<->server communication. There is some tooling out there for development (https://github.com/fullstorydev/grpcurl https://github.com/fullstorydev/grpcurl and https://github.com/fullstorydev/grpcui https://github.com/fullstorydev/grpcui are pretty nice) but it's still much less mature than the massive amount of mature tooling available for HTTP-based services. And that is both an artifact of gRPCs relative youth compared to REST and also for some more fundamental reasons (binary wire format, mutual TLS based authentication, etc). All that said, I've been working with gRPC over the past 6 months or so and overall the development experience is much nicer on net I think.
- q3k 6y ago
  There's grpcurl and other similar tools for when you just want to run a simple gRPC request against a server. If you server runs the reflection service, it will also let you inspect the schema of whatever is running on a given endpoint. For in-browser use with gRPCweb, if you use test-proto-on-XHR, things continue to work as with REST/JSON. For inter-server debugging, you usually defer to opentracing or similar, and capture request data there.
- weitzj 6y ago
  There is also Charlesproxy which supports Protobuf. But from my experience you use the code generator and trust the deserializer and serializer since they are unit tested. So you can just unit test your methods and don’t have to look at the actual binary blob payload. You trust that gRPC is battle tested and you can just test your code. You would probably wrap the generated methods/objects/structs in your own domain model and unit test the mapping between them. Using the objects from gRPC throughout your code directly does work but sometimes is not what you want to work with. So I rather would introduce another boundary to the transport. But that is personal preference (in case I want to get rid of gRPC and don’t want to touch my business logic)

q3k 6y ago

Sure. You would use gRPC when: - You want to have inter-service RPC. - You want not only unary calls, but also bidirectional streaming. - You want a well-defined schema for your RPC data and methods. - You want a cross-language solution that guarantees interoperability (no more JSON parsing differences! [1]) [1] - http://seriot.ch/parsing_json.php http://seriot.ch/parsing_json.php

wnevets 6y ago
>Parsing JSON is a Minefield and there are people who complain it's too simple, i.e no comments
- q3k 6y ago
  It's one of those 'simple at first glace' standards. If you want to confuse someone who advocates for JSON's 'simplicity' as a feature, ask them what happens when their favorite JSON deserializer receives repeated dictionary keys (yes, that's valid JSON per RFC 7159).
  - deckard1 6y ago
    there is no standard so simple that humans won't make a mess of it. You think "CSV, comma-separated-values, it's right in the name!" And then you write a parser for it and realize it won't read CSV files Excel generates. Years ago I was porting an r5rs Scheme app from Guile to other Scheme systems. The entire standard is 50 pages of fairly readable basic English. You would not believe the amount of differences different interpreter/compilers have on their agreement as to what a symbol can be. Or under-specified cases such as integer->char (one system goes out of its way to be a dick about it and purposely not use ASCII, trading pragmatics for pedantry)
  - jeffbee 6y ago
    % echo '{"a": 5, "a": 42}' | jq { "a": 42 } Pretty much what I expected and also what you would get if you saw two instances of the same optional non-repeated field in a protocol buffer message. What were you expecting or wanting?

didip 6y ago

The biggest benefit is when your company supports multiple programming languages. All RPC calls can still stay uniform regardless language backend.

coder543 6y ago

Things I "love" about REST APIs: - How should I pass an argument? Let me count the many ways: 1. Path parameters 2. Query parameters in the URL 3. Query parameters in the body of the request 4. JSON/YAML/etc. in the body of the request 5. Request headers (yes, people use these for API tokens, API versions, and other things sometimes) - There's also the REST verb that is often super arbitrary. PUT vs POST vs PATCH... so many ways to do the same thing. - HTTP response codes... so many numbers, so little meaning! There are so many ways to interpret a lot of these codes, and people often use 200 where they really "should" use 202... etc. Response codes other than 200 and 500 are effectively never good enough by themselves, so then we come to the next part: - HTTP responses. Do we put the response in the body using JSON, MessagePack, YAML, or which format do we standardize on? Response headers are used for... some things? Occasionally, responses like HTTP redirects will often just throw HTML into API responses where you're normally using JSON. - Bonus round: HTTP servers will often support compressing the response, but almost never do they allow compressing the request body, so if you're sending large requests frequently... well, oops. I don't personally have experience with gRPC, but REST APIs can be a convoluted mess, and even standardizing internally only goes so far. I like the promise of gRPC, where it handles all of the mundane transport details for me, and as a bonus... it will generate client implementations from a definition file, and stub out the server implementation for me... in whatever languages I want. Why wouldn't you want that?

kbar13 6y ago
Also writing bespoke REST clients for every single endpoint is just a huge waste of time and error prone since there’s so many ways of doing everything. One of my biggest gripes with REST APIs is having identifiers in url path instead of in query params or the request body
- spockz 6y ago
  Honestly, swagger and OpenApi have existed for ages. Who still creates bespoke rest clients? It took me one day to create a template for generating code that links our http client of choice to api specifications. These also exist out of the box for many clients like ribbon.

sudhirj 6y ago

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?

q3k 6y ago
> 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. [1] https://grpc.io/docs/guides/auth/ https://grpc.io/docs/guides/auth/
coder543 6y ago
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.

hagsh 6y ago

I work in a startup which is ~10 months old where we've decided to go all in on gRPC for all communications, both inter-service and client (Web SPA and a CLI) to service. Although investment in tooling had been significant in the beginning it has truly paid off its dividends now as we can develop in Golang (micro services, CLI), Javascript (SPA) and Python (end to end testing framework), and have a single definition for all our API endpoints and messages in the form of Protobufs. These protobufs automatically generate all client and server code and give us out-of-the-box backward and forward compatibility, increased performance due to binary format over the wire and more.. Our Architect which put together most of this infrastructure has written an entire series of blog posts about how we use gRPC in practice, detailing our decisions and tooling: https://stackpulse.com/blog/tech-blog/grpc-in-practice-introduction/ https://stackpulse.com/blog/tech-blog/grpc-in-practice-intro... https://stackpulse.com/blog/tech-blog/grpc-in-practice-directory-structure-linting-and-more/ https://stackpulse.com/blog/tech-blog/grpc-in-practice-direc... https://stackpulse.com/blog/tech-blog/grpc-web-using-grpc-in-your-front-end-application/ https://stackpulse.com/blog/tech-blog/grpc-web-using-grpc-in...

balfirevic 6y ago
My, oh my! From the first article: "About 2 months ago I started working at StackPulse. When I joined there was not a single line of code written yet. We’ve had to decide on many different things. One of those things was choosing a “protocol” for communication both between our micro services and externally".

wbl 6y ago

When you don't want to deal with the portmapper anymore and think distributed reference counting is a bad idea. Seriously binary RPC has been around for ages.

jwatte 6y ago

HTTP is super great for loosely coupled, request-based services. RPC is more lightweight for persistent connections to stateful services. RPC makes broadcast easier than HTTP. Individual RPC requests have (much) less overhead than HTTP requests, which is very helpful when tight coupling is acceptable. Trying to run, say, MMO gaming servers over HTTP is an exercise in always paying double for everything you want to do. (Also, trying to run a FPS gaming server over TCP instead of UDP is equally not the right choice!)

gravypod 6y ago

My main reasons: 1. It's standardized all the implementation for each language is roughly similar and has the same feature sets (middlewares, stubs, retry, hedging, timeouts, deadlines, etc). 2. High performance framework/webserver in "every" language. No more "should I use flask or the built in http server or gunicorn or waitress or..." 3. Tooling can be built around schemas as code. There's a great talk that I highly recommend about some of the magic you can do [0]. 4. Protos are great for serialization and not just over a network! Need to store configs or data in a range of formats (json, prototxt, binary, yaml)? 5. Streaming. It's truely amazing and can dramatically reduce latency if you need to do a lot of collection-of-things or as-soon-as-x processing. 6. Lower resource usage. Encoding/decoding protos is faster then encoding and decoding json. At high throughput that begins to matter. 7. Linting & standards can be defined and enforced programatically [1] 8. Pressures people to document things. You comment your .c or .java code, why not comment your .proto? [0] - https://youtu.be/j6ow-UemzBc?t=435 https://youtu.be/j6ow-UemzBc?t=435 [1] - https://google.aip.dev/ https://google.aip.dev/