Custom server support for TanStack Start

[TrevorBurnham]

I'm considering migrating a project from Next.js to TanStack Start, but I've hit a roadblock: I'm running Next.js behind an Express.js server for various middleware, which Next.js makes straightforward with their custom server feature. I don't see any analogous way to run TanStack Start within an existing Node.js process.

This may be a limitation of Vinxi, which can be started programatically but doesn't have any way to route calls to it programmatically AFAICT. Perhaps this feature could be added to the roadmap as a goal to achieve when moving away from Vinxi?

My use case may be a bit niche, but I imagine that being able to run behind Express.js would make gradual migration away from Next.js easier for lots of folks: You could have Express.js send requests for supported routes to TanStack Query and send all other requests to the old Next.js server as a fallback.

[TheOrdinaryWow]

I think this is needed. I want to use rust as a backend, so it'd be great to integrate with custom server.

[delambo]

This is also a requirement in our investigation for a nytimes.com framework replacement. A custom server is a must for enterprise sites.

[schiller-manuel]

this should already work with the node preset: https://nitro.build/deploy/runtimes/node#handler-advanced

[delambo]

Thanks for the info! From my investigation, Nitro is going away? Will that mean that the Vite server.js file will be the application server for Tanstack Start in the future, or a similar integration?

[schiller-manuel]

nitro will go away at runtime, but will still be used for building the deployment artifacts. however i think for the custom server case, we could just not use nitro at all (not even for building). let me think some more about that.

[danny-avila]

Hi @schiller-manuel 👋

For the time being, can you give a minimal example of how to use the node preset, in particular for an Express.js server for various middleware as OP raised?

We have the same use case, it would be a great benefit to immediately re-use our existing, battle-tested authentication middleware, rather than maintain for 2 separate frameworks.