Comment by lima | Hacker News Reader

Comment by lima | Hacker News Reader

Parent Full thread

My team has been using gRPC + Improbable's grpc-web [0] + Typescript for a green field project and it has been amazing.

- Typing all the way to the frontend.

- gRPC/protobuf forces you to describe your interfaces and are self-documenting.

- 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).

- Performance is great (but we're far from seeing bottlenecks with JSON, it's not the reason we choose gRPC).

- We use grpc-gateway which auto-generates a REST proxy for our customers. We sometimes use it for interactive debugging. [1]

- 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.

The Google API design guide is helpful: https://cloud.google.com/apis/design

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.

Rather than specifying a GraphQL query, you specify a Field Mask.

https://developers.google.com/protocol-buffers/docs/referenc...

Happy to answer questions on our experience.

[0]: https://github.com/improbable-eng/grpc-web

[1]: https://github.com/grpc-ecosystem/grpc-gateway

Were you able to find a good javascript or typescript gRPC client? The official google one seemed to have spotty documentation for the js module itself. It did not look like it supported promises or Nodejs streams either.

We use the Improbable grpc-web client (linked in the post), plus a thin promises wrapper. We haven't used gRPC from NodeJS (you wouldn't need the grpc-web detour since NodeJS can just speak the "real" gRPC protocol).

Does converting gRPC into a JS object has better performance than converting JSON into an object?

Is it still necessary to use a REST proxy when using protobuf from the browser?

No - it's just there for customers who want a REST API. We don't use it outside of tests and development.

lima - great points.

Questions:

1) If you have TS on the front and back end - you already have de-facto typing. Why did you opt for gRPC over just some kind of basic serialization, even JSON? I

2) If you have TS classes, then you need to maintain a set of Protobuff service definitions as well - do you find this was a lot of duplicated overhead?

3) gRPC seems to me to be a little 'internal', not quite a web tech meant to be shared between parties. Did you have trouble with authentication, especially with 3rd parties? Or other 'cross-cutting' concerns?

I'm literally looking at doing what you're doing, any feedback would be greatly appreciated.

1) I forgot to mention - the backend is written in Go. Even if both were TS, all of the interoperability and other advantages will apply.

2) The TS classes are auto-generated and the protobuf definitions are the only authoritative definition.

3) We're using JWT for authentication (in particular, short-lived tokens issues by Keycloak, using their JS library). gRPC has request metadata and it was straight-forward to use it with the Keycloak library.

We generate client libraries for customers to use and give them the option of using the REST API if they don't want to deal with gRPC. We consider the gRPC API to be a competitive advantage - our customers are enterprises and like well-defined and typed interfaces.

Hey, sorry if this is off-topic, but how have you been finding Keycloak? This is the first time I've seen it mentioned on here, and it looks like a great auth solution at first glance.

Keycloak has been great.

- Very complete OpenID Connect implementation.

- Back-channel logout.

- Short-lived tokens and lots of tooling to handle refreshing them. This solves many of the issues associated with JWT expiration.

- Documentation is very complete.

- Their data model allows for very fine-grained access control - you can issue sub-tokens with limited scopes, limit scopes per client and so on.

- Easy to deploy in OpenShift/k8s.

Only pain points are the build process (Java has got nothing on NodeJS as far as number of dependencies go!), data migrations and the fact that it's written in Java (start up time in CI).

Thanks a lot, great to hear!

I use it and it's great.

Excepting jwt this is what we are doing. Typescript has been a blessing when used this way, especially for merges.

To address all of your questions:

One of the biggest selling points of gRPC (or many of the protobuf based systems, like Twirp) is that there's a huge community of people building code-gen tools for the API and Client out of a .proto file. What this means is that you can auto-generate a typescript library in one command, then publish that to npm.

There's an implicit guarantee that, if the TS client library and, say, the Go backend, are both "the same version" of the API (meaning, generated from the same .proto file), you'll get full API compatibility. And its not just "the frontend is assuming the response is of type T" or "doing schema validation on the response once you get it to make sure it conforms to a type the frontend defines independently"; the client lib and the backend lib are both generated from the same source of truth.

This exists with something like OpenAPI, but Protobuf is much simpler. And then you layer something like gRPC on top of that to get all the HTTP2 benefits, and its obvious why its gaining popularity.

That being said, to the third question: There's a huge advantage in those auto-generated client libraries. That's literally how libraries like the Google Cloud SDK are made; autogenerated from protobufs. But, if you use gRPC, the state of using that on the frontend natively sucks. So its got pros and cons.

Personally, we've opted to use Twirp instead of gRPC for the time being. Its all the advantages of protobufs, but it creates an API that is easily callable by web clients because its just a simple HTTP endpoint with a JSON payload. The only big thing you lose is the HTTP2 streaming, which might come one day.

> - Typing all the way to the frontend.

...where it is transpiled to ES5... :(

Reply on news.ycombinator.com