3 ms·

Things I don’t get: 1. why are they choosing gRPC over REST if the application is entirely web based. With REST you have a standardized system of verbs and not

Things I don’t get: 1. why are they choosing gRPC over REST if the application is entirely web based. With REST you have a standardized system of verbs and not specific application functions (GET /user/id , 200 OK <data> vs.... MyGetUserFoo(ID) , some return data unique to application). With RPC both sides need very specific knowledge of the functions each other have and their arguments all the time, service discovery seems harder and an update to application seems to nearly always imply and update to web. 2. What is the model supposed to be for typical protobuf schema sharing? I like PBs, but it seems a little harder than JSON or CBOR or MessagePak or other schemaless serializers in that the proto file has the same sync issue among all of your endpoints. 3. Wouldn’t be really swell if serializers were supported by cloud providers and Microservices a little more? I have a project right now that every time a message goes from our services to an endpoint it needs encoding and decoding. This is kind of a header now for every Microservices we have, it would be nice to not have the option of making so many mistakes.

ec109685 8y ago
gRPC’s responses are backwards compatible, so you aren’t mandated to update all clients at the same time.
- lugg 8y ago
  You're still blocked from using later features potentially even reaching a dependency chain deadlock until you update. Systems like this work far better when you just work to not break backwards compatibility full stop. Similarly, they work better when you don't tangle up dependencies in a bunch of shared code, generated or otherwise.
  - joshuamorton 8y ago
    I'm unclear what problem your describing. Your always blocked from using later features until an update because we'll, you won't have application code that can take advantage of those features until you update.
  - ehsankia 8y ago
    That's missing the point. Yes, the goal is to get to a state where all the services are running the new code, but the hard part is that transition. You can manually handle it using versioning and such, but gRPC handles that for you.
- nhooyr 8y ago
  JSON is as well.
  - isoskeles 8y ago
    JSON is agnostic towards anything-compatibility. If you want your service to be backwards compatible, and it is serving JSON, I think you're only going to achieve your goal through rigorous 'integration' tests.
nine_k 8y ago
REST is seriously more expensive traffic-wise. Traffic may be cheap, but latency of receiving a large message can't be helped. Protobufs can be and in normal practice are made backwards-compatible. For serious breaking changes, you want to version your endpoints anyway.
owaislone 8y ago
> With RPC both sides need very specific knowledge of the functions each other have and their arguments all the time Some might say that is a good thing. It kind of makes your API "type-safe". You can also auto-generate client libraries for the grpc services so your JS code would literally import a function and call it with args instead of dealing with XHR stuff. > 2. What is the model supposed to be for typical protobuf schema sharing? I like PBs, but it seems a little harder than JSON or CBOR or MessagePak or other schemaless serializers in that the proto file has the same sync issue among all of your endpoints. I don't think the "sync" issue is a problem really. We already have sync issues even if you just use REST. We need to make sure your client code is up to date to handle any changes in your API. This is more or less something engineers need to sync manually. May be write additional tests, may be annotate APIs with versions, etc. Something like grpc makes this explicit and since it can generate code, it allows us to build tooling that can automate most of the "sync issues".

ec109685 8y ago

gRPC’s responses are backwards compatible, so you aren’t mandated to update all clients at the same time.

lugg 8y ago
You're still blocked from using later features potentially even reaching a dependency chain deadlock until you update. Systems like this work far better when you just work to not break backwards compatibility full stop. Similarly, they work better when you don't tangle up dependencies in a bunch of shared code, generated or otherwise.
- joshuamorton 8y ago
  I'm unclear what problem your describing. Your always blocked from using later features until an update because we'll, you won't have application code that can take advantage of those features until you update.
- ehsankia 8y ago
  That's missing the point. Yes, the goal is to get to a state where all the services are running the new code, but the hard part is that transition. You can manually handle it using versioning and such, but gRPC handles that for you.
nhooyr 8y ago
JSON is as well.
- isoskeles 8y ago
  JSON is agnostic towards anything-compatibility. If you want your service to be backwards compatible, and it is serving JSON, I think you're only going to achieve your goal through rigorous 'integration' tests.

nine_k 8y ago

REST is seriously more expensive traffic-wise. Traffic may be cheap, but latency of receiving a large message can't be helped. Protobufs can be and in normal practice are made backwards-compatible. For serious breaking changes, you want to version your endpoints anyway.

owaislone 8y ago

> With RPC both sides need very specific knowledge of the functions each other have and their arguments all the time Some might say that is a good thing. It kind of makes your API "type-safe". You can also auto-generate client libraries for the grpc services so your JS code would literally import a function and call it with args instead of dealing with XHR stuff. > 2. What is the model supposed to be for typical protobuf schema sharing? I like PBs, but it seems a little harder than JSON or CBOR or MessagePak or other schemaless serializers in that the proto file has the same sync issue among all of your endpoints. I don't think the "sync" issue is a problem really. We already have sync issues even if you just use REST. We need to make sure your client code is up to date to handle any changes in your API. This is more or less something engineers need to sync manually. May be write additional tests, may be annotate APIs with versions, etc. Something like grpc makes this explicit and since it can generate code, it allows us to build tooling that can automate most of the "sync issues".