(no title)
grosskur | 3 years ago
For personal projects, I typically have a single Go binary that serves (1) gRPC, (2) grpc-web (using the Improbable library), and (3) gprc-gateway. Along with protobuf-ts for the client, IMO it's quite a pleasant stack. Glad to see timostamm involved in protobuf-es :)
I'm curious: Can you say more about why you ported the code generator from Go to TypeScript (https://github.com/bufbuild/connect-web/commit/8002c2696aad0...)? Was it is easier to generate code this way, or did it just get too unwieldy to package Go binaries in NPM modules?
akshayshah|3 years ago
We ported the code generators to TypeScript because - as you guessed - it was a bit of a pain to package them for NPM. We also felt that it would be more approachable for TypeScript developers to read, which we hoped would contribute to a sense that all of this isn't actually all that complex. We were a bit worried that performance might be perceivably worse, but the difference wasn't significant.
lf-non|3 years ago
However I do miss being able to inspect the traffic in devtools, and the TS sdk is still not ESM friendly and requires jumping through hoops to get working with vite.
So we ended up bundling it separately through esbuild (along with other google protobuf deps etc.) to a large single file ESM module that other projects can easily consume.
Buf seems to be a solution that handles all of this better. Very excited to try this out.
[1] https://github.com/improbable-eng/grpc-web