Endgame1013
Would you recommend tRPC’s usage in this case?
I’ve personally never implemented something like this with tRPC, but it does sound possible. Personally, I’ve found monorepos and shared packages to be a pretty major headache, especially as projects begin to scale (handling different typescript configs, cjs/esm, build steps, etc.). If you want to keep things tightly coupled and are confident you’re gonna be dealing with only typescript clients for the foreseeable future, then I’d stick with tRPC for this for sure. If not, GraphQL would probably fit this quite nicely.
Speaking from experience, tRPC is perfect for BFF (backend for frontend), but trying to extend it out to non-typescript clients (via openapi or something of the like) can really be a pain. GraphQL, on the other hand, solves this problem a bit more elegantly, since it’s mostly language-agnostic. But it does come with its fair share of tradeoffs, too. Pick your poison.
Speaking from experience, tRPC is perfect for BFF (backend for frontend), but trying to extend it out to non-typescript clients (via openapi or something of the like) can really be a pain. GraphQL, on the other hand, solves this problem a bit more elegantly, since it’s mostly language-agnostic. But it does come with its fair share of tradeoffs, too. Pick your poison.
7 replies