Would you recommend tRPC’s usage in this case?
So we have two applications, one existing, one about to be started. These two applications will talk to an external API in the exact same way. The current application uses React Query to do so.
I’m thinking about creating some shared library/SDK/service (whatever you want to call it) so these two applications can consume the API in the same way.
I guess tRPC solves this quite well in some respects, have the tRPC client be it’s own package, have the two applications consume it.
The procedures in the tRPC client are going to to be making fecth requests to this external API though, maybe transforming the data so it’s more suitable/consistent for the consumer applications.
Anyone done anything like this? Or does anyone see this as being a good or really terrible idea?
Solution:Jump to solution
I think there's nothing wrong with creating a reusable piece of logic, but you say make the client its own package. Why the client? Personally I'd create a private package with only the common logic in it as an async function. No reference to even trpc. Then I'd install this package on both applications, and invoke the library function in a procedure somewhere in a router.
This way you can easily:
- Transform the results further.
- Have completely unique trpc configurations. ...
4 Replies
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.
P.s. I refer back to this graphic from Theo Browne whenever I’m picking backend infra for a project:
Solution
I think there's nothing wrong with creating a reusable piece of logic, but you say make the client its own package. Why the client? Personally I'd create a private package with only the common logic in it as an async function. No reference to even trpc. Then I'd install this package on both applications, and invoke the library function in a procedure somewhere in a router.
This way you can easily:
- Transform the results further.
- Have completely unique trpc configurations.
- Have different trpc clients / links
- Use the api call anywhere, even without trpc.
- Extend the library with other API integrations in the future.
- Have independent repos for the two apps and the library without any issues.
Thanks both for your input, that’s really helpful 👍🏻 Much appreciated 🙏🏻