Forem: simonxabris

SSR Authentication Across Subdomains Using TanStack Start and Better-Auth

simonxabris — Fri, 29 Aug 2025 08:21:41 +0000

TLDR: When using TanStack Start with authentication handled on a different subdomain (e.g., api.domain.com), fetching the user session directly in your SSR loader won’t work as expected because server-to-server requests don’t include browser cookies. To fix the header flicker and SSR the correct user state, create a server function that forwards the original request’s cookies to your auth server. Call this function in your loader to ensure the authenticated user is available during SSR, eliminating the flicker and improving UX.

The situation is the following, you're developing an app with Tanstack Start, you deploy it to app.domain.com, but you have a separate API server that handles logic and authentication using better-auth, which runs on api.subdomain.com.

You create a header in your app that displays the logged in user, but you see that when you log in and reload the app, the header flickers because initially it displays the logged out state and once the user data arrives, it flips to the logged in state.

Of course you're a good developer who wants to deliver good UX, so you decide to fix it by fetching the user on the server and then the proper logged in/out state will get rendered into the HTML and the flicker is gone.

What you do is you go and write a loader function like this:

export const Route = createRootRouteWithContext<{
  queryClient: QueryClient;
}>()({
  loader: async () => {
    const session = await authClient.getSession();

    return { user: session?.data?.user }
  },
  component: RootComponent,
});

and then in the RootComponent, you have access to user and can pass it to your Header or Navigation component, whatever you want to call it.

function RootComponent() {
  const { user } = Route.useRouteContext();
  return (
    <html>
      <head>
        <HeadContent />
      </head>
      <body>
        <AuthProvider>
          <Navigation user={user} />
          <main className="min-h-screen bg-background">
            <Outlet />
          </main>
          <TanStackRouterDevtools />
          <Toaster />
          <Scripts />
        </AuthProvider>
      </body>
    </html>
  );
}

Great, it was very easy, now you go and open your app to marvel at your excellence and then boom, the flicker is still there. You scratch your head, you have no idea what's going wrong (I know I didn't).

This is where if this article existed, it could have saved me quite a few agonizing hours, hope it can for someone else as well.

The problem is that when authClient.getSession makes a request to api.domain.com, this request is going from your server that is running tanstack start to your server that is running auth, which means there are no cookies involved here, since cookies are stored in the browser. This is where you might say, but hey, the browser is making the request to the tanstack server to render the page, so that request must have the cookies, right? If you said this, you're absolutely right, this is what we're going to take advantage of to solve the problem.

The solution is, you have to create a server function that fetches the user and then call that server function in your loader. I don't think this is documented anywhere (or maybe I haven't found it), but server function include all credentials like cookies from the original request the browser made, so you can write one like this:

export const fetchUser = createServerFn({ method: "GET" }).handler(async () => {
  const event = getEvent();

  const session = await authClient.getSession({
    fetchOptions: {
      headers: {
        Cookie: event.headers.get("Cookie") || "", // For brevity I copy all cookies here, but you might want to just parse out the auth cookie and send that.
      },
    },
  });

  if (!session.data) {
    return null;
  }

  return session.data.user;
});

call it in your loader:

  loader: async () => {
    const user = await fetchUser();

    return { user };
  },

and you're done. With this you can now get the authenticated user on the server and properly SSR your pages.

The design system struggle

simonxabris — Tue, 14 Mar 2023 18:00:06 +0000

Okay, so this post will basically be a rant about my experience working on a design system for almost 2 years now. I've failed to come up with a solution to this struggle, so I feel like I'll just write it out of myself and see if people out there are fighting the same thing and if they managed to solve it in any way.

The struggle cycle

The thing is I'm talking about is basically an endless cycle involving UX and engineering and it goes like this:

You work with a UX designer on the design system team and you come up with a design for a component, let's say an Accordion where there's text on the left side and a chevron on the right, something like this:
You go into your cave and implement this design with whatever fancy and cool stack your team is using for your design system. You come up with the best API ever, you feel very proud, UX approves your implemented component and you release it, you go to sleep.
Next day you wake up, have some breakfast, brew that perfect coffee and open slack and you see the following message: The Accordion is not working, how can I place the chevron to be on the right side of the text? After you survived your heart attack, you start to wonder, why on earth would they want a chevron on the left side? That's not at all how the Accordion is designed, so you ask the developer. The answer is that they got handed a design in let's say Figma, and they saw that there was an Accordion with a chevron on the left side, so they imported your Accordion component and searched for a way to place the chevron on the left side, but it was nowhere to be found. Of course it was nowhere to be found, since it wasn't a requirement, but now you're in a place where you are right because you implemented what the design was, the developer is right, because they just want to implement a design the were handed, so where did it all go wrong?

Understanding where it goes wrong.

Well, here's where it all goes wrong. In design tools like Figma, it's just too easy to customise a component. You pull the component in, you notice something you want to change, right-click, Detach and boom, you're free to do whatever you want to the design. You shift that chevron to the left-side (which by the way might be a valid change), you hand it off to your developer and onto the next one. Without proper organisation wide education on how to use the design system and a very disciplined approach from UX designers, this is bound to happen in every org. And by the time you, the developer on the design system team, catch this error, it's all too late. UX already spent a ton of time coming up with the design, they (understandably) feel attached to it, the developer on the product team also spent a bunch of time implementing that design and now you're faced with the following task.

The questions you have to deal with

You have to tell them that the Accordion is not supposed to be used like this, you have to involve your UX designer and you have to find the answer to a bunch of very tricky questions, usually in a short amount of time.

Does this change make sense in the context of the system?
Do you want to allow Accordions with chevrons on the left side company wide?
Should you add some escape hatch so that this team can move forward with their feature and hack the chevron to the left side?
If you add that, how do you make sure that it's not abused in other places and that your product(s) have a consistent UI?
Do you tell them that they have to stop the feature work and redesign it and live with the chevron on the right side? Does your team even have the political power to say something like that?

It's a big can of warms that get opened repeatedly, ultimately, because UX tools are not good at enforcing the constraints of the system on designers. If you faced this problem in the past, please leave a comment, I'm very interested in how other organisations solve this problem.