Framework-Router Fit For Spa-Like Ux And Version-Coupled Deployment
Sources: 1 • Confidence: Medium • Updated: 2026-04-13 04:03
Key takeaways
- T3Chat was migrated off Next.js to TanStack Start.
- There was an active investigation (including a call with Pouya and others) to determine the root cause of the TanStack route-loading failures, and the host considered rerecording content once more details were known.
- Cloudflare Workers bundle-size limits (about 3MB free and 10MB paid) were quickly exceeded by the team’s server-side code, making Cloudflare impractical without significant deployment complexity.
- On Vercel, because the hard maximum request duration was 800 seconds, setting the chat API route maxDuration to 799 seconds in Next.js forced Fluid Compute to provision it separately from other 800-second routes, isolating long-running chat requests from short requests.
- Julius independently initiated and drove the TanStack Start rewrite and selected it as the best solution for the codebase rather than following the host’s direct instruction.
Sections
Framework-Router Fit For Spa-Like Ux And Version-Coupled Deployment
- T3Chat was migrated off Next.js to TanStack Start.
- At launch, T3Chat used Next.js but replaced the Next router with a hacked-in React Router setup using rewrites to a static app shell.
- A primary original reason the team used Next.js was to deploy frontend and backend together from one codebase to keep versions synchronized.
- The team used Next.js in a client-first way, avoided Server Components, and aimed for SPA-like navigation speed after the initial JS load.
- The rewrite strategy initially broke tRPC traffic and required using a custom header so tRPC requests were not routed to the static app shell.
- TanStack Start’s routing approach combines code generation with TypeScript inference to provide type-safe route parameters and loaders that ensure required data is fetched before a route component renders.
Post-Migration Production Failures, Investigation, And Routing-Layer Decomposition
- There was an active investigation (including a call with Pouya and others) to determine the root cause of the TanStack route-loading failures, and the host considered rerecording content once more details were known.
- The solution required patching TanStack Start server core to expose a Nitro/H3 event binding so the team could bind and handle Nitro events directly for mixed Nitro and TanStack routes.
- Deployments encountered a recurring root-route error where Node’s undici-based fetch failed around approximately 60% rollout, causing server issues and clients not rendering.
- The team suspected that TanStack route lazy-bundling loaded route-specific JavaScript on-demand but retained many bundles in memory, and under high concurrency this could overload the server and resemble EMFILE ('too many files') behavior.
- As a mitigation, the team removed API endpoints from TanStack routing and relied on Nitro’s route handling for API resolution while keeping TanStack for the browser route experience.
- Configuring Nitro with a serverDir in Vite enables defining server functions outside TanStack route definitions, creating a split between server endpoints and TanStack routes within the TanStack Start setup.
Platform And Organizational Constraints Shaping Migration Options
- Cloudflare Workers bundle-size limits (about 3MB free and 10MB paid) were quickly exceeded by the team’s server-side code, making Cloudflare impractical without significant deployment complexity.
- The team explored leaving Next.js via Remix, React Router’s server approach, and a Vite+Hono rewrite targeting Cloudflare, but these paths were hindered by platform and documentation complexity.
- Vercel’s Fluid compute was said to have changed the economics of long-running AI generation requests by making scaling cheaper than a prior model where each user chat effectively consumed a dedicated Lambda.
- Because the team was very small and lacked dedicated infrastructure staff, managed deployment via Vercel was a practical necessity to preserve engineering velocity.
Request-Duration And Concurrency Isolation Tradeoffs On The Hosting Platform
- On Vercel, because the hard maximum request duration was 800 seconds, setting the chat API route maxDuration to 799 seconds in Next.js forced Fluid Compute to provision it separately from other 800-second routes, isolating long-running chat requests from short requests.
- Vercel’s Fluid compute was said to have changed the economics of long-running AI generation requests by making scaling cheaper than a prior model where each user chat effectively consumed a dedicated Lambda.
- In the TanStack/Nitro setup, the speaker stated that configuring maxDuration at a broader level appeared to bundle multiple APIs together and removed the prior ability to split the chat endpoint from other API endpoints, though APIs were at least split from TanStack Start routes and overall API call volume had been reduced by moving most data access to Convex and the chat endpoint.
Team Autonomy And Reduced Key-Person Dependency
- Julius independently initiated and drove the TanStack Start rewrite and selected it as the best solution for the codebase rather than following the host’s direct instruction.
- The speaker stated that post-migration the codebase was easier to understand and debug, routing was significantly improved, and implementation ownership had shifted from the host’s personal hacks to the team.
Watchlist
- There was an active investigation (including a call with Pouya and others) to determine the root cause of the TanStack route-loading failures, and the host considered rerecording content once more details were known.
Unknowns
- What was the confirmed root cause of the rollout-correlated undici fetch failures, and did the investigation produce a reproducible minimal case and fix?
- Did post-migration reliability measurably improve (incident frequency/severity, error rates, oncall load), especially for routing and client/server incompatibility issues?
- What was the net performance impact (TTFB, LCP, navigation latency) after enabling SSR and moving to the TanStack/Nitro architecture?
- Can per-endpoint duration and isolation controls be restored in the Nitro/Vercel setup, or is bundling an inherent limitation of the current configuration?
- How long will the team need to carry the TanStack Start server-core patch, and is there an upstream-supported alternative to avoid ongoing patch maintenance?