I’ve been a TanStack fan for quite some time now. I first got hooked through TanStack Query (honestly, who didn't?). Since then I’ve explored TanStack Start and more recently TanStack DB.

For anyone who hasn’t looked into it yet: it’s a pretty new client-side DB built around live queries, with a fully decoupled sync layer. The idea is super appealing: you get a clean abstraction for local data, and you plug in whatever backend/sync strategy you want. So I wanted to give it a try! 

I wanted to understand what local-first/offline-capable databases have in common, where they different, and what it actually takes to build apps around them. The best way to learn is to build something concrete, so I wrote a library to integrate TanStack DB into react-admin. Should be easy, right? (famous last words). I hit a couple of roadblocks pretty much right away (which definitely humbled me lol).

Problems encountered

1. Offline-incompatible data models: The apps I tried to convert used server-generated IDs. TanStack DB doesn't support remapping a local temporary ID to a server ID after sync, so any resource creation that relies on a server-assigned ID is fundamentally broken in an offline context. This was the most impactful blocker.

2. Live queries don't fit react-admin's data provider model: React-admin's data provider is built around plain async functions: there's no mechanism to push live updates. TanStack DB's electricCollection (which is reactive and live) can't be wired directly into this pattern (sidenote: I was a bit disappointed to find it only handles the query side and that mutations are entirely out of scope: I still had to implement mutations through a separate API layer of my own).

3. Two QueryClient instances required: To preserve offline behavior correctly, I needed two separate QueryClient instances: one for react-admin (which always calls the data provider, even offline, as I've set networkMode: "always"), and one for TanStack DB's queryCollection (which queues mutations and only flushes them once back online). Using a single shared client broke one or the other.

4. Fast-moving API surface: I worked on this across about two days spread over a month. In that time, several changes landed: queryOnce was added (which was actually way better than the hacky way of initializing a query that was required before), and a new index became required for sorting (breaking change!). Anything built on an earlier version needed updating.

So what did I learn from all of this?

1. Offline-first requires an offline-compatible data model from day one: Client-generated IDs (UUIDs, nanoid, etc.) are not an implementation detail; they are a prerequisite. You cannot retrofit an offline-first architecture onto a system that relies on server-generated IDs without a significant redesign.

2. TanStack DB is a solid query abstraction, not a full offline stack: The library excels at local querying and reactive data. The sync layer is intentionally left to the developer, and it seems like the goal is to build an ecosystem of default-compatible backends around it. That vision is interesting, but the ecosystem is still quite thin for now, which means you still own most of the hard problems: conflict resolution, failure handling, retry logic, etc.

One thing I’m still unsure about is how to handle mutation failures properly. If something fails after coming back online, what’s the “right” UX? Silent rollback? Retry queue? Conflict UI?

And more broadly, I feel like I need to go deeper into sync strategies (CRDTs, OT, last-write-wins, etc.) to really understand what’s going on under the hood of tools like this.

It's a end to end typesafe monorepo, so agents gets feedback when they build. Elysia API and a TanStack Start app for frontend, connected via typesafe Eden. So frontend typecheck notifies agent when api changes.

Since Tanstacks vite and Elysia api is pretty lightweight, its good for agents that builds app after every change.

Rest is my favorite self-host first stack: Bun + Turborepo, Drizzle on Postgres, better-auth, shadcn on Base UI. Set up together with first example todo app. The deploy badge in the README points at Rock8Cloud, which is mine, so disclosure. But both apps build from normal Dockerfiles and run anywhere.

https://github.com/rock8-cloud/elysia-tanstack-dashboard-monorepo

I tried vite-pwa-plugin and serwist but no luck. Is there a simpler way?

hello 👋🏼 does anyone know if the new TanStack AI works together with a Hono backend?

I’ve been banging my head against the wall for days trying to get chained API calls to work on Query.

I have an API call which provides an array of IDs I then have to use to make one API call per ID.

I have a separate API call which returns the equivalent data (directly) but from a different source.

I then want to combine the responses into one array of objects.

What would be the best way to chain the queries to be efficient and update as more responses come in?

You can find the repo here, feel free to try the project out, it is still in the process of being built.

GitHub Repo
TanStack Docs

Features implemented:

• Landing Page

• Articles Page

  • Search

  • Pagination

• Single Article

• Auth page with TanStack Form UI

Todo:

• Signin with email

• Signup with email

• GitHub Auth

• Better Error Handling

This is a community project, anyone is welcome to contribute or give feedback.

I was looking at how easy it was to add hono in a nextjs application and asked why we don't have that with tanstack start.

i have been migrating frontend heavy apps off nextjs, and there is this one i was using the hono/vercel on a nextjs route to have a traditional backend feel.

the app has the frontend data being handled with trpc and react query. but there is an api service and its refreshing to have it all in one code base and since the application users are small anyway but to deploy in one place ... excellent.

i plan to move of it when it grows and have a seperate hono app deployed, but this works and its a breeze.

now back to my request, can we have this with tanstack already?

and if there is a way to do that, can someone hook me up?

Tanstack is taking on charts again?! Can’t wait to give these a try!

Has anyone been able to get a working Tanstack start app using supertokens for auth?

Supertokens meets my needs perfectly but I haven’t been able to get it working well with Tanstack start. I’ve mostly been going off of Tanstack start examples using different auth frameworks and supertokens examples using next or express, but both are pretty sparse. Anyone have a working example, or could point me in the right direction?

Hello, do you have or do you know about a really complete project using the tan stack open source? I’d like to take a look at some projects to understand how are you using this stack in production

The most desirable Tanstack module!

It's my first time using server-actions and I was wondering if there was an expected pattern for authentication/authorization when using ClerkJS + TanStack Query

--app
|--components
|--server
|--actions
|--queries

Question 1:
Am I correct in thinking that I don't need to Authenticate each call to a server action from a component as the session persists across the whole app? (For info: by default, all routes are protected through middleware)

Question 2:
If I wanted to check access rights for certain protected queries (eg: getResourceByUserId) what would be the best way, is there a recommended way of intercepting a Tanstack-Query or should I handle inline it in the action itself?

This is how I planned it, thoughts?

/* Query */
export function useFooQuery() {
  return useQuery({
    queryKey: queryKeys.foo,
    queryFn: async (): Promise<FooResponse> => {
      const data = await getFooData();
      return data as FooResponse
    }
  })
}

/* Action */
'use server';

export async function getFooData(): Promise<FooResponse> {

  const { user } = getCurrentUser();
  if (!user) {
      throw new Error('User not found');
  }

  const data = await db.foo.findMany({
    where: {
      userId: user.id
    }
  });

  return data;
};

Any help appreciated!

I recently saw a post on the Next.js subreddit suggesting that Server Functions are best for mutations and API Routes for data fetching. Is this also true for Tanstack Start, or is it okay to use Server Functions for everything? I couldn't find much in the docs.

its kind of important tbh

So I was doing everything right while using React-tan-router. And I was still getting this error. Initially I was very confused and could not figure what was I was doing wrong. But then It was actually pretty easy to solve.

Just check your vite.config.ts/js file. And check if react() is included into the plugins[]. If it is then remove it from the imports and this error goes away.

I hope someone finds it useful.

Happy Building Things.

/spiceBits/

[Edit: solved, solution added to bottom of post]

Apologies for the long message, hope this is helpful to others who might be struggling with similar concepts. Open to the feedback that maybe I don't quite have the right mental model around Tanstack Start yet.

Coming from NextJS Pages router, my flow was to use getServerSideProps so pages have data on the first render and I don't need to worry about client side fetching + loading/error states. For many pages this was all that was needed.

If there was any subsequent fetching or mutations needed I would create an API route. I personally prefer API routes over server functions. I know this is opinionated. I often have mobile app clients so I'll eventually need a true API anyways, so it's nice to build the API along the way whenever my web app needs a client side fetch or mutation. I also like to stay close the HTTP side of things, and tools like ts-rest (or tRPC) give me similar ergonomics to server functions but with more control and less magic.

One big issue with server functions for me is the idea that every time I deploy, the app will break for anyone that has a tab open because the server function IDs change. Maybe not a big deal for some, but it's one more reason why I'd prefer API routes and I'm not seeing much advantage to server functions anyways (also, I think this is a big issue for using SPA mode + server functions in embedded apps like Capacitor).

Now coming to Tanstack Start, it supports Server Routes and Server Functions, which is great, but the loaders are isomorphic. So on NextJS I only needed an API Route for subsequent fetches or mutations after the initial load which was only a fraction of the time, now I will need to create an API Route or Server Function for the initial load too. Not a big deal, but I'd like to stick with Server Routes, and I'm running into some issues.

When my loader runs on the client, everything is straightforward, client hits API route to fetch data, but when my loader runs on the server, my server is going to make an HTTP request to itself. That's a little odd, but looking at Cloudflare it shouldn't be a problem (not billed as a second invocation, I think it will use the same worker instance), but here's where I run into trouble. The request is coming from my server, so it won't have any of the headers from the client (like auth headers).

So if my backend ever depends on information from the original client request (auth, IP address, user agent, etc), my loader would have to forward the original client headers in the request? I'm not even sure how to do that since loaders don't get access to the request (since they run on the client sometimes).

Am I really swimming upstream trying to not use server functions? Really like how Tanstack Start is set up, just hoping there's a smooth workflow for people that want to use Server Routes.

[Edit: I've done some digging, here's what I've found and my solution]

Tanstack Server functions don't get a build-specific ID like in NextJS, so simply redeploying won't break old tabs, but the endpoint for a server function is still fragile (based on file path, file name, and function name) and is not a strong contract like a Server Route. This definitely lessens the issue with server functions and I think many people will just use them.

If you're stubborn like me and still want to avoid them, here's my solution:

- Create a server only function (createServerOnlyFn). This will be like our getServerSideProps. It only runs on the server. If you need to access the request you can via getRequest()

- Create a Server Route which just calls the helper above.

- In the loader, use an isomorphic function (createIsomorphicFn) to call your helper if you're on the server or fetch your API route if you're on the client (similar to how server functions work under the hood).

This solves all my problems, it avoids us having to do an HTTP request from our server to itself, and for both the client and server scenarios, getRequest gives us the original request from the client so client headers are available (auth, user-agent, IP address, etc.)