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

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.