5 ms·

This is grpc, Google's remote procedure call framework based on protobuffers. You don't really use it to expose public services, you mostly use it when you cont

This is grpc, Google's remote procedure call framework based on protobuffers. You don't really use it to expose public services, you mostly use it when you control both client and server endpoints, such as microservices. You get type marshalling and other niceties with it that you don't get with REST, and it is much lighter and less complex than SOAP (on which WCF is based). Another decent alternative is json-rpc. Cross-platfofm compatibility is also miles better (ws-security and soap exceptions anybody?)

mehrdada 7y ago
> You don't really use it to expose public services Why not? Google Cloud certainly does. Google Ads also exposes gRPC API. Google Assistant SDK is basically gRPC too. You get efficient typed client libraries in 10 or more languages for free. No reason not to consider it for public-facing endpoints.
- james_s_tayler 7y ago
  I haven't played with gRPC much but just trying to get my head around pros and cons and use cases... I was under the impression that you can't specify fields as null. Instead they just get assigned whatever the default value is for that type. That seems like a significant drawback for me if it is indeed the case. Especially in the case of a public facing API. I like the idea of a lot of client libraries able to generate easily, I'm just not sure on this one point how to deal with it nicely...
  - heavenlyblue 7y ago
    It’s so much better to express your opinion when you at least have read the docs of the technology you are discussing.
    - james_s_tayler 7y ago
      "When a message is parsed, if it does not contain an optional element, the corresponding field in the parsed object is set to the default value for that field. The default value can be specified as part of the message description. For example, let's say you want to provide a default value of 10 for a SearchRequest's result_per_page value. optional int32 result_per_page = 3 [default = 10]; If the default value is not specified for an optional element, a type-specific default value is used instead: for strings, the default value is the empty string. For bytes, the default value is the empty byte string. For bools, the default value is false. For numeric types, the default value is zero. For enums, the default value is the first value listed in the enum's type definition. This means care must be taken when adding a value to the beginning of an enum value list. See the Updating A Message Type section for guidelines on how to safely change definitions." Well according to the docs on protocol buffers at least my understanding is as I have read elsewhere. I don't know what your problem is guy.
vmarsy 7y ago
> You get type marshalling and other niceties My favorite other nicety is forward and backwards compatibility. Having an older binary being able to easily handle the next version of the incoming proto, and also to not loose any of the not-yet-understood fields. Short blog giving a concrete example: https://www.beautifulcode.co/blog/88-backward-and-forward-compatibility-protobuf-versioning-serialization https://www.beautifulcode.co/blog/88-backward-and-forward-co...
manigandham 7y ago
I highly recommend using it for public endpoints too. It's much nicer than worrying about a supported up-to-date client library in your language or using yet another variation of JSON/HTTP/REST that's unique to every API. Some databases and queues are starting to use this now and it makes it incredibly easy to get started since we can generate our own clients and integrate at whatever level we need.
- xarope 7y ago
  I'm starting to steer our dev team towards this as well, would you have any good links to the gotchas involved in using grpc for public endpoints (if coming from REST as a legacy base)? e.g. for authentication and authorization, throttling etc? I looked at kong, but it seems the plugins don't apply to grpc.
  - manigandham 7y ago
    Unfortunately no good reading I know of other than the official GRPC docs.

mehrdada 7y ago

> You don't really use it to expose public services Why not? Google Cloud certainly does. Google Ads also exposes gRPC API. Google Assistant SDK is basically gRPC too. You get efficient typed client libraries in 10 or more languages for free. No reason not to consider it for public-facing endpoints.

james_s_tayler 7y ago
I haven't played with gRPC much but just trying to get my head around pros and cons and use cases... I was under the impression that you can't specify fields as null. Instead they just get assigned whatever the default value is for that type. That seems like a significant drawback for me if it is indeed the case. Especially in the case of a public facing API. I like the idea of a lot of client libraries able to generate easily, I'm just not sure on this one point how to deal with it nicely...
- heavenlyblue 7y ago
  It’s so much better to express your opinion when you at least have read the docs of the technology you are discussing.
  - james_s_tayler 7y ago
    "When a message is parsed, if it does not contain an optional element, the corresponding field in the parsed object is set to the default value for that field. The default value can be specified as part of the message description. For example, let's say you want to provide a default value of 10 for a SearchRequest's result_per_page value. optional int32 result_per_page = 3 [default = 10]; If the default value is not specified for an optional element, a type-specific default value is used instead: for strings, the default value is the empty string. For bytes, the default value is the empty byte string. For bools, the default value is false. For numeric types, the default value is zero. For enums, the default value is the first value listed in the enum's type definition. This means care must be taken when adding a value to the beginning of an enum value list. See the Updating A Message Type section for guidelines on how to safely change definitions." Well according to the docs on protocol buffers at least my understanding is as I have read elsewhere. I don't know what your problem is guy.

vmarsy 7y ago

> You get type marshalling and other niceties My favorite other nicety is forward and backwards compatibility. Having an older binary being able to easily handle the next version of the incoming proto, and also to not loose any of the not-yet-understood fields. Short blog giving a concrete example: https://www.beautifulcode.co/blog/88-backward-and-forward-compatibility-protobuf-versioning-serialization https://www.beautifulcode.co/blog/88-backward-and-forward-co...

manigandham 7y ago

I highly recommend using it for public endpoints too. It's much nicer than worrying about a supported up-to-date client library in your language or using yet another variation of JSON/HTTP/REST that's unique to every API. Some databases and queues are starting to use this now and it makes it incredibly easy to get started since we can generate our own clients and integrate at whatever level we need.

xarope 7y ago
I'm starting to steer our dev team towards this as well, would you have any good links to the gotchas involved in using grpc for public endpoints (if coming from REST as a legacy base)? e.g. for authentication and authorization, throttling etc? I looked at kong, but it seems the plugins don't apply to grpc.
- manigandham 7y ago
  Unfortunately no good reading I know of other than the official GRPC docs.