Any good practices for creating trpc queries/mutes that don't use Prisma, in a t3 app that does.
From my understanding adding Prisma to the context of a router at it's base (createTRPCContext), results in the Prisma client being present in all sub routes used by that router, but we don't always need access to it so it's slowing down some serverless functions unnecessarily.
Currently trying:
Separate Routers : Creating separate tRPC routers with different contexts (one including the Prisma client). - we lose some DX because of having to prefix/separate the api , potential semantic name conflicts, makes defining sub routers more verbose. - doesn't seem like SOA in the trpc examples is useable for this as it needs common context for routers. Middleware : adding Prisma client to the ctx object using middleware and then using pipe where necessary to create additional middleware. - Will this have any known performance drawbacks on sub routes that actually use this middleware vs putting Prisma client in the base ctx of the router? - Will this actually achieve goal, i.e. does the entire router get sent to the serverless function or just the specific query/mutation. ( my current understanding is just the query/mutation, am I wrong)New to t3-stack & loving it any advice would be appreciated ty : D
4 Replies
Middleware is a great way to do this
Personally for more complex projects I define procedure types at the top of each subrouter
So I have a “custom” base procedure
And then a subrouter might have some kind of procedure that is this + middleware
That being said I’m not actually sure if the default build step is smart enough to build your lambdas optimally
Let me know if you try it!
oki sweet, I'm using currently using the separate router approach cos I know that will definitely not build with the Prisma client but I'll test the middleware approach to see if there's any time diff, need to find a good way to test lambdas though (i.e. whether was cold or warm when function called) new to serverless coming from docker >_<. Thanks for tips : D
I feel like you need to hit a completely separate endpoint in order to achieve this. I guess easiest way is to test it out yourself
If you use the same endpoint but different routers, you’d still expect the one route pulling in Prisma to add the binary to the final bundle
This seems to be the case from testing, seems good from the perspective of low traffic queries because will get less cold starts, so as long as the trade-off for the bundle size is acceptable.
Yeah I think only way to use separate contexts using the separate routers approach is to hit a separate endpoint, because the router passes the context from the base router at the endpoint to all sub routers so any sub routers context must be a subset/transformation of the base routers context, (won't throw type errors but any new items that aren't a subset/transformation will be undefined).
ty OwO