Multiple TRPC endpoints on same API, with discrete clients? Any gotchas?
I'm building a Sveltekit app that has several pages that will need to behave like SPA's. Rather than have one TRPC enpoint in the api routes, I'd like to divide each section of the app into it's own trpc server handler, and be able to call a discrete client for that portion. This would allow separation of concerns for each portion of the app. My plan is the following routes ( and maybe more as the app grows)
-
/routes/api/estimating/trpc/[...procedures]
- /routes/api/scheduling/trpc/[...procedures]
- /routes/api/reporting/trpc/[...procedures]
On the client I would create a separate client for each server route pointed to the corresponding URL. This would in effect create 3 distinct standalone TRPC servers in the app.
Any gotchas with this that anyone can see? Anyone done something like this?4 Replies
Why would you create more tRPC servers ?
Why I u do not have just one server, that server has 1/2…n routes that can do several things ?
I have one server and I created multiple routes for different things
what I was hoping for was having the multiple routers isolated per API route, so when you were working on the
estimating route you would only have access to the trpc procedures for that route. Just a level of isolation for development, so futures devs (ahem me) don't get confused and start cross cutting concerns. Also not sure if this holds water, but having separated routers might mean less load on the language server so I might be able to scale the project a bit more before trpc starts to bog down.
All just conjecture at the moment, but I'm curious how folks are doing things.I belive trpc dealing very well the routes
Also … nice try
Good luck
I am just a beginner with it
So..go ahead
I'm also kind of a beginner tbf, I used it for a little while just to see how it worked, and then started using form actions in Sveltekit when those came around. This was about a year ago, and I didn't get a ton of time with trpc. My biggest concern is committing to it, then finding out later that it's bogging down development earlier than I'm ready to start breaking the app apart into discrete services to get the perf gains.
We'll see, all opinions on the matter are welcome.