12 ms·

gRPC-Web is going GA

345 points by biggestlou 8y ago

asdkhadsj 8y ago
Can someone describe why gRPC-Web needs a proxy? I recently had trouble deciding between the official gRPC-Web and Improbable's gRPC-Web[1]. In the end I decided on Improbable's, because it seemed to not require a proxy. In practice, it's working very nicely. Yet, I'm still not clear on what exactly the Proxy serves to do, in either case. If a browser supports HTTP 2, why is a proxy needed? [1]: https://github.com/improbable-eng/grpc-web https://github.com/improbable-eng/grpc-web
- deleted 8y ago
  [deleted]
- bpicolo 8y ago
  improbable/grpc-web does require a proxy, it just happens to also support a drop-in http proxy in the same app when you're writing a golang based grpc app. grpc/grpc-web intends to support the same: https://github.com/grpc/grpc-web/blob/master/ROADMAP.md#local-proxies https://github.com/grpc/grpc-web/blob/master/ROADMAP.md#loca...
  - asdkhadsj 8y ago
    Ah hah! Thanks! Yea the drop-in web server works awesomely. It's been a surprisingly painless experience. Thanks for linking the roadmap!
- seattleeng 8y ago
  Conceptually, I think you're right -- to serve gRPC requests only requires http2 as a transport and more shouldn't be necessary (edit: I stand corrected, seems like not all HTTP2 features are supported by all modern browsers). In practice, I believe the official gRPC web setup it serves as a translation layer and provides some monitoring bells and whistles. E.g. the official gRPC-Web implementation allows for a base-64 encoded wire format in addition to the typical protobuf binary format, so without a proxy layer, you'd need to define middleware server-side that translates the base64 encoding to the protobuf format. I think the full set of differences can be found here: https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-WEB.md https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-WEB.md
  - thwd 8y ago
    HTTP/2 is only necessary if you want to stream, most of gRPC can be implemented over traditional request/response cycles.
    - Matthias247 8y ago
      Technically it's not even required for that. HTTP/1.1 bodies can be streamed just fine. The main reason not to do this in a browser is that one real TCP connection would be required for each stream, and the number of concurrent outgoing connections from a website is strictly limited. With HTTP/2 this problem goes away.
- hsaliak 8y ago
  gRPC needs access HTTP/2 trailers, which is not supported in browsers today. This necessitates translation in a proxy of some form. It is possible to support in-process or local proxies, but instead starting with this in n languages, we are starting with a proxy, with the intention to build in-process support on languages or use cases where there is real need for it.
  - thwd 8y ago
    Note that trailers have existed since HTTP 1.1.
    - puzzle 8y ago
      Yeah, but a lot of software does not support them, at all levels in the chain. Which is a tragedy. They'd be useful in more contexts than just gRPC.
    - chrissnell 8y ago
      The answer--as I recall--from the Chromium team was that they see trailers access as a security issue. HTTP/2 multiplexes many connections and it was a security risk, they said, to allow one client process to access trailers for connections that may be used by different processes or even entirely different sites behind the same load balancer/reverse proxy/etc. What I don't understand is why gRPC was designed to depend on trailers. Web gRPC is the killer app for this technology. If they could build a new version of the protocol that doesn't rely on trailers, I would be thrilled.
      - mentat 8y ago
        I believe trailers are because you could start streaming a response and end up having an error than you need to communicate out of band. Hopefully someone has a better answer though.
        aktau 8y ago
        I've been trying to read the HTTP2 spec and I can't figure out whether it's allowable to return or modify the HTTP(2) status code in a trailer instead of in the header. After some re-readings, I decided it wasn't allowed. But then, gRPC definitely needs to be able to signal an error even after it has already streamed data. So gRPC would need to use some end-of-connection message, like a trailer.
- deleted 8y ago
  [deleted]
rcfox 8y ago
What does GA mean? The article uses it a few times but doesn't define it.
- tareqak 8y ago
  General availability (GA) is the marketing stage at which all necessary commercialization activities have been completed and a software product is available for purchase, depending, however, on language, region, electronic vs. media availability.[12] Commercialization activities could include security and compliance tests, as well as localization and worldwide availability. The time between RTM and GA can be from a week to months in some cases before a generally available release can be declared because of the time needed to complete all commercialization activities required by GA. At this stage, the software has "gone live". [0] https://en.wikipedia.org/wiki/Software_release_life_cycle#General_availability_(GA) https://en.wikipedia.org/wiki/Software_release_life_cycle#Ge...
- deleted 8y ago
  [deleted]
- kraig 8y ago
  http://www.lmgtfy.com/?q=What+does+GA+mean http://www.lmgtfy.com/?q=What+does+GA+mean
- azurezyq 8y ago
  I think it may be aligned with GCP terms here: https://cloud.google.com/terms/launch-stages https://cloud.google.com/terms/launch-stages General Availability (GA) GA features are open to all developers and are considered stable and fully qualified for production use.
  - hsaliak 8y ago
    I've taken your phrasing and addressed OP's question in the blog. Thank you. :)
- deleted 8y ago
  [deleted]
victor106 8y ago
Anyone here knows if gRPC-Web provides performance benefits as opposed to using REST?
- larkost 8y ago
  RethinkDB switched away from Protobufs (which underly GRPC) in favor of JSON when talking with both Python and Ruby clients because it was so much slower than using JSON. My guess is that this is still true, and even worse for JavaScript (that last is pure speculation). But I would be happy to see real benchmarks done now.
  - philwelch 8y ago
    The performance benefits of Protobuf serialization and deserialization are extremely variable by language; JSON is faster in Python while Protobuf is significantly faster in Java and Golang. JSON is pretty fast in JS (unsurprisingly) but perhaps Google is working on optimizing protobuf in JS.
  - puzzle 8y ago
    Python protocol buffers can use either a native or a C++ implementation. The latter is more than an order of magnitude faster. I'm wondering if they tried that. It doesn't solve the Ruby case, of course. Or JavaScript. gRPC can also use Flatbuffers, by the way.
_zachs 8y ago
I'm still not sold on gRPC vs JSON/REST. .proto offers me little over a decent development environment around JSON, and it seems to be pretty Google-specific. I'm also wary of adopting standards that come out of Google.
- nprateem 8y ago
  Say "farewell" to Swagger, etc. and just generate your server & client libraries. I've found it to be far superior to JSON/REST, especially for microservices. Browser support was always the sticking point to wide adoption, so this is great news.
- Techonomicon 8y ago
  It allows you to define an interface wherein you can then simply generate clients and service libraries from that are typesafe.
- hsaliak 8y ago
  disclaimer: I work for the gRPC team. gRPC lets you use other data exchange formats or IDLs as well, such as flatbuffers. However, the protobuf codegen experience we have spent most of the time and energy on. I see two sides to this - on one hand, there are folks who want a 'contract first' development experience, in which the service contracts are defined first, and the business logic is implemented later. gRPC lends itself to this model very well. Admittedly, this is also the way services are developed in Google. On the other hand, there are folks who want a model whereby you evolve a service and generate the specs from that service. Currently, this is not the experience that gRPC is optimized for. Time and effort are the main barriers to making this work well alongside a contract-first experience. FWIW: I believe both models have merit and it really depends on what you want to adopt as the source of truth for how your services interact. Ideally, gRPC would be good at both.
  - yashap 8y ago
    IMO json+REST works just as well for contract first workflows. Just write up the contract in an IDL, have both sides agree on it up front, then use codegen tools to generate client SDK(s) for your client language(s) of choice. Same workflow as as with gRPC, though you’re probably less likely to get generated server stubs (which you don’t really need with json+REST anyways).
nprateem 8y ago
Thus ends REST.
- Myrth 8y ago
  Cue the relevant xkcd standards comic.
juancampa 8y ago
Anyone willing to share experiences using gRPC-Web vs. GraphQL?
- andy_ppp 8y ago
  gRPC is lightweight, highly performant, difficult to debug, difficult to detect breaking schema changes, lots of magic going on to learn compared to REST or GraphQL. GraphQL is much heavier, easier to test and debug and has some performance optimisations like data loader and is better for multiple clients to consume. I’d say it’s easier to manage schema changes but it’s probably not empirical. I guess huge overheads by comparison to gRPC but I’m guessing data over the wire is a much larger piece of the pie. Personally think GraphQL is far superior for web clients and I think gRPC for services in general can be a pretty large overhead for most teams... at least initially you are going to get things done much faster with restful services.
  - anentropic 8y ago
    as someone without experience in gRPC but interested to use it, I am curious why it was difficult to detect breaking schema changes? thanks
    - andy_ppp 8y ago
      Because the schema is based on a numbered position rather than a field name. This means you need to never rename positions - if you want to deprecate fields you just loose the numbering. Numbers 0-15 use less space in the message than others for example.
- _euac 8y ago
  As I understand it, they are essentially very different technologies. GraphQL focuses on providing a DSL for requesting subsets of data from a web endpoint that "talks" JSON. gRPC-Web is just a wrapper around gRPC so that you can expose your RPC endpoints in a front-end friendly manner. In other words: GraphQL is akin to SQL, while gRPC-Web would be closer to a serialization/exchange format like XML/SOAP.
Myrth 8y ago
https://xkcd.com/927/ https://xkcd.com/927/
skybrian 8y ago
I thought this was interesting from the roadmap: "The binary protobuf encoding format is not most CPU efficient for browser clients. Furthermore, the generated code size increases as the total protobuf definition increases. "For Google's Web applications (e.g. gmail), we use a JSON like format which is comparable to JSON in efficiency but also very compact in both the message size and code size." I wonder what the benchmarks look like? It seems surprising this hasn't changed with newer browser optimizations.
- romed 8y ago
  Proto encoding makes the unfortunate choice of more-bit variable-length numbers which are hard to decode. JavaScript engines and browser all have very well optimized decoders for the unary length-prefixed variable-length numbers (i.e. UTF-8). So you can imagine how an encoding very much like proto but with the proper style of varints can be faster. Generated code size is a huge problem of all protobuf-supporting languages, not just js. Code size issues on Android have constrained development of the official (google) protobuf libraries in various ways over the years.
linkmotif 8y ago
I think GraphQL makes more sense here, at least in terms of unifying backend services and presenting them to a user—aka an API gateway—but this could be a very useful way to transmit GraphQL queries and subscriptions and for sidecar services like authentication, or just very simple services.
gigatexal 8y ago
This is all well and good but examples only ever show localhost quick projects. I’d like to see the demo game upped a bit to include some basic auth and HTTPS stuff
- hsaliak 8y ago
  that's good feedback, can I request you to file an issue detailing what you would like to see in an example? https://github.com/grpc/grpc-web/issues https://github.com/grpc/grpc-web/issues
- stan394 8y ago
  There is a gRPC-Web on Kubernetes example here: https://github.com/salrashid123/grpc_web_with_gke https://github.com/salrashid123/grpc_web_with_gke
- gigatexal 8y ago
  Done: https://github.com/grpc/grpc-web/issues/341 https://github.com/grpc/grpc-web/issues/341
calebh 8y ago
I think that if we're going to have a full blown typed RPC system, we need to at least be able to represent generics/parametric polymorphism. As far as I know, protobufs do not support this feature! Why are we settling for using a subpar interchange format when the alternative (polymorphic sum types) is so much better?
- superfrank 8y ago
  Can you give me an example where generics would be helpful? I'm not doubting you, my brain is just a little slow today and I'm struggling to think of a scenario where I feel I would NEED them for gRPC.
  - wbl 8y ago
    If I was to design a type system I would introduce sum and product as type constructors and some basic types and be done. To make this really work takes polymorphism so you can write list.
  - deathanatos 8y ago
    Option<T>. Protobuf "supports" this particular case via other means: messages are always implicitly nullable, and the WKTs cover primitives, which don't count as messages. Map<K, V>: Protobuf has dedicated syntax for this case.
  - calebh 8y ago
    Generics and user defined types make it easier to represent more complicated data. Now everyone is just going to have to write custom encoders and decoders to get the data to a Protobuf compatible format, which is pretty much what we do right now with JSON. If you haven't used algebraic/sum types before, I highly recommend trying them out. Once you use them you won't want to go back.
- romed 8y ago
  gRPC is not "typed" in any substantial way. You wan use any payload encoding you feel like suits your worldview. Protobufs happen to be a common choice.
JBReefer 8y ago
Isn't this just WCF reborn? Contracts, codegen no one will use, etc
- aaaaaaaaaab 8y ago
  >Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works. https://news.ycombinator.com/item?id=18296113 https://news.ycombinator.com/item?id=18296113
- zbentley 8y ago
  Awww, man. I like WCF; wish more people would use it (and use it right). So much of the stuff I've had to do there is untangling the work of people that fundamentally don't want what WCF provides (quick, one-size-fits-all-imperfectly prototyping with an option for greater flexibility later on), and instead want 'automatic contract enforcement, but I still get to write the client/server code from scratch the way I used to', which is a recipe for sadness.
mlthoughts2018 8y ago
This is going to enable so many people to find-replace “Thrift” with “gRPC” for such an easy solution to updating legacy Slack messages, GitHub issues, and message board threads. Updating your outrage at a stupid tool nobody should use has never been easier!
brad0 8y ago
Personally I don't think that gRPC is a good step forward. However, if the community at large moves away from REST + JSON to gRPC I'll follow. Why? - I don't want to be like the guy who refuses to use anything but XML + SOAP - I want to be valuable on the job market. Putting gRPC may get you in the door - Avoid bikeshedding Anyone who's been in the industry a few years knows that "the way" to do things changes often. Going with the flow and completing the actual job is what matters.
- asdkhadsj 8y ago
  Mind commenting on what you think would be better? Personally I'm in love with the idea of protobufs, but I'm not terribly sold on the implementation. The language is great, but the mapping to code languages is not great. Eg, to make great idiomatic Go code, I need to litter my Protobuf with extensions (via Gogoprotobuf) and the readability of the Protobuf sort of goes down the tubes. So I think the idea behind Protobuf is great, and the syntax itself looks great, but a small tweak to how it handles code generation would be very welcome. Likewise gRPC feels quite verbose. I use it, but conceptually I massively prefer simplistic implementations like Twirp[1]. However, again Protobuf handles this really nicely in that I can use the same Protobuf file to describe a Twirp or gRPC Service - it's great. [1]: https://github.com/twitchtv/twirp https://github.com/twitchtv/twirp So what do you think would be a better step forward?
- ljm 8y ago
  I found gRPC to be exciting when I was writing something in Go. The tooling around that is pretty decent and it sets a certain expectation about how it works. Then I had to write a client in a different language, and the generated code was utterly intuitive. gRPC itself adds extensions to Protobuf to handle code-gen nuances but of course they're deployed in Go-land, not relevant-language-land. That's a small niggle that's easily solved one way or another. What was frustrating was that the `protobuf` CLI could handle language extensions, but you couldn't make use of that without a hell of a lot of faff. If you want to add a gRPC client to your Rails app you can't use the protobuf CLI, that you might already have.... you have to add a gem that includes a different version of the protobuf CLI that is guaranteed to be not compatible. Even the command and its args aren't compatible. When I found myself working against that I just gave up. It's a solution that sounds elegant, but you're going to get a feature out of the door much quicker if you steer away from that layer altogether. There's nothing wrong with an ad-hoc HTTP API if you're confident about the interface. Technical purity isn't technical excellence and nor is it user value. Just like K8S, you're not gonna need RPC on the web unless you can justify the scale and have the firepower to handle it.
lost-theory 8y ago
It's interesting to watch Google's moves to control every part of the stack. Browser: Chrome. Frontend: Closure compiler -> obfuscated SPAs. Transport: gRPC. Backend: Proprietary Google software written in Golang. Orchestration: Kubernetes. Hosting: Google Cloud. Etc. You can imagine a future where Google services are no longer just web apps on the same footing as anything else in the web ecosystem, but where every step of the development, deployment, and end-use is managed by Google. Can't blame them for doing that, I'm sure it's more efficient, but it's definitely moving the web in a different direction, one where Google has more control at the expense of everyone else (end users, competitors).
- gcb0 8y ago
  don't forget office suite:gdoc, and conferencing: hangouts/meet/whatever they force down your throat tomorrow. this is specially pernicious as they are actively using it to undermine Firefox in the workplaces. their proprietary plugin took 2 months to be available in Firefox after they rebranded hangouts as meet. and now it only supports SD video and crashes frequently.
- romed 8y ago
  It shouldn’t be a surprise that the company all-in on the Web has a solution for every part of the stack. It might be a surprise that they open source so many things but that’s a pleasant surprise. Every thing you mentioned has a replacement from someone else so I don’t see how you concluded “control”. And finally the great majority of Google’s backends are written in C++ not Go.
  - lost-theory 8y ago
    Many companies are "all-in on the web" but aren't in the same position as Google. Look at the recent Chrome profile / Google account auto-login issue. Isn't that an example of Google exercising "control" over how its users interact with the web? If Google is effectively a monopoly, does it matter if you could theoretically replace all of its offerings? Think about other monopolies in history, I'm sure they had "replacements" too.
bcheung 8y ago
Can people share their experience and success stories with gRPC and/or GraphQL? I've tried both in the past and found that APIs are rarely as static as typed API systems require. Many APIs have fields that are required conditionally based on the value of other fields. Other times the schema is dynamic and workarounds are required like stuffing things into a JSON object and making it a "string" in the API. This added a bunch of work to marshall it in and out of a custom workaround format. In both cases (gRPC and GraphQL) we've run into so many issues that the technology was abandoned and we fell back to plain JSON REST.
- cobookman 8y ago
  You can have conditional protobuf fields / messages. Checkout: - Any: https://developers.google.com/protocol-buffers/docs/proto3#any https://developers.google.com/protocol-buffers/docs/proto3#a... - OneOf: https://developers.google.com/protocol-buffers/docs/proto3#oneof https://developers.google.com/protocol-buffers/docs/proto3#o... I believe Any is the equivalent to having a proto in format of: ``` message MyMessage { string type = 1; bytes data = 2; } ```
  - buckhx 8y ago
    Also FieldMasks and the View patterns can be very useful for the other issues that were raised https://cloud.google.com/apis/design/design_patterns#partial_response https://cloud.google.com/apis/design/design_patterns#partial...
- yashap 8y ago
  Have used both, and don’t like either. I actually DO like very statically typed schemas, but you can easily do this with json over REST, and using IDLs to generate SDKs. For gRPC vs. REST, I just don’t see the benefits. Performance wins of gRPC are extremely minimal for most backends, ”push based” workflows can easily be handled with webhooks (or message queues), so why am I throwing out extremely mature technology (and tooling/middleware!) that every dev is very familiar with? For GraphQL, reducing client/datacentre round trips is nice, but can also easily be achieved with RESTful “coordination” services, that serve the front end specifically, and do nothing but stringing together calls to backend services. Why force people to learn another complex technology for that? “Returning smaller payloads” makes minimal impact in practice, and GraphQL requests are MASSIVE compared to REST requests, so you often end up with a performance loss, not gain. Also, GraphQL requests are way harder to glance at in the browser, you can’t just look for GET /dog/123, you have to peek into all the request bodies. And again, all the great REST middleware stops working, because you’re doing RPC. Basically I see them both as extra complexity with little payoff.
pkieltyka 8y ago
I prefer twirp's model of no http2 requirement and supports JSON. https://github.com/twitchtv/twirp https://github.com/twitchtv/twirp I do think twirp code could be refactored and made a lot better though.
- stock_toaster 8y ago
  If twirp had more existing backend implementations, I would certainly use it for more things.
  - zbentley 8y ago
    Check out Thrift: https://thrift.apache.org/ https://thrift.apache.org/
z3t4 8y ago
Has anyone gone from plain text JSON to protobuffer (over Websocket) ? How much bandwidth did you save, and was it worth it ?
gregwebs 8y ago
I am using the HTTP Gateway and generating OpenAPI from that for type-safe access [1]. The downside is that this introduces an additional build step in your project. The upside is supporting a JSON API and not requiring gPRC(-Web) for clients. Even for non-browser clients, GRPC tooling can still be a little heavy-weight to pull into your project compared to OpenAPI. On the other hand, not all languages have good OpenAPI integration. But its also quite possible to use both. [1] https://github.com/gogo/grpc-example https://github.com/gogo/grpc-example
ilaksh 8y ago
How does this compare to JSON-rpc or GraphQL or just using JSON to send custom messages over HTTP 1.1 or HTTP 2?
jhabdas 8y ago
Truly amazing. Death to JSON!
polskibus 8y ago
What's the advantage of gRPC-Web to someone in the .NET world that uses Typescript, and generates TS schemas from .NET POCOs ?
- zbentley 8y ago
  Protobufs (the transfer format of gRPC) include not just a schema, but a transport format that may be more efficient than a serialized POCO. gRPC also allows you to encode communication semantics (i.e. "What does this endpoint want as arguments? What does it return?") and generate both client and server code that complies with (and automatically [de]serializes and validates protobuf data for) those semantics. It's the difference between a schema definition and a schema definition + serialization format + service (not just data) definition/codegen.

345 points by biggestlou 8y ago

Can someone describe why gRPC-Web needs a proxy? I recently had trouble deciding between the official gRPC-Web and Improbable's gRPC-Web[1]. In the end I decided on Improbable's, because it seemed to not require a proxy. In practice, it's working very nicely. Yet, I'm still not clear on what exactly the Proxy serves to do, in either case. If a browser supports HTTP 2, why is a proxy needed? [1]: https://github.com/improbable-eng/grpc-web https://github.com/improbable-eng/grpc-web

deleted 8y ago
[deleted]
bpicolo 8y ago
improbable/grpc-web does require a proxy, it just happens to also support a drop-in http proxy in the same app when you're writing a golang based grpc app. grpc/grpc-web intends to support the same: https://github.com/grpc/grpc-web/blob/master/ROADMAP.md#local-proxies https://github.com/grpc/grpc-web/blob/master/ROADMAP.md#loca...
- asdkhadsj 8y ago
  Ah hah! Thanks! Yea the drop-in web server works awesomely. It's been a surprisingly painless experience. Thanks for linking the roadmap!
seattleeng 8y ago
Conceptually, I think you're right -- to serve gRPC requests only requires http2 as a transport and more shouldn't be necessary (edit: I stand corrected, seems like not all HTTP2 features are supported by all modern browsers). In practice, I believe the official gRPC web setup it serves as a translation layer and provides some monitoring bells and whistles. E.g. the official gRPC-Web implementation allows for a base-64 encoded wire format in addition to the typical protobuf binary format, so without a proxy layer, you'd need to define middleware server-side that translates the base64 encoding to the protobuf format. I think the full set of differences can be found here: https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-WEB.md https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-WEB.md
- thwd 8y ago
  HTTP/2 is only necessary if you want to stream, most of gRPC can be implemented over traditional request/response cycles.
  - Matthias247 8y ago
    Technically it's not even required for that. HTTP/1.1 bodies can be streamed just fine. The main reason not to do this in a browser is that one real TCP connection would be required for each stream, and the number of concurrent outgoing connections from a website is strictly limited. With HTTP/2 this problem goes away.
hsaliak 8y ago
gRPC needs access HTTP/2 trailers, which is not supported in browsers today. This necessitates translation in a proxy of some form. It is possible to support in-process or local proxies, but instead starting with this in n languages, we are starting with a proxy, with the intention to build in-process support on languages or use cases where there is real need for it.
- thwd 8y ago
  Note that trailers have existed since HTTP 1.1.
  - puzzle 8y ago
    Yeah, but a lot of software does not support them, at all levels in the chain. Which is a tragedy. They'd be useful in more contexts than just gRPC.
  - chrissnell 8y ago
    The answer--as I recall--from the Chromium team was that they see trailers access as a security issue. HTTP/2 multiplexes many connections and it was a security risk, they said, to allow one client process to access trailers for connections that may be used by different processes or even entirely different sites behind the same load balancer/reverse proxy/etc. What I don't understand is why gRPC was designed to depend on trailers. Web gRPC is the killer app for this technology. If they could build a new version of the protocol that doesn't rely on trailers, I would be thrilled.
    - mentat 8y ago
      I believe trailers are because you could start streaming a response and end up having an error than you need to communicate out of band. Hopefully someone has a better answer though.
      - aktau 8y ago
        I've been trying to read the HTTP2 spec and I can't figure out whether it's allowable to return or modify the HTTP(2) status code in a trailer instead of in the header. After some re-readings, I decided it wasn't allowed. But then, gRPC definitely needs to be able to signal an error even after it has already streamed data. So gRPC would need to use some end-of-connection message, like a trailer.
deleted 8y ago
[deleted]

rcfox 8y ago

What does GA mean? The article uses it a few times but doesn't define it.

tareqak 8y ago
General availability (GA) is the marketing stage at which all necessary commercialization activities have been completed and a software product is available for purchase, depending, however, on language, region, electronic vs. media availability.[12] Commercialization activities could include security and compliance tests, as well as localization and worldwide availability. The time between RTM and GA can be from a week to months in some cases before a generally available release can be declared because of the time needed to complete all commercialization activities required by GA. At this stage, the software has "gone live". [0] https://en.wikipedia.org/wiki/Software_release_life_cycle#General_availability_(GA) https://en.wikipedia.org/wiki/Software_release_life_cycle#Ge...
deleted 8y ago
[deleted]
kraig 8y ago
http://www.lmgtfy.com/?q=What+does+GA+mean http://www.lmgtfy.com/?q=What+does+GA+mean
azurezyq 8y ago
I think it may be aligned with GCP terms here: https://cloud.google.com/terms/launch-stages https://cloud.google.com/terms/launch-stages General Availability (GA) GA features are open to all developers and are considered stable and fully qualified for production use.
- hsaliak 8y ago
  I've taken your phrasing and addressed OP's question in the blog. Thank you. :)
deleted 8y ago
[deleted]

victor106 8y ago

Anyone here knows if gRPC-Web provides performance benefits as opposed to using REST?

larkost 8y ago
RethinkDB switched away from Protobufs (which underly GRPC) in favor of JSON when talking with both Python and Ruby clients because it was so much slower than using JSON. My guess is that this is still true, and even worse for JavaScript (that last is pure speculation). But I would be happy to see real benchmarks done now.
- philwelch 8y ago
  The performance benefits of Protobuf serialization and deserialization are extremely variable by language; JSON is faster in Python while Protobuf is significantly faster in Java and Golang. JSON is pretty fast in JS (unsurprisingly) but perhaps Google is working on optimizing protobuf in JS.
- puzzle 8y ago
  Python protocol buffers can use either a native or a C++ implementation. The latter is more than an order of magnitude faster. I'm wondering if they tried that. It doesn't solve the Ruby case, of course. Or JavaScript. gRPC can also use Flatbuffers, by the way.

_zachs 8y ago

I'm still not sold on gRPC vs JSON/REST. .proto offers me little over a decent development environment around JSON, and it seems to be pretty Google-specific. I'm also wary of adopting standards that come out of Google.

nprateem 8y ago
Say "farewell" to Swagger, etc. and just generate your server & client libraries. I've found it to be far superior to JSON/REST, especially for microservices. Browser support was always the sticking point to wide adoption, so this is great news.
Techonomicon 8y ago
It allows you to define an interface wherein you can then simply generate clients and service libraries from that are typesafe.
hsaliak 8y ago
disclaimer: I work for the gRPC team. gRPC lets you use other data exchange formats or IDLs as well, such as flatbuffers. However, the protobuf codegen experience we have spent most of the time and energy on. I see two sides to this - on one hand, there are folks who want a 'contract first' development experience, in which the service contracts are defined first, and the business logic is implemented later. gRPC lends itself to this model very well. Admittedly, this is also the way services are developed in Google. On the other hand, there are folks who want a model whereby you evolve a service and generate the specs from that service. Currently, this is not the experience that gRPC is optimized for. Time and effort are the main barriers to making this work well alongside a contract-first experience. FWIW: I believe both models have merit and it really depends on what you want to adopt as the source of truth for how your services interact. Ideally, gRPC would be good at both.
- yashap 8y ago
  IMO json+REST works just as well for contract first workflows. Just write up the contract in an IDL, have both sides agree on it up front, then use codegen tools to generate client SDK(s) for your client language(s) of choice. Same workflow as as with gRPC, though you’re probably less likely to get generated server stubs (which you don’t really need with json+REST anyways).

nprateem 8y ago

Thus ends REST.

Myrth 8y ago
Cue the relevant xkcd standards comic.

juancampa 8y ago

Anyone willing to share experiences using gRPC-Web vs. GraphQL?

andy_ppp 8y ago
gRPC is lightweight, highly performant, difficult to debug, difficult to detect breaking schema changes, lots of magic going on to learn compared to REST or GraphQL. GraphQL is much heavier, easier to test and debug and has some performance optimisations like data loader and is better for multiple clients to consume. I’d say it’s easier to manage schema changes but it’s probably not empirical. I guess huge overheads by comparison to gRPC but I’m guessing data over the wire is a much larger piece of the pie. Personally think GraphQL is far superior for web clients and I think gRPC for services in general can be a pretty large overhead for most teams... at least initially you are going to get things done much faster with restful services.
- anentropic 8y ago
  as someone without experience in gRPC but interested to use it, I am curious why it was difficult to detect breaking schema changes? thanks
  - andy_ppp 8y ago
    Because the schema is based on a numbered position rather than a field name. This means you need to never rename positions - if you want to deprecate fields you just loose the numbering. Numbers 0-15 use less space in the message than others for example.
_euac 8y ago
As I understand it, they are essentially very different technologies. GraphQL focuses on providing a DSL for requesting subsets of data from a web endpoint that "talks" JSON. gRPC-Web is just a wrapper around gRPC so that you can expose your RPC endpoints in a front-end friendly manner. In other words: GraphQL is akin to SQL, while gRPC-Web would be closer to a serialization/exchange format like XML/SOAP.

Myrth 8y ago

https://xkcd.com/927/ https://xkcd.com/927/

skybrian 8y ago

I thought this was interesting from the roadmap: "The binary protobuf encoding format is not most CPU efficient for browser clients. Furthermore, the generated code size increases as the total protobuf definition increases. "For Google's Web applications (e.g. gmail), we use a JSON like format which is comparable to JSON in efficiency but also very compact in both the message size and code size." I wonder what the benchmarks look like? It seems surprising this hasn't changed with newer browser optimizations.

romed 8y ago
Proto encoding makes the unfortunate choice of more-bit variable-length numbers which are hard to decode. JavaScript engines and browser all have very well optimized decoders for the unary length-prefixed variable-length numbers (i.e. UTF-8). So you can imagine how an encoding very much like proto but with the proper style of varints can be faster. Generated code size is a huge problem of all protobuf-supporting languages, not just js. Code size issues on Android have constrained development of the official (google) protobuf libraries in various ways over the years.

linkmotif 8y ago

I think GraphQL makes more sense here, at least in terms of unifying backend services and presenting them to a user—aka an API gateway—but this could be a very useful way to transmit GraphQL queries and subscriptions and for sidecar services like authentication, or just very simple services.

gigatexal 8y ago

This is all well and good but examples only ever show localhost quick projects. I’d like to see the demo game upped a bit to include some basic auth and HTTPS stuff

hsaliak 8y ago
that's good feedback, can I request you to file an issue detailing what you would like to see in an example? https://github.com/grpc/grpc-web/issues https://github.com/grpc/grpc-web/issues
stan394 8y ago
There is a gRPC-Web on Kubernetes example here: https://github.com/salrashid123/grpc_web_with_gke https://github.com/salrashid123/grpc_web_with_gke
gigatexal 8y ago
Done: https://github.com/grpc/grpc-web/issues/341 https://github.com/grpc/grpc-web/issues/341

calebh 8y ago

I think that if we're going to have a full blown typed RPC system, we need to at least be able to represent generics/parametric polymorphism. As far as I know, protobufs do not support this feature! Why are we settling for using a subpar interchange format when the alternative (polymorphic sum types) is so much better?

superfrank 8y ago
Can you give me an example where generics would be helpful? I'm not doubting you, my brain is just a little slow today and I'm struggling to think of a scenario where I feel I would NEED them for gRPC.
- wbl 8y ago
  If I was to design a type system I would introduce sum and product as type constructors and some basic types and be done. To make this really work takes polymorphism so you can write list.
- deathanatos 8y ago
  Option<T>. Protobuf "supports" this particular case via other means: messages are always implicitly nullable, and the WKTs cover primitives, which don't count as messages. Map<K, V>: Protobuf has dedicated syntax for this case.
- calebh 8y ago
  Generics and user defined types make it easier to represent more complicated data. Now everyone is just going to have to write custom encoders and decoders to get the data to a Protobuf compatible format, which is pretty much what we do right now with JSON. If you haven't used algebraic/sum types before, I highly recommend trying them out. Once you use them you won't want to go back.
romed 8y ago
gRPC is not "typed" in any substantial way. You wan use any payload encoding you feel like suits your worldview. Protobufs happen to be a common choice.

JBReefer 8y ago

Isn't this just WCF reborn? Contracts, codegen no one will use, etc

aaaaaaaaaab 8y ago
>Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works. https://news.ycombinator.com/item?id=18296113 https://news.ycombinator.com/item?id=18296113
zbentley 8y ago
Awww, man. I like WCF; wish more people would use it (and use it right). So much of the stuff I've had to do there is untangling the work of people that fundamentally don't want what WCF provides (quick, one-size-fits-all-imperfectly prototyping with an option for greater flexibility later on), and instead want 'automatic contract enforcement, but I still get to write the client/server code from scratch the way I used to', which is a recipe for sadness.

mlthoughts2018 8y ago

This is going to enable so many people to find-replace “Thrift” with “gRPC” for such an easy solution to updating legacy Slack messages, GitHub issues, and message board threads. Updating your outrage at a stupid tool nobody should use has never been easier!

brad0 8y ago

Personally I don't think that gRPC is a good step forward. However, if the community at large moves away from REST + JSON to gRPC I'll follow. Why? - I don't want to be like the guy who refuses to use anything but XML + SOAP - I want to be valuable on the job market. Putting gRPC may get you in the door - Avoid bikeshedding Anyone who's been in the industry a few years knows that "the way" to do things changes often. Going with the flow and completing the actual job is what matters.

asdkhadsj 8y ago
Mind commenting on what you think would be better? Personally I'm in love with the idea of protobufs, but I'm not terribly sold on the implementation. The language is great, but the mapping to code languages is not great. Eg, to make great idiomatic Go code, I need to litter my Protobuf with extensions (via Gogoprotobuf) and the readability of the Protobuf sort of goes down the tubes. So I think the idea behind Protobuf is great, and the syntax itself looks great, but a small tweak to how it handles code generation would be very welcome. Likewise gRPC feels quite verbose. I use it, but conceptually I massively prefer simplistic implementations like Twirp[1]. However, again Protobuf handles this really nicely in that I can use the same Protobuf file to describe a Twirp or gRPC Service - it's great. [1]: https://github.com/twitchtv/twirp https://github.com/twitchtv/twirp So what do you think would be a better step forward?
ljm 8y ago
I found gRPC to be exciting when I was writing something in Go. The tooling around that is pretty decent and it sets a certain expectation about how it works. Then I had to write a client in a different language, and the generated code was utterly intuitive. gRPC itself adds extensions to Protobuf to handle code-gen nuances but of course they're deployed in Go-land, not relevant-language-land. That's a small niggle that's easily solved one way or another. What was frustrating was that the `protobuf` CLI could handle language extensions, but you couldn't make use of that without a hell of a lot of faff. If you want to add a gRPC client to your Rails app you can't use the protobuf CLI, that you might already have.... you have to add a gem that includes a different version of the protobuf CLI that is guaranteed to be not compatible. Even the command and its args aren't compatible. When I found myself working against that I just gave up. It's a solution that sounds elegant, but you're going to get a feature out of the door much quicker if you steer away from that layer altogether. There's nothing wrong with an ad-hoc HTTP API if you're confident about the interface. Technical purity isn't technical excellence and nor is it user value. Just like K8S, you're not gonna need RPC on the web unless you can justify the scale and have the firepower to handle it.

lost-theory 8y ago

It's interesting to watch Google's moves to control every part of the stack. Browser: Chrome. Frontend: Closure compiler -> obfuscated SPAs. Transport: gRPC. Backend: Proprietary Google software written in Golang. Orchestration: Kubernetes. Hosting: Google Cloud. Etc. You can imagine a future where Google services are no longer just web apps on the same footing as anything else in the web ecosystem, but where every step of the development, deployment, and end-use is managed by Google. Can't blame them for doing that, I'm sure it's more efficient, but it's definitely moving the web in a different direction, one where Google has more control at the expense of everyone else (end users, competitors).

gcb0 8y ago
don't forget office suite:gdoc, and conferencing: hangouts/meet/whatever they force down your throat tomorrow. this is specially pernicious as they are actively using it to undermine Firefox in the workplaces. their proprietary plugin took 2 months to be available in Firefox after they rebranded hangouts as meet. and now it only supports SD video and crashes frequently.
romed 8y ago
It shouldn’t be a surprise that the company all-in on the Web has a solution for every part of the stack. It might be a surprise that they open source so many things but that’s a pleasant surprise. Every thing you mentioned has a replacement from someone else so I don’t see how you concluded “control”. And finally the great majority of Google’s backends are written in C++ not Go.
- lost-theory 8y ago
  Many companies are "all-in on the web" but aren't in the same position as Google. Look at the recent Chrome profile / Google account auto-login issue. Isn't that an example of Google exercising "control" over how its users interact with the web? If Google is effectively a monopoly, does it matter if you could theoretically replace all of its offerings? Think about other monopolies in history, I'm sure they had "replacements" too.

bcheung 8y ago

Can people share their experience and success stories with gRPC and/or GraphQL? I've tried both in the past and found that APIs are rarely as static as typed API systems require. Many APIs have fields that are required conditionally based on the value of other fields. Other times the schema is dynamic and workarounds are required like stuffing things into a JSON object and making it a "string" in the API. This added a bunch of work to marshall it in and out of a custom workaround format. In both cases (gRPC and GraphQL) we've run into so many issues that the technology was abandoned and we fell back to plain JSON REST.

cobookman 8y ago
You can have conditional protobuf fields / messages. Checkout: - Any: https://developers.google.com/protocol-buffers/docs/proto3#any https://developers.google.com/protocol-buffers/docs/proto3#a... - OneOf: https://developers.google.com/protocol-buffers/docs/proto3#oneof https://developers.google.com/protocol-buffers/docs/proto3#o... I believe Any is the equivalent to having a proto in format of: ``` message MyMessage { string type = 1; bytes data = 2; } ```
- buckhx 8y ago
  Also FieldMasks and the View patterns can be very useful for the other issues that were raised https://cloud.google.com/apis/design/design_patterns#partial_response https://cloud.google.com/apis/design/design_patterns#partial...
yashap 8y ago
Have used both, and don’t like either. I actually DO like very statically typed schemas, but you can easily do this with json over REST, and using IDLs to generate SDKs. For gRPC vs. REST, I just don’t see the benefits. Performance wins of gRPC are extremely minimal for most backends, ”push based” workflows can easily be handled with webhooks (or message queues), so why am I throwing out extremely mature technology (and tooling/middleware!) that every dev is very familiar with? For GraphQL, reducing client/datacentre round trips is nice, but can also easily be achieved with RESTful “coordination” services, that serve the front end specifically, and do nothing but stringing together calls to backend services. Why force people to learn another complex technology for that? “Returning smaller payloads” makes minimal impact in practice, and GraphQL requests are MASSIVE compared to REST requests, so you often end up with a performance loss, not gain. Also, GraphQL requests are way harder to glance at in the browser, you can’t just look for GET /dog/123, you have to peek into all the request bodies. And again, all the great REST middleware stops working, because you’re doing RPC. Basically I see them both as extra complexity with little payoff.

pkieltyka 8y ago

I prefer twirp's model of no http2 requirement and supports JSON. https://github.com/twitchtv/twirp https://github.com/twitchtv/twirp I do think twirp code could be refactored and made a lot better though.

stock_toaster 8y ago
If twirp had more existing backend implementations, I would certainly use it for more things.
- zbentley 8y ago
  Check out Thrift: https://thrift.apache.org/ https://thrift.apache.org/

z3t4 8y ago

Has anyone gone from plain text JSON to protobuffer (over Websocket) ? How much bandwidth did you save, and was it worth it ?

gregwebs 8y ago

I am using the HTTP Gateway and generating OpenAPI from that for type-safe access [1]. The downside is that this introduces an additional build step in your project. The upside is supporting a JSON API and not requiring gPRC(-Web) for clients. Even for non-browser clients, GRPC tooling can still be a little heavy-weight to pull into your project compared to OpenAPI. On the other hand, not all languages have good OpenAPI integration. But its also quite possible to use both. [1] https://github.com/gogo/grpc-example https://github.com/gogo/grpc-example

ilaksh 8y ago

How does this compare to JSON-rpc or GraphQL or just using JSON to send custom messages over HTTP 1.1 or HTTP 2?

jhabdas 8y ago

Truly amazing. Death to JSON!

polskibus 8y ago

What's the advantage of gRPC-Web to someone in the .NET world that uses Typescript, and generates TS schemas from .NET POCOs ?

zbentley 8y ago
Protobufs (the transfer format of gRPC) include not just a schema, but a transport format that may be more efficient than a serialized POCO. gRPC also allows you to encode communication semantics (i.e. "What does this endpoint want as arguments? What does it return?") and generate both client and server code that complies with (and automatically [de]serializes and validates protobuf data for) those semantics. It's the difference between a schema definition and a schema definition + serialization format + service (not just data) definition/codegen.