3 ms·

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 o

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.

lima 8y ago
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.
- lachenmayer 8y ago
  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.
  - segmondy 8y ago
    I use it and it's great.
  - lima 8y ago
    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).
    - lachenmayer 8y ago
      Thanks a lot, great to hear!
- foobiekr 8y ago
  Excepting jwt this is what we are doing. Typescript has been a blessing when used this way, especially for merges.
013a 8y ago
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.

lima 8y ago

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.

lachenmayer 8y ago
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.
- segmondy 8y ago
  I use it and it's great.
- lima 8y ago
  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).
  - lachenmayer 8y ago
    Thanks a lot, great to hear!
foobiekr 8y ago
Excepting jwt this is what we are doing. Typescript has been a blessing when used this way, especially for merges.

013a 8y ago

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.