> E.g. there's a type registry, which means you can't ever have the same proto type compiled by two different configs (it'll panic at import time). In a monorepo that's (potentially) fine, but for the rest of the world it means libraries can't embed the generated code that they rely on (if the spec is shared), which means they can't customize it (no perf/size/etc tradeoff possible), can't depend on different versions of codegen or .proto files (despite code clearly needing specific versions, and breaking changes to the generated code are somewhat common), can't have convenience plugins for things that would benefit from it, etc.
I actually forgot about this when writing the article. This is a major pain in the ass both in Go and Python and basically forces you to ensure than no 2 services have the same file called "api/users/service.proto". There have been multiple instances where we literally had to rename a proto file to something like reponame_service.proto to avoid this limitation.
> grpc-web never worked well for me.
connectrpc is good alternative for the client side libraries. The code it generates is much better than the one produced by grpc-web (and the 3-4 different plugins on the market for it). it also supports grpc-web encoding out of the box. we are still using grpc-web internally just with connectrpc generated clients. The frontend engineers were extremely happy when we moved from the grpc-web clients to but ones. The DX is much better.
> grpc-gateway works pretty well, though.
I think grpc-gateway is a decent choice if you are building REST api for internal use. It does feel like an unfinished product (well.. it is a community effort). Specifically if you decide to follow Google's AIPs guidelines (https://google.aip.dev/general) you may find that some things are not implemented. Another downside of it is that it can't produce OpenAPI v3.
Torq's frontend application is the cornerstone of our platform, serving as the primary interface for our customers' daily operations.
Many users engage with it extensively, often for hours on end, making it our most widely utilized user facing service.
It is no surprise that the most effective method for evaluating frontend changes is through hands-on visual inspection and interaction.
Inspired by platforms like Vercel and Netlify, we've decided to implement a preview environment generator into our CI pipeline, automatically creating fully functioning preview environments on our K8S cluster for each pull request in our frontend repository.
This has significantly enhanced our development process, allowing us to:
1. Craft more comprehensive and refined pull requests
2. Collaborate more closely with UI/UX designers and product managers
3. Execute end-to-end tests prior to merging changes into the main branch
To find out more, I invite you to read my latest article on Torq's engineering blog.