supabase-architecture-variants

# Supabase Architecture Variants ## Overview Different application architectures require fundamentally different Supabase `createClient` configurations. The critical distinction is **where the client runs** (browser vs server) and **which key it uses** (anon key respects RLS; service_role bypasses it). This skill provides production-ready patterns for five architectures: **Next.js SSR** (server components with service_role, client components with anon), **SPA** (React/Vue with browser-only client), **Mobile** (React Native with deep link auth), **Serverless** (Edge Functions with per-request clients), and **Multi-tenant** (RLS-based or schema-per-tenant isolation). ## Prerequisites - `@supabase/supabase-js` v2+ installed - `@supabase/ssr` package for Next.js SSR (v0.5+) - Supabase project with URL, anon key, and service role key - TypeScript project with generated database types (`supabase gen types typescript`) - For mobile: React Native with Expo or bare workflow ## Step 1 — Next.js SSR (App Router with Server and Client Components) Next.js App Router requires **two separate clients**: a server-side client using cookies for auth (with `@supabase/ssr`) and a browser client for client components. Never expose `service_role` to the client. ### Server-Side Client (for Server Components, Route Handlers, Server Actions) ```typescript // lib/supabase/server.ts import { createServerClient } from '@supabase/ssr' import { cookies } from 'next/headers' import type { Database }...