Moving tRPC out of Next

[adamspotlite]

Hey everyone! Big supporter of the amazing work @juliusmarminge has done here.

I began with this repo a couple months ago and as I've started ...productionizing things for my use-case it's come to my attention that there are a few benefits for separating out the api from running on next, principally for independent scaling + deployment + development.

However, I still really like the code completion / ease of use of that tRPC offers and would like to keep that DX. Ideally, I can wrap more or less the trpc/[trpc]/route.ts in some express/koa/whatever the newest framework is server, and start routing my requests there both from expo and the nextjs frontend, but keep the DX/typesafety currently offered.

Does anyone have any thoughts or experience on/with this? To admit my bias, I come as a former backend dev and still don't feel really comfortable with using Next endpoints for all my use cases, especially because my primary application is a mobile one and our webapp is very secondary.

[dBianchii]

Your Next.JS endpoints are usually and should usually be where you host your server.
However, I can understand that for some use-cases people might prefer to separate that entirely into its own backend package/app.

You can adapt the api package to export what you need to use on your new backend app. be it express or whatever it is. The main reason to have a separate api package is so that you can include that as a dev dependency in a frontend app and this way have access to the types tRPC will provide for your app router.
I believe you could in theory remove the api package and then export your tRPC type definitions from the main backend itself. As long as you install said backend as a devDependency.

Why are you skeptical of using the Next.JS backend? Is it just so you can fully separate frontend from backend?

[adamspotlite]

Thanks for the response. Would love to have a longer discussion about this.

Your Next.JS endpoints are usually and should usually be where you host your server.

For clarification, Is this to say it's common for nextjs applications to ship as a "full" nextjs app, i.e. that they don't normally separate out their backend?

You can adapt...

Exactly! It would more or less remove the apps/nextjs/app/api/trpc/[trpc] dir, replace that api client with something similar to what we have in expo/.../api.tsx using the type defs, and then deploy the trpc app using express/koa/etc in whatever format the team wants.

Why are you skeptical?

I've become a bit disenchanted with the abstraction layer nextjs provides in blurring the backend/frontend boundary. I find that it's too murky to get deeper insight into what is going on in my application... Granted, I am far from a nextjs wizard, but when things go awry on my server, I don't particularly like that my best option to debug is to dig into a single route file and cross my fingers that the nextjs deployment/build works to its spec. I personally would prefer to be a bit closer to the metal and have more control over deploying and scaling that part of the system separately.

--
Additionally, for other team members that aren't familiar with the nextjs ecosystem and come from a more traditional backend background, they've lamented the idea that their reach / flexibility is limited to just what next exposes and stuffing all things into next middleware.

--
I'm curious your take on the bull case for piling allll the things backend into the nextjs application? Personally, I find the simplicity of "just starting", some elements of DX, and abstracting away a backend for devs not as accustomed to backend dev to have been good value drivers... However, I'm much deeper into a project / company that is def not just a starter kit anymore, tRPC + tanstack provide a lot of the DX benefits, and I feel much more comfortable inside docker than outside of it 😄

Let me know your thoughts!

[juliusmarminge]

You could expose the trpc api on the auth-proxy server using Nitro if you want

[adamspotlite]

Right! Or theoretically any server, you just have to more or less wrap what comes out of packages/api in something that can handle http reqs, correct? Of which nitro is just the latest + greatest opinionated framework to help bridge backend to front end gap? (meant that sincerely, not snarky! 👍 )

[juliusmarminge]

Nitro is fairly nice from what I've tried.

Actually been considering this more and more lately, especially with the Expo auth PR having to work around csrf stuff with having the auth server coupled to next.js