supabase-architecture-variants
Provides blueprints for integrating Supabase into diverse stacks like Next.js, SPAs, and mobile apps.
Install
mkdir -p .claude/skills/supabase-architecture-variants && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/8266" && unzip -o skill.zip -d .claude/skills/supabase-architecture-variants && rm skill.zipInstalls to .claude/skills/supabase-architecture-variants
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Use when choosing how to integrate Supabase into a specific stack — setting up Next.js SSR auth flows, wiring an SPA or React Native client, configuring mobile deep links, or designing multi-tenant data isolation. Covers where the client runs (browser vs server) and which key it uses (anon respects RLS, service_role bypasses it). Trigger with phrases like "supabase next.js", "supabase SSR", "supabase react native", "supabase SPA", "supabase serverless", "supabase multi-tenant", "supabase server component", "supabase architecture", "supabase service_role server".Key capabilities
- →Configure Next.js SSR auth flows
- →Implement multi-tenant data isolation
- →Set up mobile client architecture
- →Manage service_role and anon key usage
- →Design serverless edge function clients
How it works
The skill provides architectural patterns for Supabase integration based on the client environment and required security level. It defines how to route requests between browser, server, and admin clients while managing RLS and session persistence.
Inputs & outputs
When to use supabase-architecture-variants
- →Set up Next.js SSR auth flows
- →Configure mobile client architecture
- →Implement multi-tenant data isolation
- →Determine client vs server key usage
About this skill
Supabase Architecture Variants
Overview
Every Supabase createClient configuration turns on two questions: where the client runs (browser vs server) and which key it uses (anon respects RLS; service_role bypasses it). This skill supplies production-ready patterns for five architectures — Next.js SSR, SPA, Mobile, Serverless Edge Functions, and Multi-tenant isolation.
Prerequisites
@supabase/supabase-jsv2+ installed@supabase/ssrpackage for Next.js SSR (v0.5+)- Supabase project with URL,
anonkey, andservice_rolekey - TypeScript project with generated database types (
supabase gen types typescript) - For mobile: React Native with Expo or bare workflow
Instructions
Pick the architecture that matches the target stack, then follow the linked walkthrough for the full, copy-ready client setup.
| Architecture | Client(s) | Key | Session storage |
|---|---|---|---|
| Next.js SSR | Server (cookies) + browser + admin | anon in-request, service_role server-only | HTTP cookies |
| SPA (React/Vue) | Single browser client | anon only | localStorage |
| Mobile (React Native) | Single native client | anon only | AsyncStorage |
| Serverless (Edge Functions) | Per-request client | anon (forwarded JWT) or service_role | none (stateless) |
| Multi-tenant | Any of the above | anon + RLS, or schema-per-tenant | per host pattern |
Step 1 — Next.js SSR (App Router)
Next.js App Router needs two separate clients: a server client that reads/writes auth cookies via @supabase/ssr, and a browser client for client components. A third service_role admin client is used only in Server Actions/Route Handlers and must never reach the browser. The browser client is the minimal skeleton:
// lib/supabase/client.ts
'use client'
import { createBrowserClient } from '@supabase/ssr'
import type { Database } from '../database.types'
export function createSupabaseBrowser() {
return createBrowserClient<Database>(
process.env.NEXT_PUBLIC_SUPABASE_URL!,
process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY! // anon key only — respects RLS
)
}
Full walkthrough — server client, admin client, middleware session refresh, server component usage, Server Actions, and the OAuth callback route: Next.js SSR patterns.
Step 2 — SPA (React/Vue) and Mobile (React Native)
SPAs and mobile apps both use a single browser/native client with the anon key; all authorization is enforced by RLS and the service_role key is never bundled. They differ only in session storage (localStorage for SPA, AsyncStorage for mobile) and OAuth handling (URL detection for SPA, deep links for mobile). Minimal SPA skeleton:
// src/lib/supabase.ts
import { createClient } from '@supabase/supabase-js'
import type { Database } from './database.types'
export const supabase = createClient<Database>(
import.meta.env.VITE_SUPABASE_URL,
import.meta.env.VITE_SUPABASE_ANON_KEY,
{ auth: { autoRefreshToken: true, persistSession: true, detectSessionInUrl: true } }
)
Full walkthrough — SPA singleton + auth-state listener, React Query hooks, React Native AsyncStorage client, mobile OAuth with deep links, and Expo app.json config: SPA and mobile patterns.
Step 3 — Serverless (Edge Functions) and Multi-Tenant
Edge Functions create a per-request client from the forwarded JWT (stateless, no session persistence), escalating to service_role only for privileged operations. Multi-tenant isolation is either RLS-based (a tenant_members lookup gates every row) or schema-per-tenant.
Full walkthrough — Edge Function per-request clients, admin escalation, RLS multi-tenant isolation, and tenant-scoped SDK queries: serverless and multi-tenant patterns.
Output
- Next.js SSR setup with server client (cookies-based auth), browser client, and middleware
- Server Actions using admin client with
service_rolefor privileged operations - SPA pattern with singleton client, React Query integration, and auth state listener
- React Native setup with
AsyncStorage, deep link OAuth, and in-app browser - Edge Function patterns for per-request auth and admin escalation
- Multi-tenant RLS isolation with
tenant_memberslookup and scoped queries - Decision matrix for choosing the right architecture per stack
Error Handling
| Issue | Cause | Solution |
|---|---|---|
AuthSessionMissingError in Server Component | Cookies not passed to Supabase client | Use createServerClient from @supabase/ssr with cookie handlers |
| OAuth redirect fails in React Native | Missing deep link scheme | Add scheme to app.json and configure Supabase redirect URL |
service_role key in client bundle | Wrong env var prefix (NEXT_PUBLIC_) | Remove NEXT_PUBLIC_ prefix; only server code should access it |
| Multi-tenant data leak | Missing RLS policy or missing tenant_id filter | Verify RLS is enabled and policies check tenant_members |
Edge Function auth.getUser() returns null | Missing Authorization header | Forward user's JWT from the client call |
| Session not persisting on mobile | AsyncStorage not configured | Pass AsyncStorage in auth config; ensure package is installed |
Examples
Verify tenant isolation by impersonating a JWT and confirming RLS scopes the result:
-- Test that RLS properly isolates tenants
SET request.jwt.claims = '{"sub": "user-uuid-1"}';
-- Should only return projects for user-uuid-1's tenant
SELECT * FROM public.projects;
More runnable examples — the Next.js OAuth callback route and further end-to-end flows: Next.js SSR patterns and examples.
Resources
- Supabase SSR (Next.js)
- Supabase React Native
- Supabase Edge Functions
- Multi-Tenant with RLS
- Supabase Auth Deep Linking
- @supabase/ssr Package
Next Steps
After wiring the client for your architecture, review supabase-known-pitfalls for common mistakes and anti-patterns to avoid, then generate database types with supabase gen types typescript and enable RLS on every table before shipping.
When not to use it
- →Client-side bundling of service_role keys
- →Direct browser access to admin-only operations
Prerequisites
Limitations
- →Service_role keys must never reach the browser
- →Read-after-write consistency issues on replicas
How it compares
Unlike generic documentation, this provides specific client-side skeletons and decision matrices for five distinct Supabase deployment patterns.
Compared to similar skills
supabase-architecture-variants side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| supabase-architecture-variants (this skill) | 0 | 27d | Review | Intermediate |
| javascript-typescript-typescript-scaffold | 3 | 4mo | Review | Beginner |
| open-notebook-lm-guidelines | 0 | 5mo | No flags | Advanced |
| nextjs-best-practices | 31 | 6mo | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by jeremylongshore
View all by jeremylongshore →You might also like
javascript-typescript-typescript-scaffold
sickn33
You are a TypeScript project architecture expert specializing in scaffolding production-ready Node.js and frontend applications. Generate complete project structures with modern tooling (pnpm, Vite, N
open-notebook-lm-guidelines
RainLib
Core project guidelines, architecture, and UI styling instructions for the FerrisMind (openNotebookLm) AI workspace project. Use this whenever working on the frontend or backend of this project.
nextjs-best-practices
davila7
Next.js App Router principles. Server Components, data fetching, routing patterns.
project-overview
lobehub
Complete project architecture and structure guide. Use when exploring the codebase, understanding project organization, finding files, or needing comprehensive architectural context. Triggers on architecture questions, directory navigation, or project overview needs.
nx-generate
nrwl
Generate code using nx generators. USE WHEN scaffolding code or transforming existing code - for example creating libraries or applications, or anything else that is boilerplate code or automates repetitive tasks. ALWAYS use this first when generating code with Nx instead of calling MCP tools or running nx generate immediately.
server-components
davepoon
This skill should be used when the user asks about "Server Components", "Client Components", "'use client' directive", "when to use server vs client", "RSC patterns", "component composition", "data fetching in components", or needs guidance on React Server Components architecture in Next.js.