frontend

Frontend — Supabase Client Integration

Connecting frontend applications to the Supabase backend. Client initialization, RPC calls, auth state, routing, data fetching, forms, and type safety.

The CLI scaffolds a single frontend: React + TanStack Start in SPA mode (Vite under the hood, file-based routing via TanStack Router, TanStack Query for data). It ships as a fully client-rendered static SPA — no server. Because it's built on TanStack Start, server-side rendering is a config switch away later, with no route rewrites (see Rendering).

Client Initialization

Scaffolded by the CLI in src/lib/supabase.ts. Uses @supabase/supabase-js directly — the app is client-rendered, so there's no server client to configure:

import { createClient } from "@supabase/supabase-js";

const supabase = createClient(
  import.meta.env.VITE_SUPABASE_URL,
  import.meta.env.VITE_SUPABASE_PUBLISHABLE_KEY,
  { db: { schema: "api" } }
);

The data API schema is always api ({ db: { schema: 'api' } }). Env vars use Vite's VITE_ prefix and are read via import.meta.env — this holds even in TanStack Start SPA mode, since the build is Vite-based.

The real scaffolded lib/supabase.ts adds two things the snippet above omits, and you should not strip them: a lazy Proxy so importing the module has no side effects (the SPA prerenders the route graph on the server), and a global fetch wrapper that injects the x-workspace-id header on every request from the active-workspace store. That header is the whole 2.0 workspace model — see Auth on the Client. It also sets auth: { flowType: "pkce", detectSessionInUrl: true } for the email-confirm callbacks.

---

Environment Variables

The scaffold uses Vite's VITE_ prefix, read via import.meta.env:

Variable	Purpose
VITE_SUPABASE_URL	Supabase API URL (client-safe)
VITE_SUPABASE_PUBLISHABLE_KEY	Publishable key (client-safe)