My team has been using gRPC + Improbable's grpc-web [0] + Typescript for a green field project and it has been amazing.<p>- Typing all the way to the frontend.<p>- gRPC/protobuf forces you to describe your interfaces and are self-documenting.<p>- gRPC semantics like error codes and deadlines (if you propagate them through your stack, they're particularly useful - for instance, we cancel database transactions across service boundaries if a request times out).<p>- Performance is great (but we're far from seeing bottlenecks with JSON, it's not the reason we choose gRPC).<p>- We use grpc-gateway which auto-generates a REST proxy for our customers. We sometimes use it for interactive debugging. [1]<p>- Rather than importing database models for our management tools and one-off scripts, using the API is so frictionless that we even use it inside our backend code and for CLI utilities.<p>The Google API design guide is helpful: <a href="https://cloud.google.com/apis/design" rel="nofollow">https://cloud.google.com/apis/design</a><p>One piece of advice: Treat your gRPC calls like you would treat a GraphQL resolver - if you squint your eyes, they're very similar concepts.<p>Rather than specifying a GraphQL query, you specify a Field Mask.<p><a href="https://developers.google.com/protocol-buffers/docs/reference/csharp/class/google/protobuf/well-known-types/field-mask" rel="nofollow">https://developers.google.com/protocol-buffers/docs/referenc...</a><p>Happy to answer questions on our experience.<p>[0]: <a href="https://github.com/improbable-eng/grpc-web" rel="nofollow">https://github.com/improbable-eng/grpc-web</a><p>[1]: <a href="https://github.com/grpc-ecosystem/grpc-gateway" rel="nofollow">https://github.com/grpc-ecosystem/grpc-gateway</a>
Web has come a full circle. First we disgust and hate SOAP XML and friends. Then we go to REST and realize of it's too loose! Then we invent stuff like Swagger and JSONAPI in order to put some interfacing in place. And then we bring in cripples that give similar but water downed features of SOAP, GRPC, GraphQL and more friends.<p>Edit: I know I might get downvotes but think for a second we could have just taken some good parts from SOAP to begin with and have all the goodness.
We built out our gRPC services starting about 8 months ago. I pounded my fists on the gRPC-web issue board a bunch of times. Things started moving. In the end, it was too little and the effort is too divided. Also the route for which they wanted to implement streaming was, personally, poorly designed.<p>We have since switched to GraphQL and haven't looked back.
Could someone explain the difference between gRPC and Apache Thrift? Even tough the Apache Thrift project is not as active as gRPC it works quite well for us.
Slight off topic, but has anyone executed gRPC on a C platform for embedded? I'm willing for forgo the automatic code generation - but hell if there are any good resources I've been able to find on this.
I am using the HTTP Gateway and generating OpenAPI from that for type-safe access [1]. The main downside is that this introduces an additional build step in your project and a small amount of additional run-time processing.
The upside is supporting a JSON API and not requiring gPRC(-Web) for clients. Even for non-browser clients, GRPC tooling can still be heavy-weight to pull into your project. Not all languages have easy to use OpenAPI integration, but any language can always just send some JSON.<p>But with the HTTP Gateway you are actually supporting both, so a browser client can still use GRPC-Web if it is able.<p>[1] <a href="https://github.com/gogo/grpc-example" rel="nofollow">https://github.com/gogo/grpc-example</a>
One other that helps JSON/REST to remain defacto these days, is not just a web browser support.
But also nice mobile clients like Retrofit.<p>Retrofit seamlessly converts JSON data by means of json de-serializer, into Java classes.
So we get typefull semantic (but, albeit at run time only).<p>I have retrofit integrated with RxJava, and when I looked what it would take to 'plugin' gRPC, I found that I have to change not just my backend, but all the wiring for the mobile frontends. And, at the time it looked like too much work.<p>If Retrofit, would make it transparent JSON vs gRPC -- then it would be great for folks that already invested into Retrofit/JSON.
gRPC is two things to me (please correct me if I'm forgetting something):<p>- A specification language for services and the RPC calls they take (except RPC response primitives include single message and stream)<p>- A binary object definition/packing scheme (aka protobuf)<p>Outside of the HTTP and what HTTP/2 makes possible, I feel vaguely like everyone is rushing to replace pure HTTP/HTTP2 (and HTTP3 in the future) with something that is less extensible and could be implemented <i>inside</i> HTTP for the most part.<p>Obviously you can't do anything about the inefficiencies of headers in HTTP/1 (this is better in HTTP/2 & 3), the lack of built-in stream semantics (again only HTTP/1 though you can make do with some longpolling/SSE/websockets scheme) but outside of the HTTP stuff you can absolutely transmit your content as a stream of tightly packed bytes and let consumers do whatever they need to...<p>Why is gRPC anything more than a content type? It's so weird to see gRPC evolve from (in some sense, I might be wrong) HTTP + HTTP/2, and now people trying to shoe horn it back into the browser.<p>It's really hard to find metrics (maybe I should do a comparison and post results I guess), but like in this SO post[0]. The hype train is presenting gRPC as the <i>next</i> thing, but it shouldn't be, IMO. Most of the improvement is from use of <i>protobuf</i> for more efficient (de)serialization -- and I don't think gRPC is the best tool for declaring API schemas (RPC or otherwise) either.<p>[0]: <a href="https://stackoverflow.com/questions/44877606/is-grpchttp-2-faster-than-rest-with-http-2" rel="nofollow">https://stackoverflow.com/questions/44877606/is-grpchttp-2-f...</a>
Has anyone considered using this or something else for IPC – that is, communicating between memory boundaries in the same application (e.g., Node/web, Swift or C# to a web container, etc.)?<p>Even just for Electron the built in IPC API doesn’t really cut it long term since you don’t get typing nor proper request/response or topic based streaming support so bugs are more likely to sneak in.
The state of gRPC on the browser is the main reason why my company selected Twirp instead. Being able to natively call a simple HTTP endpoint with a JSON payload is fantastic; its the benefits of protobufs when you can use it, with a graceful fallback for clients that need normal HTTP. Of course you can get this with grpc-gateway, but now you have two things to maintain.
I've had issues with npm and binaries of gRPC in firebase related to node versions and electron versions. It seems like this could be a good alternative if it was used in firebase since it's implemented in typescript - not sure I completely understand it, though.
I'm quite surprised they're not using websockets for streaming. Anyone know why?<p>EDIT: Better question: is anyone aware of a system like gRPC but built with bidirectional streaming for the browser from the beginning?
Another team at my company developed a microservice that uses gRPC that my team depends on and it’s been an absolute nightmare. Protobufs are just too limited in what they can do to make them useful except in very specific, narrow cases.