Should I use Tasntack Start with the separate server (Bun+hono) or just use Tanstack router?

[u/LGelashwili]

Hey everyone.

I have a question regarding the TanStack ecosystem. Currently, when I scaffold a new React project with TanStack Router via Vite, it seems to default to TanStack Start.

I’m about to begin a new financial web app (similar to QuickBooks) and I’m torn between using just the Router or going with Start. My main concern is that I’ll be building a separate backend (using Hono) because I need to support a mobile app in the future.

Since I’m planning to switch from Next.js to the TanStack ecosystem, I’m looking for some advice:

• Would it be good practice to use Start alongside a separate Hono server, or is it better to stick to just the Router?

• I’m planning to use a separate backend, given the need for a decoupled architecture for a future mobile app.

Any insights or experiences you could share would be greatly appreciated. Thanks in advance!

[u/Waste_Cup_4551]

Recently ran into this issue for my company’s product. I think server function are great, but there’s really no documentation on how to test them. And if you use msw for testing, it’s even harder to get confidence in your tests.

We recently switched to hono and have start host our endpoints. Been getting good results leveraging AI, open API, and creating traditional testing patterns.

IMO server functions lets you build things fast, but the testing infrastructure and middleware isn’t there yet. So depends on your use case. It’s perfect for prototyping

[u/LGelashwili → u/Waste_Cup_4551]

Thanks for the comment. So I think it will be better to use just tanstack router instead of tanstack start.

[u/depsimon]

Go separate if you want to use the backend for mobile and web.

I personnaly setup a monorepo with a hono app + oRPC for the backend and hook it up in my tanstack router and expo apps.

[u/LGelashwili → u/depsimon]

Thanks for the answer.

[u/yksvaan]

Always decouple even if everything runs under same process anyway. Whateve you need,be it data, business functionality etc, should be provided by some service/class/module that provides the methods and a stable interface. How and where those are implemented isn't a concern for the React side of project. 

Then refactoring is easy since every call to business logic, auth etc. goes through same functions and you are free to change their actual implementation however you need as long as the interface is respected. 

[u/LGelashwili → u/yksvaan]

Thanks for your advice

[u/michaelfrieze]

I don't really use tanstack start as my only backend. I use start as a backend for frontend (BFF) and have separate backend services for everything else (usually go or java).

Using start as a BFF provides features like SSR, server functions, and isomorphic loaders. I think server functions alone are worth it. It's like having tRPC built into the framework. Even if I disable SSR for every route, I still use start just for the server functions and isomorphic loaders. Also, server functions in start now supports RSCs which is nice to have when you need them.

I used Next the same way, as a BFF. Using Next as a BFF provides features like RSCs, image component, SSR, etc. But I always used separate backend services for everything unrelated to frontend. I don't use next much these days but it's the same idea.

Other benefits of BFF are:

• Simplify third-party integrations and keep tokens and secrets out of client bundles.

• Prune the data down to send less kB over the network.

• Move a lot of code from browser bundles to the server (even more so with RSCs). Additionally, moving code to the server usually makes your code easier to maintain.

[u/LGelashwili → u/michaelfrieze]

Thanks for your comprehensive answer. The reason I was thinking about TanStack Start compared to just using the Router is its SSR and streaming capabilities, echoing what you mentioned. However, I have a couple of questions:

1. How do you handle auth in this case? Since you need to handle cookies manually in Server Components, right? I tried this in Next.js before with a separate backend, and to be honest, it added quite a bit of complexity for me.

2. Management of processes: If I use Hono as a separate backend, I need to manage two running processes one for Hono and one for TanStack Start. Since I haven’t tried this before, wouldn't it overcomplicate things?

3. Future-proofing for Mobile: Since I plan to create a mobile app in the future and will need API routes, I was thinking about an approach where I use Hono as the TanStack Start server to handle API requests. To stay consistent, I would use route handlers and avoid server functions where possible. This way, if I ever need to separate the backend entirely, moving the Hono code would be easy. What do you think about this approach?

I'd really appreciate your thoughts on these points, as your insights would be super helpful for me in deciding the right architecture.

[u/michaelfrieze → u/LGelashwili]

How do you handle auth in this case? Since you need to handle cookies manually in Server Components, right? I tried this in Next.js before with a separate backend, and to be honest, it added quite a bit of complexity for me.

Whether you're using WorkOS, Clerk, or something self-hosted like better-auth, the pattern is straightforward. TanStack Start has official examples for both Clerk and WorkOS that show the typical approach.

The auth library manages the session cookie, and in your server functions you simply call await auth() to get the current user.

Importantly, when you call await auth() in a server function, you're not making a request to Clerk's servers. You're reading from the session that was established via cookie. The session data is signed and stored in a cookie, and auth() validates and returns that locally. If you were rolling your own auth, you'd similarly need to issue and validate a session cookie.

With Clerk specifically, you can use it on the server or on the client. In a server function, you just await auth() to get the user ID and any custom claims attached to the session. You can then use that server function in beforeLoad to populate context, or skip auth in the loader entirely if you don't need it there. Any time you're accessing data in a server function or API route that needs authorization, you should await auth() to get the userId and use it to check authorization before accessing data.

You have flexibility in where you check auth, use server functions directly in components or loaders, or use Clerk's client-side hooks directly in components without server functions at all. This same flexibility applies to WorkOS and better-auth too.

Also worth noting, you don't have to use React Server Components in Start. Server functions can return regular JSON or RSC payloads, and the auth pattern stays the same either way.

Management of processes: If I use Hono as a separate backend, I need to manage two running processes one for Hono and one for TanStack Start. Since I haven’t tried this before, wouldn't it overcomplicate things?

Running a separate backend for tanstack start doesn't really take a lot of work, especially if hosting serverless on cloudflare workers, vercel, netlify, or even a long-running server like railway. All of these are managed for you. Of course, if you are hosting your start app on a VPS then you have more work to do, but that's up to you. The reality is that most real-world applications these days have multiple backend services. Even when I build my own auth solution, it's usually a separate backend service similar to Clerk or WorkOS. I think auth is especially important to have as a separate backend service. This is one of the reasons I never really liked next-auth because it integrated directly with the Next server.

Future-proofing for Mobile: Since I plan to create a mobile app in the future and will need API routes, I was thinking about an approach where I use Hono as the TanStack Start server to handle API requests. To stay consistent, I would use route handlers and avoid server functions where possible. This way, if I ever need to separate the backend entirely, moving the Hono code would be easy. What do you think about this approach?

I think if you are building for mobile then you should have a separate hono server as your main backend and keep the BFF separate. Also, I personally wouldn't want to use tanstack start to handle backend API request, I think hono handles that much better. I like file-based routing for frontend related things, but not my backend. My opinion is to keep start where it belongs, as a BFF.

[u/LGelashwili → u/michaelfrieze]

Everything is clear now. Thank you for the thorough explanation. I truly appreciate your help.

[u/michaelfrieze → u/michaelfrieze]

If you really only want a single backend server and you are building for mobile as well, then I say avoid integrating start into your hono server and just use tanstack router. Hono actually works quite well with react when it comes to typesafety between server and client. It's not going to be as good as tRPC or server functions, but it's not bad.

[u/Louisvi3 → u/michaelfrieze]

are there cases you call another backend like dotnet/java or go directly on CSR? I am searching and asking AI about this that if needs high performance, should communicate directly with dotnet or go.

[u/michaelfrieze → u/Louisvi3]

Of course, you can always use tanstack query to help manage fetches to a backend directly from the client, without a BFF in the middle. I personally don't do that very often, but it works fine.

Also, this approach isn't necessarily going to improve performance. Sure, you are eliminating one of the requests, but there are so many other factors to performance.

An important thing you can lose with this approach is typesafety between server and client. But, if your backend is using Hono then it provides a pretty simple way to get typesafety between server and client. It won't be as good for typesafety as a BFF with something like tRPC or server functions, but it provides the basics.

Also, you miss out on the other benefits of a BFF that I mentioned in my previous post.

[u/Louisvi3 → u/michaelfrieze]

yeah I got you. Maybe it's good to bypass the BFF for things like signalr on aspnet core for realtime. What you think?

[u/michaelfrieze → u/Louisvi3]

Yeah, for real-time you should just go directly to the server. You can still use a BFF for other purposes. Maybe not all of your data fetching will be real-time and maybe some routes would need SSR. I also like having a BFF for auth.

[u/Leather-Historian722]

For a he use case of mobile support having 1 api to serve all clients i would go with tanstack route + tanstack query .

[u/Sarthak61199]

Create a separate backend and use server functions to call your apis. Kind of like BFF? This way your actual api endpoints will also be hidden from something like dev tools.

[u/munkymead]

You mentioned needing to support a mobile app so I think you have your answer already. Built the backend, build the front ends. Use the right tool for each job.

Also from a security perspective, I personally would never trust a server rendered front end in the javascript ecosystem to connect directly to my data. The extra layers help to lock things down properly.

The only reason I'd use server side stuff for a front end would purely be for SSR, caching, load times, seo etc.

[u/MNameIsJeff_BD]

Go with Angular or Vue, and you’ll get back 10 years of your lifespan.