Coder Legion - Recent posts tagged supabase

Extracting a React presence hook from a production event app

Wed, 30 Sep 2026 14:10:55 +0000

How we turned a battle-tested Supabase Realtime Presence layer into react-supabase-presence
Real-time “who is in the room” sounds simple until you ship it on phones.

Tabs freeze. Networks drop. React Strict Mode double-mounts effects. Supabase will often restore the socket for you — but presence track state does not magically re-announce itself. If you do not re-track after resubscribe, other clients still think you are offline.

We hit that in production while building an event networking product (QR check-in, live roster, ephemeral rooms). The presence logic had to be honest in the UI: not a single boolean “connected,” but a small state machine the interface could show without lying.

That code is now open source:
npm: react-supabase-presence
GitHub: devhabeeblateef/react-supabase-presence
License: MIT

The problem we actually had
Supabase Realtime Presence is a good primitive. The gaps show up at the edges:

Lifecycle — subscribe → track → sync/join/leave. Miss a re-track after reconnect and your user vanishes for everyone else.
Mobile browsers — background tabs can freeze sockets without a clean CLOSED event. Coming back to the tab should re-announce.
UI honesty — “loading” vs “live” vs “trying again” are different states. Collapsing them into one spinner trains users to ignore the product.

App boundaries — roster, roles, and business logic should not live inside the presence hook. The hook should only answer: who is online, and is the channel healthy?

We implemented that as a React hook inside the product first, then extracted it so the package has zero knowledge of events, QR codes, or billing.

What the hook does

`import { useEventPresence } from "react-supabase-presence";
import type { EventPresence, PresenceStatus } from "react-supabase-presence";
TypeScriptconst { online, status, version } = useEventPresence(
  supabase,   // your browser Supabase client
  channelKey, // stable room / event id
  selfId      // stable presence key for the current user
);

Behaviour that mattered in production

Channel name is derived as presence:${channelKey} with config.presence.key = selfId.
On SUBSCRIBED, the hook tracks { user_id, at }.
On CHANNEL_ERROR / TIMED_OUT / CLOSED, status becomes reconnecting (the client library may still recover underneath).
On visibilitychange → visible, it re-tracks so a returning mobile tab reappears.

Cleanup removes the channel; no shared global channel name that breaks under Strict Mode remounts.

You own the SupabaseClient. The library does not create clients, read env vars, or assume your schema.

Minimal example

`"use client";
import { createClient } from "@supabase/supabase-js";
import { useEventPresence } from "react-supabase-presence";

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
);

export function Room({ roomId, userId }: { roomId: string; userId: string }) {
  const { online, status, version } = useEventPresence(
    supabase,
    roomId,
    userId
  );

  return (
    <div>
      <p>Status: {status}</p>
      <p>
        {online.size} online (v{version})
      </p>
      <ul>
        {[...online].map((id) => (
          <li key={id}>{id}</li>
        ))}
      </ul>
    </div>
  );
}

Install: npm install react-supabase-presence
Peer dependencies: react (≥18) and @supabase/supabase-js (^2.40).

Design choices (and non-goals)
In scope for v0.1

Presence subscribe + track + state aggregation
Explicit connection state for UI
Tab-visible re-track
TypeScript types exported from the package root

Out of scope (on purpose)
Authentication
Authorization / RLS policy design
Handshakes, chat, or matching
Rendering components (dots, avatars, lists)

Those belong in the product. Keeping them out is what makes the package reusable and reviewable.
The product that motivated this work still uses the published package for its live room roster — same API, one implementation path.

Why open source this slice
Presence is a sharp edge many Supabase + React apps re-implement poorly. Publishing a small, MIT-licensed hook:

Documents the reconnect and visibility behaviour in public
Gives others a starting point that is not tied to one startup’s domain model
Forces a clean boundary: if it needs your event table, it does not belong in the library

If you find bugs or want a multi-tab leader election helper, issues and PRs are welcome on the repo.

Links
npm: https://www.npmjs.com/package/react-supabase-presence
Source: https://github.com/devhabeeblateef/react-supabase-presence
License: MIT

Multi-Tenant Architecture in Next.js 16 (2026)

Sun, 20 Sep 2026 03:02:16 +0000

Every SaaS product hits the same wall eventually: you built it for one company, and now you need it to work for a hundred — each with their own users, their own data, and their own little corner of the app, like acme.yourapp.com. Bolt that on badly and you get the nightmare scenario every backend developer fears: one bug in a WHERE clause, and Company A's customer list shows up in Company B's dashboard.

That's the entire problem multi-tenant architecture solves. It's not one trick — it's a set of decisions about routing, data isolation, and access control that, done right, make "which company does this user belong to?" a question your app can never get wrong, even if a developer forgets to ask it.

By the end of this guide, you'll have a working multi-tenant Next.js 16 app: subdomain-based routing through proxy.ts, a tenant data model backed by Postgres Row Level Security so isolation is enforced by the database — not just your application code — and a path to deploying it on Vercel with wildcard domains.

Quick Answer: What Is Multi-Tenant Architecture?

Multi-tenant architecture is a software design where a single application instance and (usually) a single database serve multiple independent customers — called tenants — while keeping each tenant's data, users, and configuration completely isolated from every other tenant. Instead of deploying a separate copy of your app per customer, one codebase and one deployment serve everyone, and the app itself decides which tenant a request belongs to and what data that tenant is allowed to see.

Think of it like an apartment building: one building (your app), many separate units (tenants), each with its own locked door (data isolation) — but the plumbing, the elevator, and the foundation (your codebase and infrastructure) are shared.

Single-Tenant vs. Multi-Tenant: The Difference That Matters

	Single-Tenant	Multi-Tenant
Deployment	One app + one database per customer	One app (usually one database) for all customers
Infrastructure cost	Scales linearly with customers	Shared, scales with usage not customer count
Data isolation	Physical (separate databases)	Logical (enforced in code and/or the database)
Updates/bug fixes	Deploy to every customer separately	Deploy once, everyone gets it
Customization per customer	Easy — each customer has an isolated deployment/configuration	Harder — needs a plan/feature-flag system
Best for	Enterprise clients needing full data isolation or compliance	SaaS products with many small-to-mid customers

Many collaboration and SaaS platforms expose workspace/organization concepts that follow the multi-tenant model. You don't get your own copy of Slack's servers when you sign up; you get a workspace, which is just a tenant inside their shared infrastructure.

💡 Tip: "Tenant" is deliberately generic — in your app it might be called a workspace, organization, team, company, or account. The underlying pattern is identical regardless of what you call it in your UI.

Why This Is Tricky

Multi-tenancy isn't hard because the concept is complicated — it's hard because the cost of getting it wrong is severe (a data leak between customers), and there are genuinely several valid ways to build it, each with real tradeoffs. Before writing any code, you need to answer two separate questions:

How do I identify which tenant a request belongs to? (subdomain, custom domain, or URL path)
How do I keep each tenant's data isolated? (separate databases, separate schemas, or one shared table set with a tenant_id column)

Get the first one wrong and tenants can't reach the right version of your app. Get the second one wrong and — worst case — tenants can see each other's data. We'll cover both, and this guide focuses on the combination most SaaS products actually ship with: subdomain-based routing plus a shared database with row-level isolation, because it's the cheapest to run and the fastest to build on, while still giving you database-enforced security.

The Three Data Isolation Models

Model	How it works	Isolation strength	Cost & complexity
Database-per-tenant	Every tenant gets a fully separate database	Strongest — physical separation	Highest — migrations, backups, and connections multiply per tenant
Schema-per-tenant	One database, one Postgres schema per tenant	Strong — separate tables per tenant	Medium — still need to manage N schemas, but one database to back up
Shared tables + `tenant_id`	One database, one set of tables, every row tagged with a `tenant_id`	Depends entirely on enforcement — weak if only in app code, strong with Postgres Row Level Security	Lowest — one schema, one migration, scales to thousands of tenants easily

For most SaaS products — and everything in this guide — shared tables with a tenant_id column, enforced by Postgres Row Level Security (RLS), is the right default. It's the cheapest to operate, the easiest to migrate, and — critically — RLS means isolation is enforced by the database itself, not just by remembering to add .eq("tenant_id", ...) to every query. Reach for schema-per-tenant or database-per-tenant only when a specific customer has a compliance requirement (like data residency) that a shared database genuinely can't satisfy.

Related: Supabase RLS Policy Generator — generates the exact kind of tenant-scoped policies this guide writes by hand, in seconds.

Three Ways to Identify a Tenant

Strategy	Example URL	Pros	Cons
Subdomain	`acme.yourapp.com`	Clean URLs, easy to brand, works great with wildcard SSL	Needs wildcard DNS + nameserver setup
Custom domain	`app.acme.com`	Best for enterprise/white-label, tenant owns their domain	Most setup work — DNS verification, SSL provisioning per domain
Path-based	`yourapp.com/acme/dashboard`	Zero DNS config, works anywhere immediately	Tenant is visible and editable in every URL, no per-tenant branding

This guide builds subdomain-based routing, since it's the sweet spot most SaaS products land on — better UX and branding than path-based, far less setup work than per-tenant custom domains. We'll touch on custom domains near the end for when you're ready to offer that too.

What We're Building

Next.js 16 with the App Router
TypeScript in strict mode
Supabase (Postgres) for the database, using Row Level Security for tenant isolation
Tailwind CSS for the (minimal) UI

By the end, visiting acme.localhost:3000 will resolve to Acme's tenant context, acme.yourapp.com will do the same in production, and every database query for tenant data will be protected by RLS — so even a bug in your own code can't leak one tenant's rows to another.

tenant1.yourapp.com/dashboard
        ↓
   proxy.ts resolves "tenant1" → looks up tenant in DB
        ↓
   Tenant ID attached to the request as a header
        ↓
   Server Component reads the header, fetches tenant-scoped data
        ↓
   Postgres RLS double-checks: is this row actually this tenant's?

Step 1: Project Setup

If you're starting fresh:

npx create-next-app@latest multi-tenant-app

Choose TypeScript, Tailwind CSS, App Router, and the src/ directory if you prefer it (this guide omits src/ for shorter paths). You'll also need Supabase:

npm install @supabase/supabase-js @supabase/ssr

Add your environment variables:

# .env.local
NEXT_PUBLIC_SUPABASE_URL=https://yourproject.supabase.co
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY=your_publishable_key
SUPABASE_SERVICE_ROLE_KEY=your_service_role_key

# The root domain your app is served from. In development this keeps
# its port (localhost:3000); in production it's your bare domain.
NEXT_PUBLIC_ROOT_DOMAIN=localhost:3000

⚠️ Common Mistake: SUPABASE_SERVICE_ROLE_KEY must never be prefixed with NEXT_PUBLIC_. It bypasses every Row Level Security policy in your database — treat it exactly like a database root password, server-only, never shipped to the browser.

Step 2: Resolve the Tenant in `proxy.ts`

In Next.js 16, the file previously called middleware.ts was renamed to proxy.ts — same job, same file conventions, just a new name and a change in default runtime (it now runs on the Node.js runtime by default, which matters here since we're making a database call on every request).

💡 Think of proxy.ts like a receptionist at the front desk of your building. Every visitor (request) talks to the receptionist first. The receptionist checks which company (tenant) they're visiting based on which door they walked through (the subdomain), confirms that company actually exists in the building directory, and then tells the elevator (your app) exactly where to send them — before the visitor ever reaches an office.

First, a small server-only lookup function:

// lib/supabase/service-client.ts
import "server-only";
import { createClient } from "@supabase/supabase-js";

// Service-role client — bypasses RLS, has no user session attached.
// Only ever call this for trusted, server-only reads like tenant lookups.
// Never import this into a Client Component.
export const supabaseAdmin = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!
);

// lib/tenant/get-tenant-by-subdomain.ts
import "server-only";
import { supabaseAdmin } from "@/lib/supabase/service-client";

export type TenantSummary = {
  id: string;
  slug: string;
};

export async function getTenantBySubdomain(
  subdomain: string
): Promise<TenantSummary | null> {
  const { data, error } = await supabaseAdmin
    .from("tenants")
    .select("id, slug")
    .eq("slug", subdomain)
    .maybeSingle();

  if (error || !data) return null;
  return data;
}

If you already have Supabase auth wired up (see our Supabase Auth vs Firebase Auth guide if not), you likely already have these two files for keeping the auth session refreshed on every request:

// lib/supabase/proxy.ts
import { createServerClient } from "@supabase/ssr";
import { NextResponse, type NextRequest } from "next/server";

export async function updateSession(request: NextRequest) {
    let supabaseResponse = NextResponse.next({ request });

    const supabase = createServerClient(
        process.env.NEXT_PUBLIC_SUPABASE_URL!,
        process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!,
        {
            cookies: {
                getAll() {
                    return request.cookies.getAll();
                },

                setAll(cookiesToSet, headers) {
                    cookiesToSet.forEach(({ name, value }) =>
                        request.cookies.set(name, value)
                    );

                    supabaseResponse = NextResponse.next({
                        request,
                    });

                    cookiesToSet.forEach(({ name, value, options }) =>
                        supabaseResponse.cookies.set(name, value, options)
                    );
                    Object.entries(headers).forEach(([key, value]) =>
                        supabaseResponse.headers.set(key, value)
                    );
                },
            },
        }
    );

    await supabase.auth.getClaims();

    return supabaseResponse;
}

// lib/supabase/server.ts
import { createServerClient } from "@supabase/ssr";
import { cookies } from "next/headers";

export async function createClient() {
  const cookieStore = await cookies();

  return createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!,
    {
      cookies: {
        getAll() {
          return cookieStore.getAll();
        },

        setAll(cookiesToSet) {
          try {
            cookiesToSet.forEach(({ name, value, options }) =>
              cookieStore.set(name, value, options)
            );
          } catch {
            // Ignore if called from Server Component
          }
        },
      },
    }
  );
}

⚠️ Don't skip this if you have authentication. Tenant resolution and session refresh are two separate concerns, but they both have to happen in the same proxy.ts run. If you only resolve the tenant and never call updateSession, Supabase's access token is never refreshed on the server, and signed-in users get logged out once it expires — even though nothing about tenant routing looks broken.

Now the proxy itself, composing both:

// proxy.ts
import { NextRequest, NextResponse } from "next/server";
import { updateSession } from "@/lib/supabase/proxy";
import { getTenantBySubdomain } from "@/lib/tenant/get-tenant-by-subdomain";

// Keep the port for building an absolute redirect URL later; strip it
// only when comparing hostnames.
const ROOT_DOMAIN_ENV = process.env.NEXT_PUBLIC_ROOT_DOMAIN ?? "localhost:3000";
const ROOT_DOMAIN = ROOT_DOMAIN_ENV.split(":")[0];

// Subdomains that belong to your main app, not a tenant.
const RESERVED_SUBDOMAINS = new Set(["www", "app", "admin", "api"]);

export async function proxy(request: NextRequest) {
  // Refresh the Supabase auth session first. This may rewrite Set-Cookie
  // headers if the access token needed rotating — we copy those onto
  // whatever response we ultimately return below.
  const supabaseResponse = await updateSession(request);

  const host = (request.headers.get("host") ?? "").split(":")[0];
  const subdomain = getSubdomain(host);

  // No subdomain, or a reserved one — this is the marketing site or the
  // main app shell, not a tenant. Nothing tenant-related to attach.
  if (!subdomain || RESERVED_SUBDOMAINS.has(subdomain)) {
    return supabaseResponse;
  }

  const tenant = await getTenantBySubdomain(subdomain);

  if (!tenant) {
    return redirectToTenantNotFound(request, subdomain);
  }

  // Strip any inbound tenant headers so a client can never forge them —
  // only this proxy is allowed to set x-tenant-*.
  const requestHeaders = new Headers(request.headers);
  requestHeaders.delete("x-tenant-id");
  requestHeaders.delete("x-tenant-slug");
  requestHeaders.set("x-tenant-id", tenant.id);
  requestHeaders.set("x-tenant-slug", tenant.slug);

  // Rebuild the response so the tenant headers ride along on the
  // *request* (this is what makes them readable via headers() in a
  // Server Component), then carry over any refreshed auth cookies.
  const response = NextResponse.next({ request: { headers: requestHeaders } });
  supabaseResponse.cookies.getAll().forEach((cookie) => {
    response.cookies.set(cookie);
  });

  return response;
}

// Redirects to the ROOT domain, not the unknown tenant's subdomain —
// redirecting back to the same bad host would just re-trigger this
// same lookup and loop forever.
//
// Built as a brand-new URL rather than mutating a clone of request.url.
// Cloning request.url first (new URL(request.url)) means the object
// starts out with the tenant subdomain already baked into it, and
// reassigning .host on that object is not reliable for fully replacing
// an existing hostname — in practice it can end up only changing the
// port and leaving the old subdomain in place (e.g. producing
// "unknowndomain.localhost:3000" instead of "localhost:3000"), which
// silently recreates the exact loop this function exists to prevent.
// Constructing the URL from a plain template string sidesteps that
// entirely, since there's no stale hostname left for anything to retain.
function redirectToTenantNotFound(request: NextRequest, subdomain: string) {
  const protocol = request.nextUrl.protocol; // "http:" or "https:"
  const notFoundUrl = new URL(`${protocol}//${ROOT_DOMAIN_ENV}/tenant-not-found`);
  notFoundUrl.searchParams.set("tenant", subdomain);
  return NextResponse.redirect(notFoundUrl);
}

function getSubdomain(host: string): string | null {
  if (host === ROOT_DOMAIN || host === `www.${ROOT_DOMAIN}`) return null;
  if (!host.endsWith(`.${ROOT_DOMAIN}`)) return null;

  return host.slice(0, -(ROOT_DOMAIN.length + 1));
}

export const config = {
  matcher: ["/((?!_next/static|_next/image|favicon.ico).*)"],
};

What's happening here:

updateSession(request) runs first and unconditionally — auth refresh shouldn't depend on whether the host happens to be a tenant subdomain.
redirectToTenantNotFound() builds a brand-new URL pointed at ROOT_DOMAIN_ENV (your real app domain) instead of the unresolved tenant subdomain. The next time proxy runs against that new URL, getSubdomain() returns null for the root domain and the request just passes through — no loop. This has to be a fresh URL, not a mutated clone of the incoming request's URL — cloning request.url first means the tenant subdomain is already baked into the object, and reassigning .host on it is not reliable for fully replacing that hostname (in practice it can end up changing only the port while the old subdomain silently survives, e.g. unknowndomain.localhost:3000 instead of localhost:3000), which just recreates the same loop this function exists to prevent.
The ?tenant= query param survives the redirect, so your /tenant-not-found page can show which subdomain didn't resolve.
We only build requestHeaders (and delete any inbound x-tenant-* values) once we know a real tenant was found — there's nothing to strip or attach on the reserved/no-subdomain path, since supabaseResponse is returned as-is.
supabaseResponse.cookies.getAll() returns whatever refreshed auth cookies Supabase's client queued up; copying them onto the new tenant-aware response means neither concern silently overwrites the other.

A minimal page for the redirect target:

// app/tenant-not-found/page.tsx
interface PageProps {
  searchParams: Promise<{ tenant?: string }>;
}

export default async function TenantNotFoundPage({ searchParams }: PageProps) {
  const { tenant } = await searchParams;

  return (
    <div className="mx-auto max-w-md space-y-3 p-8 text-center">
      <h1 className="text-2xl font-semibold">Workspace not found</h1>
      <p className="text-sm text-muted-foreground">
        {tenant
          ? `We couldn't find a workspace at "${tenant}".`
          : "That workspace doesn't exist."}
      </p>
    </div>
  );
}

⚠️ Common Mistake: Running your tenant lookup on the Edge runtime by explicitly setting runtime: 'edge'. Don't — proxy.ts in Next.js 16 runs on the Node.js runtime by default (and throws if you try to override it), which is exactly what you want here, since a database client typically needs Node.js APIs that aren't available on the Edge runtime.

💡 Tip: For a small application, this direct indexed lookup is straightforward. At higher traffic, cache the subdomain → tenant mapping in Redis/KV/Edge Config or another low-latency store so proxy doesn't hit Postgres on every request.

Step 3: Testing Subdomains Locally

You don't need to edit your /etc/hosts file for this. Modern browsers (Chrome, Firefox, Safari) automatically resolve any *.localhost address to 127.0.0.1 — it's a reserved TLD, not a Next.js feature. So once your dev server is running:

npm run dev

Visiting http://acme.localhost:3000 in your browser just works, as long as NEXT_PUBLIC_ROOT_DOMAIN=localhost:3000 is set in .env.local and a tenant with slug = 'acme' exists in your database.

💡 Tip: If a subdomain isn't resolving locally, it's almost always a browser/network quirk (some corporate VPNs or older browsers don't support .localhost resolution) rather than a bug in your code — try a different browser before debugging proxy.ts.

Step 4: Model Tenants and Isolation in Postgres

This is the part that actually keeps tenants' data apart. Run this in the Supabase SQL editor.

-- Core tenant table. The slug doubles as a DNS label (acme.yourapp.com),
-- so its constraint is stricter than a generic "url-safe string" check:
-- no leading/trailing hyphens, and capped at 63 characters (the DNS
-- label limit), on top of lowercase alphanumerics and hyphens.
create table public.tenants (
  id uuid primary key default gen_random_uuid(),
  slug text unique not null check (
    char_length(slug) between 1 and 63
    and slug ~ '^[a-z0-9-]+$'
    and slug !~ '(^-|-$)'
  ),
  name text not null,
  plan text not null default 'free',
  created_at timestamptz not null default now()
);

-- Who belongs to which tenant, and with what role
create table public.memberships (
  user_id uuid not null references auth.users(id) on delete cascade,
  tenant_id uuid not null references public.tenants(id) on delete cascade,
  role text not null default 'member' check (role in ('owner', 'admin', 'member')),
  created_at timestamptz not null default now(),
  primary key (user_id, tenant_id)
);

-- An example tenant-scoped resource — every real table in your app
-- (invoices, documents, tasks, whatever) follows this same shape.
create table public.projects (
  id uuid primary key default gen_random_uuid(),
  tenant_id uuid not null references public.tenants(id) on delete cascade,
  name text not null,
  created_at timestamptz not null default now()
);

-- The composite primary key (user_id, tenant_id) already gives Postgres
-- a btree index usable for "where user_id = ?" lookups, since a
-- multi-column index supports equality search on a leading prefix of
-- its columns — a separate single-column index on user_id would just
-- be a redundant duplicate. What that composite index can't serve
-- efficiently is "where tenant_id = ?" on its own, since tenant_id
-- isn't the leading column — that's the index actually worth adding.
create index idx_memberships_tenant_id on public.memberships (tenant_id);
create index idx_projects_tenant_id on public.projects (tenant_id);

alter table public.tenants enable row level security;
alter table public.memberships enable row level security;
alter table public.projects enable row level security;

What's happening here: tenants is your list of customers. memberships is the join table linking Supabase's built-in auth.users to tenants — one user can belong to multiple tenants (think: a consultant working with several client workspaces). projects is a stand-in for any real, tenant-owned data table — invoices, documents, tasks, whatever your app actually stores.

Write the RLS Policies

A tenant_id column on a table means nothing on its own — it's just data. Row Level Security is what turns that column into an actual security boundary, enforced by Postgres itself rather than trusted to every query you (or a future teammate) ever write.

-- Security-definer helper: returns every tenant_id the current user
-- belongs to. Wrapping it this way avoids the classic recursive-RLS
-- trap (a policy on "projects" querying "memberships", which has its
-- own RLS that would otherwise re-trigger the same check).
--
-- It lives in a dedicated "private" schema rather than "public" —
-- Supabase's Data API (PostgREST) only exposes schemas you've explicitly
-- opted into (public by default), so putting security-definer functions
-- in "private" keeps them uncallable directly over the REST/RPC API.
-- A security-definer function sitting in "public" is callable by anyone
-- who can reach your API, running with the *creator's* privileges —
-- that's a real privilege-escalation surface if it isn't locked down.
create schema if not exists private;

create or replace function private.user_tenant_ids()
returns setof uuid
language sql
security definer
stable
set search_path = ''
as \(
  select tenant_id
  from public.memberships
  where user_id = (select auth.uid())
\);

-- Postgres grants EXECUTE on every new function to PUBLIC by default —
-- revoke it explicitly, then grant only to the role that actually needs it.
revoke execute on function private.user_tenant_ids() from public;
revoke execute on function private.user_tenant_ids() from anon;
grant usage on schema private to authenticated;
grant execute on function private.user_tenant_ids() to authenticated;

-- Members can see their own membership rows
create policy "memberships_select_own"
on public.memberships
for select
to authenticated
using ( user_id = (select auth.uid()) );

-- Members can see the tenants they belong to
create policy "tenants_select_member"
on public.tenants
for select
to authenticated
using ( id in (select private.user_tenant_ids()) );

-- Members can only see, create, edit, or delete projects that belong
-- to a tenant they're actually part of
create policy "projects_select_tenant_member"
on public.projects
for select
to authenticated
using ( tenant_id in (select private.user_tenant_ids()) );

create policy "projects_insert_tenant_member"
on public.projects
for insert
to authenticated
with check ( tenant_id in (select private.user_tenant_ids()) );

create policy "projects_update_tenant_member"
on public.projects
for update
to authenticated
using ( tenant_id in (select private.user_tenant_ids()) )
with check ( tenant_id in (select private.user_tenant_ids()) );

create policy "projects_delete_tenant_member"
on public.projects
for delete
to authenticated
using ( tenant_id in (select private.user_tenant_ids()) );

What's happening here: user_tenant_ids() is a security definer function — it runs with elevated privileges internally, which lets it read memberships (bypassing that table's own RLS just for this lookup) without creating a circular dependency. set search_path = '' forces every identifier inside the function body to be fully schema-qualified (notice public.memberships, not just memberships) — without this, a malicious or accidental object created earlier in the search path could get resolved instead of the table you actually meant, which is exactly the class of attack Supabase's own linter flags as "Function Search Path Mutable." The revoke/grant pair closes the other half of the gap: by default Postgres lets any role call a newly created function, so without the explicit revoke, anon (unauthenticated requests) could call it too.

Every policy on projects then just asks "is this row's tenant_id one this user belongs to?" Wrapping auth.uid() in (select ...) lets Postgres cache the result once per statement instead of re-evaluating it for every row — a meaningful performance win once your tables have real data in them.

💡 Tip: Notice there's no policy granting using (true) anywhere. Every single operation is explicitly scoped to tenant membership — this is deliberate. A missing policy means Postgres denies access by default, which is exactly the fail-safe direction you want security to fail in.

⚠️ Common Mistake: Putting a security definer helper function in the public schema "because that's where everything else is." If a schema is exposed through Supabase's Data API settings (public is, by default), every function in it is a potential RPC endpoint — private (or any schema you deliberately keep out of the exposed-schemas list) is the safer default for anything that runs with elevated privileges.

Related: Supabase Auth vs Firebase Auth in 2026 if you haven't wired up authentication yet.

Step 5: Read the Tenant in Server Components

Now that proxy.ts attaches x-tenant-id to every request, build a small Data Access Layer function that reads it — this is the single place the rest of your app goes to ask "which tenant is this?"

// lib/tenant/get-current-tenant.ts
import "server-only";
import { cache } from "react";
import { headers } from "next/headers";
import { redirect } from "next/navigation";
import { supabaseAdmin } from "@/lib/supabase/service-client";

export type Tenant = {
  id: string;
  slug: string;
  name: string;
  plan: string;
};

export const getCurrentTenant = cache(async (): Promise<Tenant> => {
  const headersList = await headers();
  const tenantId = headersList.get("x-tenant-id");

  if (!tenantId) {
    // No tenant header means this request never went through a tenant
    // subdomain — proxy.ts only sets it for tenant*.yourapp.com traffic.
    redirect("/");
  }

  const { data: tenant, error } = await supabaseAdmin
    .from("tenants")
    .select("id, slug, name, plan")
    .eq("id", tenantId)
    .maybeSingle();

  if (error || !tenant) {
    redirect("/tenant-not-found");
  }

  return tenant;
});

What's happening here: headers() is async in Next.js 16, so it has to be awaited. Wrapping the whole function in React's cache() means no matter how many components on the same page call getCurrentTenant(), the actual header read and database lookup only run once per request.

Next, a helper that also confirms the signed-in user actually belongs to this tenant — not just that the tenant exists:

// lib/tenant/require-tenant-member.ts
import "server-only";
import { redirect } from "next/navigation";
import { createClient } from "@/lib/supabase/server";
import { getCurrentTenant } from "./get-current-tenant";

export async function requireTenantMember() {
  const tenant = await getCurrentTenant();
  const supabase = await createClient();

  const {
    data: { user },
  } = await supabase.auth.getUser();

  if (!user) {
    redirect(`/login?tenant=${tenant.slug}`);
  }

  // This query runs through the cookie-based client, so RLS applies —
  // it can only ever return a row for the signed-in user themselves.
  const { data: membership } = await supabase
    .from("memberships")
    .select("role")
    .eq("tenant_id", tenant.id)
    .eq("user_id", user.id)
    .maybeSingle();

  if (!membership) {
    redirect("/not-a-member");
  }

  return { tenant, user, role: membership.role };
}

Use it in a page:

// app/dashboard/page.tsx
import { requireTenantMember } from "@/lib/tenant/require-tenant-member";
import { createClient } from "@/lib/supabase/server";

export default async function DashboardPage() {
  const { tenant, user } = await requireTenantMember();
  const supabase = await createClient();

  // The explicit tenant_id filter selects the active tenant represented
  // by this request. RLS provides the database-level safety net that
  // prevents the signed-in user from accessing tenants they don't belong to.
  const { data: projects } = await supabase
    .from("projects")
    .select("id, name, created_at")
    .eq("tenant_id", tenant.id)
    .order("created_at", { ascending: false });

  return (
    <div className="mx-auto max-w-2xl space-y-6 p-8">
      <div>
        <h1 className="text-2xl font-semibold">{tenant.name}</h1>
        <p className="text-sm text-muted-foreground">Signed in as {user.email}</p>
      </div>

      <ul className="space-y-2">
        {projects?.map((project) => (
          <li key={project.id} className="rounded-lg border p-3">
            {project.name}
          </li>
        ))}
      </ul>
    </div>
  );
}

What's happening here: notice the .eq("tenant_id", tenant.id) filter is still there in the app code, even though RLS would block cross-tenant rows either way. This is defense in depth — the query filter makes the intent obvious to any developer reading the code, and RLS is the safety net that catches the case where someone forgets it.

Writing Tenant-Scoped Data with a Server Action

// actions/create-project.ts
"use server";

import { revalidatePath } from "next/cache";
import { createClient } from "@/lib/supabase/server";
import { requireTenantMember } from "@/lib/tenant/require-tenant-member";

export async function createProject(formData: FormData) {
  const { tenant } = await requireTenantMember();
  const supabase = await createClient();

  const name = (formData.get("name") as string | null)?.trim();

  if (!name) {
    return { error: "Project name is required." };
  }

  const { error } = await supabase
    .from("projects")
    .insert({ name, tenant_id: tenant.id });

  if (error) {
    return { error: error.message };
  }

  revalidatePath("/dashboard");
  return { success: true };
}

What's happening here: requireTenantMember() runs first, so an unauthenticated or non-member request never reaches the database at all. Even so, the insert explicitly sets tenant_id: tenant.id rather than trusting a value from the form — never let tenant identity come from client-submitted data, always derive it server-side from the resolved tenant context.

⚠️ Common Mistake: Accepting a tenantId field from formData or a request body and trusting it. The tenant a user is allowed to write to should always come from getCurrentTenant() / the resolved request context — never from anything the client sent.

Related: Role-Based Access Control (RBAC) in Next.js 16 pairs naturally with this — once you have tenants, you'll usually want owner/admin/member permissions within each tenant too, not just membership.

Step 6: Deploy Wildcard Domains on Vercel

To get acme.yourapp.com, beta-co.yourapp.com, and every future tenant's subdomain working automatically in production, you need a wildcard domain pointed at your Vercel project.

Point your domain to Vercel's nameservers (ns1.vercel-dns.com and ns2.vercel-dns.com). Vercel needs to control your DNS to automatically issue SSL certificates for each new subdomain.
In your Vercel project's Domains settings, add the apex domain: yourapp.com.
Add a wildcard domain: *.yourapp.com.

Once that's done, any single-label subdomain — acme.yourapp.com, beta-co.yourapp.com — automatically resolves to your deployment, with Vercel issuing a certificate for each one on the fly. No per-tenant DNS work required on your end.

⚠️ A wildcard certificate for *.yourapp.com covers exactly one DNS label — it matches acme.yourapp.com but not a deeper subdomain like docs.acme.yourapp.com. That kind of nested subdomain would need its own certificate and DNS entry, and this guide's getSubdomain() parser doesn't handle it either (it would slice docs.acme.yourapp.com down to the single string "docs.acme", which isn't even a valid slug under the constraint from Step 4). If you need per-tenant sub-paths like that, treat it as a separate, deliberate feature — don't assume it falls out of wildcard support for free.

Update your production environment variable to match:

NEXT_PUBLIC_ROOT_DOMAIN=yourapp.com

💡 Tip: If tenants will ever be able to publish their own content or run their own code on your subdomains (not just view data you control), submit your domain to the Public Suffix List so browsers isolate cookies between tenant1.yourapp.com and tenant2.yourapp.com. This matters more for user-generated-content platforms than a typical internal-dashboard SaaS.

⚠️ Important: If you become a platform that gives mutually untrusted customers control over content or code on separate subdomains, investigate whether your domain qualifies for the PSL PRIVATE section. This changes browser cookie boundaries, so understand the consequences before applying.

What About Custom Domains?

Letting a tenant use their own domain (app.acme.com instead of acme.yourapp.com) is a common upsell for higher-tier plans, but it's meaningfully more setup: you provision the domain onto your Vercel project programmatically (via the Vercel SDK), verify the tenant actually owns it with a TXT record, and let Vercel auto-issue SSL once verified. The tenant-resolution logic in proxy.ts from Step 2 extends naturally — you'd just add a lookup by full hostname (domain_${hostname}) before falling back to subdomain parsing. Treat this as a Phase 2 feature; ship subdomains first.

Production Checklist

[ ] proxy.ts deletes inbound x-tenant-* headers before setting its own — never trust client-supplied tenant headers
[ ] An unresolved tenant subdomain redirects to the root domain, not the tenant's own (bad) host — otherwise it loops
[ ] proxy.ts refreshes the Supabase auth session on every request, not just tenant headers
[ ] Every tenant-owned table has a tenant_id column, a matching index, and RLS enabled
[ ] RLS policies exist for select, insert, update, and delete — not just select
[ ] No policy anywhere uses a bare using (true) unless a resource is genuinely meant to be public
[ ] Server Actions derive tenant_id from the resolved server-side tenant context, never from client-submitted form data
[ ] Reserved subdomains (www, app, admin, api) are excluded from tenant resolution
[ ] Tenant slugs are constrained as valid single-label DNS names (no leading/trailing hyphens, ≤63 characters)
[ ] Wildcard domain (*.yourapp.com) and apex domain are both added in Vercel, with nameservers delegated
[ ] anon/authenticated table grants are explicitly restricted to only the operations the app requires

Wrapping Up

Multi-tenant architecture in Next.js 16 comes down to two layers working together: proxy.ts figures out which tenant a request belongs to and hands that context downstream as a header, while Postgres Row Level Security makes sure that context is actually enforced — not just trusted — every time data gets read or written. Get those two pieces right, and "which company does this row belong to?" stops being a question your application code has to get right on every single query; it becomes a guarantee your database makes for you.

From here, natural next steps are layering role-based permissions on top of tenant membership (owner vs. admin vs. member), building a tenant-scoped billing flow with Stripe subscriptions, and revisiting session vs. JWT if you want tenant context embedded directly in the session instead of resolved fresh on every request.

Continue Learning

Free Developer Tools

Supabase RLS Policy Generator — generate strict, tenant/team-scoped Row Level Security policies like the ones in this guide, including the auth.uid() performance wrapper and a security-definer helper function, without hand-writing SQL.

Project LifeOps (Part 1): Personal Operating System Architecture and FastAPI + Supabase Backend

Thu, 10 Sep 2026 17:06:49 +0000

How many apps do you use daily to manage your life? If you are anything like me, you probably have one app to track your runs and gym workouts, another to keep tabs on books, a website to rate movies and TV series, and two or three more tools for project management, tasks, and notes.

The result is almost always the same: scattered data silos, mounting monthly subscription bills, and zero ability to cross-analyze data or generate a consolidated monthly executive review.

With that problem in mind and true to the Datalaria ethos of "learning by building", I decided to design and engineer LifeOps: an All-in-One Personal & Professional Operating System (OS) that unifies under a single responsive dashboard:

🏃 Fitness & Performance: Track workouts (Running, Cycling, Gym), distance volume, Personal Bests (PB), and calories.
📚 Reading & Culture: Book progress tracking, percentage bars, and ratings.
🎬 Cinema & Entertainment: Movie, TV series, and documentary catalog organized by platform.
📋 Professional Portfolio & Tasks: Interactive Kanban board, budget tracking, and deliverable milestones.
📊 Reporting & Data Portability: Streaming Word (.docx) executive dossiers, multi-sheet Excel workbooks (.xlsx), and raw CSV exports with UTF-8 BOM.

Best of all: built on top of a rock-solid, production-grade architecture that is 100% Free ($0/month).

In this first installment of the series, we dive into the core foundations: cloud architecture design, PostgreSQL relational data modeling, and building the high-performance FastAPI backend. Let's get into it! 🚀

[!TIP]
Test the live app: You can explore the production build of LifeOps directly at https://datalaria.com/apps/lifeops/.

🗺️ LifeOps Series Roadmap

To understand how every architectural layer fits together, this series spans 5 structured installments:

🟢 Part 1 (This article): Personal Operating System Architecture and FastAPI + Supabase Backend.
⚪ Part 2: React Frontend with Glassmorphism, 360° Dashboard, and Design System.
⚪ Part 3: Core Interactive Modules: Fitness, Library, Cinema, and Professional Kanban Board.
⚪ Part 4: In-Memory Word Dossiers (.docx) & Multi-Sheet Excel Engine (.xlsx).
⚪ Part 5: 24/7 Zero-Cost Cloud Deployment ($0/month), Mobile UX, and PWA.

The $0/Month Architecture: How to Run Free at Scale 💡

When architecting LifeOps, the goal wasn't merely to run on localhost, but to deploy a production-grade system with zero recurring hosting costs using the most generous free tiers available:

┌─────────────────────────────────────────────────────────────┐
│                       CLIENT BROWSER                        │
│            [https://datalaria.com/apps/lifeops](https://datalaria.com/apps/lifeops)               │
└──────────────────────────────┬──────────────────────────────┘
                               │ (Proxy Rewrite 200)
                               ▼
┌─────────────────────────────────────────────────────────────┐
│               FRONTEND: Netlify CDN ($0/month)              │
│          React 18 + Vite 8 + i18n (ES/EN) + CSS Glass       │
└──────────────────────────────┬──────────────────────────────┘
                               │
                JWT Auth Token │  REST API Calls / Streaming
                               ▼
┌─────────────────────────────────────────────────────────────┐
│               BACKEND: FastAPI + Python 3.13                │
│    • In-Memory Docx Generator (python-docx + io.BytesIO)    │
│    • Multi-Sheet Excel Engine (openpyxl)                    │
│    • Anti-DoS Rate Limiting (slowapi) + Strict CORS         │
└──────────────────────────────┬──────────────────────────────┘
                               │
                               ▼
┌─────────────────────────────────────────────────────────────┐
│              DATABASE: Supabase Managed Cloud               │
│       • PostgreSQL with isolated `lifeops` schema           │
│       • Row Level Security (RLS) & Supabase Auth            │
└─────────────────────────────────────────────────────────────┘

Frontend on Netlify ($0/mo): Single Page Application built with Vite and served globally with Gzip compression, route-level code splitting, and transparent proxy rewrite under Datalaria's domain.
Backend on FastAPI ($0/mo): Asynchronous Python 3.13 API with strict validation via Pydantic v2, hosted on Render with cold-start resilience.
Database on Supabase ($0/mo): Managed PostgreSQL database with 500 MB of storage, JWT authentication, and automated Row Level Security (RLS) policies.

[!NOTE]
Render Cold-Start Handling: Because the backend runs on Render.com's free tier, the container spins down after 15 minutes of inactivity. In the React frontend (detailed in Part 2), we implemented a preloader screen with automatic exponential-backoff retries, ensuring the user experiences zero abrupt connection drops.

Relational Data Modeling: Clean Polymorphism in PostgreSQL 🗄️

One of the biggest design challenges when combining disparate activities (a 10 km run, a 400-page book, or a Netflix movie) is avoiding monolithic tables cluttered with NULL columns.

To solve this, I designed a master table with specialized child extensions (1-to-1) inside an isolated lifeops schema:

-- 1. Master Activities Table
CREATE TABLE lifeops.activities (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id UUID NOT NULL REFERENCES auth.users(id) ON DELETE CASCADE,
    activity_type VARCHAR(30) NOT NULL, -- 'sport', 'book', 'film'
    title VARCHAR(200) NOT NULL,
    date DATE NOT NULL DEFAULT CURRENT_DATE,
    duration_minutes INTEGER,
    rating INTEGER CHECK (rating >= 1 AND rating <= 5),
    description TEXT,
    created_at TIMESTAMPTZ DEFAULT NOW(),
    updated_at TIMESTAMPTZ DEFAULT NOW()
);

-- 2. Fitness Extension (Workouts)
CREATE TABLE lifeops.workouts (
    activity_id UUID PRIMARY KEY REFERENCES lifeops.activities(id) ON DELETE CASCADE,
    workout_type VARCHAR(50) NOT NULL, -- 'running', 'cycling', 'gym', etc.
    distance_km NUMERIC(6,2),
    calories INTEGER,
    avg_heart_rate INTEGER,
    elevation_m INTEGER,
    personal_best BOOLEAN DEFAULT FALSE,
    notes TEXT
);

-- 3. Reading Extension (Books)
CREATE TABLE lifeops.books (
    activity_id UUID PRIMARY KEY REFERENCES lifeops.activities(id) ON DELETE CASCADE,
    author VARCHAR(150),
    pages_total INTEGER,
    pages_read INTEGER DEFAULT 0,
    status VARCHAR(30) DEFAULT 'reading', -- 'reading', 'completed', 'wishlist'
    genre VARCHAR(50)
);

-- 4. Cinema Extension (Films)
CREATE TABLE lifeops.films (
    activity_id UUID PRIMARY KEY REFERENCES lifeops.activities(id) ON DELETE CASCADE,
    media_type VARCHAR(30) DEFAULT 'movie', -- 'movie', 'series', 'documentary'
    director VARCHAR(150),
    platform VARCHAR(50), -- 'Cine', 'Netflix', 'HBO Max', 'Prime Video'
    genre VARCHAR(50),
    year INTEGER
);

Why this architecture shines:

Blazing Fast Global Aggregations: Dashboard queries hit only lifeops.activities for KPI counts and calendar activity heatmaps.
Cascading Referencial Integrity: When an activity is removed, PostgreSQL's ON DELETE CASCADE automatically purges child tables without orphaned rows.

Row-Level Security (RLS): Each user can only read and mutate their own data via declarative security policies:

CREATE POLICY "Users can only view their own activities"
ON lifeops.activities FOR SELECT
USING (auth.uid() = user_id);

[!IMPORTANT]
Isolated Schemas & Permissions in Supabase: When maintaining tables in a dedicated schema like lifeops (rather than default public), ensure you grant explicit schema access (GRANT USAGE ON SCHEMA lifeops TO authenticated;) and table permissions to the authenticated role. This isolates the operating system's database domain while honoring multi-tenant security.

The FastAPI Backend: Modular Architecture & Strict Typing ⚡

To organize the API cleanly as business domains expand, we follow FastAPI's Modular Router pattern:

lifeops-api/
├── main.py                  # Entrypoint, Middlewares, Rate Limiter & CORS
├── config.py                # Centralized environment settings with Pydantic Settings
├── middleware/
│   └── auth.py              # Supabase JWT validation & secure user_id extraction
├── models/
│   ├── activity.py          # Pydantic Schemas (Create, Update, Response)
│   └── project.py           # Schemas for Tasks and Projects
├── routers/
│   ├── activities.py        # CRUD endpoints for Fitness, Books & Cinema
│   ├── projects.py          # Endpoints for Kanban Board and Projects
│   ├── stats.py             # Global KPI aggregations & Dashboard metrics
│   ├── reports.py           # Word (.docx) generator & CSV/Excel streaming
│   └── alerts.py            # Intelligent reminder engine
└── services/
    ├── report_generator.py  # In-memory RAM .docx compilation
    └── data_exporter.py     # CSV (BOM) & multi-sheet Excel generator

Secure Supabase JWT Authentication

Every endpoint processing user data injects the get_current_user dependency:

from fastapi import Depends, HTTPException, status
from fastapi.security import HTTPBearer, HTTPAuthorizationCredentials
import jwt

security = HTTPBearer()

async def get_current_user(credentials: HTTPAuthorizationCredentials = Depends(security)) -> AuthenticatedUser:
    token = credentials.credentials
    try:
        payload = jwt.decode(
            token,
            settings.supabase_jwt_secret,
            algorithms=["HS256"],
            audience="authenticated"
        )
        user_id = payload.get("sub")
        if not user_id:
            raise HTTPException(status_code=status.HTTP_401_UNAUTHORIZED, detail="Token missing user identity")
        return AuthenticatedUser(id=user_id, email=payload.get("email"))
    except jwt.PyJWTError as e:
        raise HTTPException(status_code=status.HTTP_401_UNAUTHORIZED, detail="Invalid or expired token")

Production Hardening: Rate Limiting & Anti-Abuse 🛡️

Because LifeOps supports on-the-fly Word report compilation and multi-sheet Excel generation, it was crucial to prevent resource starvation or DoS attacks.

We integrated Rate Limiting with slowapi directly into the FastAPI application:

from slowapi import Limiter, _rate_limit_exceeded_handler
from slowapi.util import get_remote_address
from slowapi.errors import RateLimitExceeded

limiter = Limiter(key_func=get_remote_address, default_limits=["120/minute"])
app.state.limiter = limiter
app.add_exception_handler(RateLimitExceeded, _rate_limit_exceeded_handler)

# Strict rate limit for CPU/memory-intensive Word generation
@router.post("/generate")
@limiter.limit("10/minute")
def generate_report(request: Request, req: GenerateReportRequest, user = Depends(get_current_user)):
    ...

If a client exceeds the threshold, the API responds instantly with an HTTP 429 Too Many Requests, protecting compute resources.

Conclusion and What's Next 🎯

With our FastAPI backend hardened, the PostgreSQL relational schema operational on Supabase, and rate limiting active, we have a production-grade foundation running at $0/month.

In Part 2 of this series, we dive straight into the frontend:

Single Page App development with React 18/19, Vite, and Glassmorphism design.
Internationalization (i18n) system for instant Spanish 🇪🇸 / English 🇬🇧 locale toggling.
The 360° Dashboard architecture with aggregated KPI widgets and interactive Recharts visualizations.
Authentication context (AuthContext) and session synchronization with Supabase.

References & Useful Links 🔗

🚀 Production Application: Try the live app at datalaria.com/apps/lifeops.
🌐 Production REST API: Interactive OpenAPI Swagger documentation at lifeops-api.onrender.com/docs.
⚡ FastAPI Framework: Official documentation at fastapi.tiangolo.com.
🗄️ Supabase Cloud: Guide to PostgreSQL and Row Level Security at supabase.com/docs.
🛡️ SlowAPI: Rate limiting for ASGI/FastAPI at github.com/laurentS/slowapi.

See you in the next installment! Feel free to leave a comment below or connect on socials. 👇

I Moved My Next.js Dashboard Logic Into Postgres. My Frontend Got Boring (And That's the Point).

Tue, 25 Aug 2026 16:16:35 +0000

My dashboard had a useMemo doing arithmetic it had no business doing.

It was a Pokémon TCG Pocket collection tracker, but that part doesn't matter. What matters is that the home page needed to show three things: overall completion, completion per set, and which set you were closest to finishing. The way I'd built it, the browser was fetching every card and every owned record, then grinding through the math on each render to figure all of that out.

It worked. It also got slower and harder to read every time the data grew or I added a metric. So I moved the aggregation out of React and into Postgres, and the surprising result was that my frontend got boring. Fewer hooks, less state, almost nothing left to break.

That's the whole argument of this post: aggregation belongs in the database, and when you put it there, the React code that's left over is the kind of boring you actually want in the layer your users touch.

What "fetching everything into React" actually looks like

Here's the shape of the original dashboard. Load all the cards, load the user's owned rows, then derive everything on the client.

const [cards, setCards] = useState<Card[]>([]);
const [owned, setOwned] = useState<OwnedCard[]>([]);

useEffect(() => {
  (async () => {
    const { data: allCards } = await supabase.from("cards").select("*");
    const { data: ownedRows } = await supabase
      .from("user_cards")
      .select("card_id");
    setCards(allCards ?? []);
    setOwned(ownedRows ?? []);
  })();
}, []);

const ownedIds = useMemo(() => new Set(owned.map((o) => o.card_id)), [owned]);

const perSet = useMemo(() => {
  const groups: Record<string, { total: number; have: number }> = {};
  for (const card of cards) {
    const g = (groups[card.set_id] ??= { total: 0, have: 0 });
    g.total += 1;
    if (ownedIds.has(card.id)) g.have += 1;
  }
  return groups;
}, [cards, ownedIds]);

const overall = useMemo(() => {
  const total = cards.length;
  const have = cards.filter((c) => ownedIds.has(c.id)).length;
  return total ? have / total : 0;
}, [cards, ownedIds]);

It's not bad code. But look at what it's costing:

The payload grows with the collection. I'm shipping every card row to the browser just to count them. The user never sees most of that data. It exists only to be reduced to a few numbers.
The logic can't be tested without mounting a component. The "closest set to finishing" rule lives inside hooks, tangled up with fetching and state.
Every new metric is more client state. Want a "rarest card you're missing" stat? That's another loop, another useMemo, another thing that re-runs on render.

I was using React as a database query engine. It's not one.

Why this is the wrong layer

Counting, grouping, and computing ratios across rows is a set operation. It's the thing relational databases were built to do, indexed and compiled, sitting right next to the data.

When I do it in React instead, I pay for the same work twice. Once to serialize every row and send it over the wire, and again to recompute the aggregates in JavaScript on the client. The database already knew the answer was "you own 41 of 86 cards in this set." I just declined to ask it that question and asked for all 86 rows instead.

This isn't really a performance micro-optimization. It's a question of which layer owns which job. Aggregation is a database job. I'd put it in the wrong place.

Moving it into an RPC function

Supabase lets you call Postgres functions directly with rpc(), so I wrote one that returns exactly the rows the dashboard needs: one row per set, with the counts already computed.

create or replace function public.get_home_set_completion_rows()
returns table (
  set_id text,
  set_name text,
  set_slug text,
  release_date date,
  image_url text,
  data_version text,
  total_cards integer,
  owned_cards integer,
  missing_cards integer
)
language sql
stable
security invoker
set search_path = public
as \(
  select
    sets.id as set_id,
    sets.name as set_name,
    sets.slug as set_slug,
    sets.release_date,
    sets.image_url,
    sets.data_version,
    count(cards.id)::integer as total_cards,
    count(user_cards.card_id)::integer as owned_cards,
    (count(cards.id) - count(user_cards.card_id))::integer as missing_cards
  from public.sets
  left join public.cards
    on cards.set_id = sets.id
  left join public.user_cards
    on user_cards.card_id = cards.id
    and user_cards.user_id = auth.uid()
  group by
    sets.id,
    sets.name,
    sets.slug,
    sets.release_date,
    sets.image_url,
    sets.data_version
  order by
    sets.release_date desc nulls last,
    sets.id;
\);

The left join against user_cards filtered by auth.uid() is doing the per-user work right inside the query. Sets the user has zero cards from still show up with owned = 0, which is what I want.

And the call site collapses to this:

const { data } = await supabase.rpc("get_home_set_completion_rows");

That's it. No fetching everything, no client-side grouping, no Set of owned IDs. The component receives compact, purpose-built rows and maps over them. Overall completion is a sum of two columns. "Closest to finishing" is a sort. Both are now trivial because the hard part already happened in the database.

The React file went from a pile of hooks to a Server Component that calls one function and renders the result. That's the "my frontend got boring" moment, and deleting all that state felt great.

When a view beats a function (and vice versa)

I reached for an RPC function here because of that auth.uid() filter, since the result depends on who's asking. But it's worth knowing when a plain view is the better tool:

Use a view when the aggregation is stable, reusable, and doesn't need parameters. A view reads like a table, composes into other queries, and is the simplest thing that works. Card counts per set that aren't user-specific would be a great view.
Use a function when you need arguments (a user ID, a set filter, a scope toggle) or multi-step logic that a single select can't express cleanly.

One footgun worth flagging: both views and functions interact with row-level security, and security definer versus security invoker decides whose permissions the code runs under. A security definer function bypasses the caller's RLS, which is occasionally what you want and frequently a way to leak other users' data by accident. If you're using RLS to protect per-user rows, and you should be, make sure your function respects it rather than quietly stepping around it.

The objections worth taking seriously.

A few reasonable complaints, because this trade isn't free.

"Now my logic is split across two languages and harder to grep." True. I moved complexity, I didn't delete it. The aggregation now lives in SQL instead of TypeScript, so there's a context switch to read the whole story. My argument is just that it lands in the right place, with the database owning database work, and that the SQL version is shorter and more declarative than the loops it replaced.

"SQL is harder to test." I'd push back on this one. The function is deterministic: give it fixture rows and it produces the same counts every time, with no component to mount. And separating it out made the logic that correctly stayed in TypeScript easier to test too. My pack-recommendation engine, which sums pull probabilities for missing cards and ranks packs by expected value, is real application logic, not aggregation, so it belongs in app code. Once it wasn't tangled up with fetching and dashboard math, I could unit-test it on its own. The point isn't "move everything into Postgres." It's "move the aggregation, keep the decisions."

"This is just more infrastructure to manage." Fair, but it's version-controlled SQL living next to the rest of the schema, not a magic black box. It migrates like everything else.

The rule of thumb

If you take one thing from this post, take this:

Push aggregation and filtering down to the database. Keep decisions and presentation in the app.

Or, more bluntly: if React is looping to count things, that loop probably wants to be a GROUP BY.

The frontend got boring, with smaller payloads, fewer hooks, and less state to corrupt, and boring is exactly what you want from the layer your users actually touch. The interesting, opinionated, easy-to-get-wrong logic moved to where it could be expressed simply and tested in isolation.

The genuinely contested part is where you draw the line. I keep ranking and business decisions in app code and push counting and filtering into the database, but I know people who'd move more in either direction. Where do you draw it?

(Full code, if you want to see the whole thing wired together: mwiginton/pocketdex-tracker. Or try the live app: pocketdex-tracker.vercel.app.)

How I Built Multi-User Apps with Row-Level Security in Supabase

Mon, 24 Aug 2026 13:51:29 +0000

Originally published on clintech.me

When you move from toy projects to real products, the hard problem
isn't styling cards. It's isolation: how do you make sure each user
only sees their own data?

The wrong answer: filter by userId in React and hope no one cheats.
The right answer: Row-Level Security.

What RLS actually is

RLS is a Postgres feature that enforces access policies at the database
level — not the application level. Every query runs through your
policies before returning data.

CREATE POLICY "Users can see their own jobs"
ON jobs FOR SELECT
USING (user_id = auth.uid());

With this in place, even if someone opens DevTools and calls the
Supabase REST API directly with a valid token, they still only get rows
where user_id matches their own auth UID. The database is the
security gate, not your frontend.

How I applied this in ApplyCraft

ApplyCraft is an AI-powered job
tracker I built. Every job, note, and profile is scoped per user.
The policy pattern is consistent across all tables:

jobs.user_id = auth.uid()
job_notes.user_id = auth.uid()
profiles.id = auth.uid()

Even the server-side AI endpoint, which writes outreach copy back
to a job row, verifies ownership before touching the database.
No client-side key exposure, no trust in the frontend.

The mistakes that will burn you

1. Enabling RLS but leaving "allow all" policies
You've technically turned it on but effectively disabled it.
Every policy needs to be explicit.

2. Forgetting write policies
Easy to add SELECT and forget INSERT, UPDATE, DELETE.
Your app will silently fail on writes and you'll spend an hour
wondering why.

3. Trusting only frontend filters
If a table has unrestricted SELECT, any user can bypass your
UI and call the REST endpoint directly. RLS removes that
possibility entirely.

4. Not following the ownership chain on joins
If notes belongs to jobs and jobs belongs to a user, your
note policies should check ownership through that chain, not
just assume the foreign key is enough.

The difference between "multi-user UI" and "multi-tenant product"
is where security lives. Once the database enforces it, your
frontend gets simpler and your app gets much harder to abuse.

I'm a frontend engineer open to remote EU roles, connect with
me on LinkedIn
if this was useful.

Feature Flags in SaaS: A Beginner's Guide with Next.js 16 (2026)

Sun, 23 Aug 2026 05:03:07 +0000

You just shipped a new billing page. It works perfectly in your local environment, QA gives it a thumbs up, and you deploy on a Friday afternoon (bold choice). Twenty minutes later, support tickets start rolling in — the new checkout flow is broken for a chunk of your users, and the only fix is a full redeploy, which means more downtime while you scramble.

Here's the thing: that entire scenario is avoidable. Not by testing harder, but by changing how you ship. If that billing page had been behind a feature flag, you could've turned it off instantly — no redeploy, no rollback, no 2am panic. Just a toggle switch.

By the end of this guide, you'll understand exactly what feature flags are, why almost every real SaaS product uses them, and you'll have a working feature flag system built into a Next.js 16 app — from a simple database-backed version you can build yourself, to Vercel's official Flags SDK for a more polished setup.

Why This Is Tricky

Feature flags sound simple — "just an if statement," right? And technically, that's true. But most beginners either overuse them (turning every branch of code into a flag, creating a tangled mess) or underuse them (skipping flags entirely and relying only on git push to control what users see).

The real skill isn't writing an if statement — it's answering three questions correctly:

Where should the flag be checked? Client, server, or both?
Where should the flag's value live? Hardcoded, a database, or a third-party service?
What happens when the flag is wrong or missing? Does your app break, or fail safely?

We'll answer all three as we build this out.

What Is a Feature Flag, Exactly?

A feature flag (also called a feature toggle) is a switch in your code that controls whether a piece of functionality is active — without needing to change or redeploy your code to flip it.

💡 Think of it like: a light switch wired into your wall during construction, instead of soldering a lamp directly to the power line. The wiring (your code) ships once. Whether the light is on or off is a decision you can change any time, without touching the wall again.

In practice, a feature flag is just a boolean (or sometimes a string/number) that your code checks before rendering something or running some logic:

if (isNewCheckoutEnabled) {
  return <NewCheckout />;
}

return <OldCheckout />;

The interesting part isn't that if statement — it's where isNewCheckoutEnabled comes from and how you control it. That's what the rest of this guide covers.

Why SaaS Products Rely on Feature Flags

A handful of concrete reasons feature flags matter, especially for SaaS:

Ship without releasing. You can merge and deploy unfinished code to production behind a flag that's off. This is called "trunk-based development" — your main branch always reflects what's deployed, but not everything deployed is visible yet.
Instant kill switch. If something breaks, flip the flag off. No git revert, no redeploy, no waiting for a build to finish while your app is broken.
Gradual rollouts. Release a risky feature to 5% of users first, watch for errors, then dial it up to 25%, 50%, 100% — instead of an all-or-nothing launch.
Paid plan gating. Show a feature only to customers on your Pro or Enterprise plan, without maintaining separate codebases per plan.
A/B testing. Show two variants of a feature to different user segments and measure which one performs better.
Beta programs. Let specific users (or your own team) try a feature early, without exposing it to everyone.

💡 Tip: These use cases usually map to four flag types: release flags (hide unfinished work), ops flags (kill switches), permission flags (plan-based access), and experiment flags (A/B tests). Naming your flags after their type helps keep a growing flag list organized — more on this in the best-practices section.

Prerequisites

This guide uses:

Next.js 16 with the App Router
TypeScript in strict mode
Supabase as the database (the same pattern works with any Postgres/SQL database — just swap the client)
Tailwind CSS for the tiny UI examples

We'll build two versions of the same thing:

A do-it-yourself, database-backed flag system — no extra service, full control, great for learning how flags actually work under the hood.
The Vercel Flags SDK — an official, open-source toolkit purpose-built for Next.js that adds typed flags, a local override toolbar, and a clean pattern for swapping providers later.

You don't need both — pick whichever fits your project, or read both to understand the tradeoffs.

  User Request
      │
      ▼
Server Component
      │
      ▼
getFeatureFlag()
      │
      ▼
Next.js Cache
      │
      ├── Cache Hit ─────► true / false
      │
      ▼
  Supabase
      │
      ▼
 true / false
      │
      ▼
  Render UI

Part 1: Building Your Own Feature Flag System

This is the version to reach for if you want zero extra dependencies and full control over where flag data lives — a great fit if you're already using Supabase for your app's database.

Step 1: Create the Feature Flags Table

Every flag needs a key (a unique name), whether it's enabled, and optionally a rollout percentage for gradual releases.

-- Run this in the Supabase SQL editor
create table public.feature_flags (
  key text primary key,
  enabled boolean not null default false,
  rollout_percentage int not null default 100
  check (rollout_percentage between 0 and 100),
  description text,
  updated_at timestamptz not null default now()
);

-- Keep RLS on with no policies — only a service-role client can read this,
-- not even your normal server-side (cookie-based) Supabase client, and never the anon key.
alter table public.feature_flags enable row level security;

What's happening here: key is a plain text primary key like "new-checkout" — your code will reference flags by this string. enabled is the master on/off switch. rollout_percentage lets you release to a slice of users instead of everyone at once (100 means "everyone who has the flag enabled sees it," 25 means "only about a quarter of them do"). Enabling Row Level Security with no policies means this table isn't readable through the public API at all — only your server-side Supabase client (which uses full database access) can read it, which is exactly what you want for something that controls app behavior.

⚠️ Common Mistake: Leaving this table world-readable through the anon key. Even though flag values aren't usually "secret" in the sensitive-data sense, exposing your entire flag list (including unreleased feature names) to anyone poking at your API is an easy, avoidable leak.

Add a couple of test rows:

insert into public.feature_flags (key, enabled, rollout_percentage, description)
values
  ('new-checkout', true, 100, 'Redesigned checkout flow'),
  ('ai-summary', true, 20, 'AI-generated summary panel (early rollout)');

Step 2: Write a Deterministic Rollout Function

If rollout_percentage is 20, you want the same 20% of users to see the feature every time they visit — not a random 20% on every page load. That requires a deterministic check: given the same user and the same flag, always return the same answer.

// lib/flags/rollout.ts
import { createHash } from "crypto";

/**
 * Deterministically decides whether a given user falls inside a flag's
 * rollout percentage. The same userId + flagKey combination always
 * produces the same result, so a user doesn't flicker between the old
 * and new experience on every request.
 */
export function isInRollout(
  userId: string,
  flagKey: string,
  percentage: number
): boolean {
  if (percentage >= 100) return true;
  if (percentage <= 0) return false;

  const hash = createHash("sha256")
    .update(`${flagKey}:${userId}`)
    .digest("hex");

  // Take the first 8 hex characters, turn them into a number,
  // and reduce it to a bucket between 0 and 99.
  const bucket = parseInt(hash.slice(0, 8), 16) % 100;

  return bucket < percentage;
}

What's happening here: createHash("sha256") hashes the combination of the flag key and the user's ID. Because hashing is deterministic (the same input always produces the same output), the same user always lands in the same "bucket" (a number from 0–99) for a given flag. If that bucket number is less than the rollout percentage, they see the feature. Since we mix in the flag key too, the same user can be in the "in" bucket for one flag and the "out" bucket for a completely different flag — buckets aren't shared across flags.

Step 3: Create a Server-Only Function to Read a Flag

First create a service-role Supabase client

The feature_flags table has RLS enabled with no policies, so it can't be read by any client except one authenticated with your service role key — not even your normal server-side (cookie-based) Supabase client can see it. That's actually a good fit here, since flags are app-level configuration, not user data, and it also happens to be the client we need for caching: it has no cookies or per-request session attached, which Next.js requires for anything wrapped in "use cache".

// lib/supabase/service-client.ts
import { createClient } from "@supabase/supabase-js";

// Service-role client — bypasses RLS, no cookies/session attached.
// Only ever use this for trusted, server-only reads like feature flags.
// Never import it into a Client Component, and never prefix the key with NEXT_PUBLIC_.
export const supabaseAdmin = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!
);

⚠️ Common Mistake: Leaking the service role key to the browser. It must stay a plain (non-NEXT_PUBLIC_) environment variable, set only in your server environment — this key bypasses every RLS policy in your database, so treat it with the same care as a database password.

// lib/flags/get-flag.ts
import { supabaseAdmin } from "@/lib/supabase/service-client";
import { isInRollout } from "./rollout";

/**
 * Reads a feature flag's value for a given user.
 * Server-only — never call this from a Client Component.
 */
export async function getFeatureFlag(
  key: string,
  userId?: string
): Promise<boolean> {
  const { data, error } = await supabaseAdmin
    .from("feature_flags")
    .select("enabled, rollout_percentage")
    .eq("key", key)
    .maybeSingle();

  // Fail safe: an unknown or errored flag defaults to "off",
  // not "on" — a missing flag should never accidentally expose
  // an unfinished feature to everyone.
  if (error || !data || !data.enabled) {
    return false;
  }

  // No user context (e.g. a public page) — just use the master switch.
  if (!userId) {
    return data.rollout_percentage >= 100;
  }

  return isInRollout(userId, key, data.rollout_percentage);
}

What's happening here: this function is the single place that knows how to read a flag — every page, Server Action, or Route Handler in your app calls through here instead of querying Supabase directly. Notice the fail-safe default: if the flag doesn't exist, or the database call errors out, we return false. That's a deliberate choice — a flag failing "closed" (off) is almost always safer than failing "open" (on), since an unexpected true could expose an unfinished feature to every user.

Caching Feature Flag Reads with `next/cache`

Right now, getFeatureFlag() hits Supabase on every single call. If a flag is checked on a high-traffic page — or several times per request, once per feature — that's a lot of avoidable database round trips for data that barely changes. A hand-rolled in-memory cache can fix that, but it comes with real downsides in production: it only lives inside one serverless function instance (so different instances can disagree), and it disappears completely on every cold start or redeploy. Next.js already ships a caching layer built for exactly this — reach for that instead of reinventing it.

The good news: the shared part of a flag (its enabled state and rollout_percentage) is identical for every user. Only the final true/false decision is per-user, and that part is just cheap in-memory hashing. So you only need to cache the database row, not the per-user result.

Caching the flag row

// lib/flags/get-flag.ts
import { cacheLife, cacheTag } from "next/cache";
import { supabaseAdmin } from "@/lib/supabase/service-client";
import { isInRollout } from "./rollout";

type FlagRow = { enabled: boolean; rollout_percentage: number };

async function fetchFlagRow(key: string): Promise<FlagRow | null> {
  "use cache";
  cacheLife("minutes"); // safety-net expiry if nothing ever invalidates it
  cacheTag(`feature-flag:${key}`); // lets us invalidate just this one flag

  const { data, error } = await supabaseAdmin
    .from("feature_flags")
    .select("enabled, rollout_percentage")
    .eq("key", key)
    .maybeSingle();

  return error ? null : data;
}

export async function getFeatureFlag(
  key: string,
  userId?: string
): Promise<boolean> {
  const row = await fetchFlagRow(key);

  if (!row || !row.enabled) return false;
  if (!userId) return row.rollout_percentage >= 100;

  return isInRollout(userId, key, row.rollout_percentage);
}

What's happening here: "use cache" at the top of fetchFlagRow marks that function as a cache boundary — Next.js automatically derives the cache key from the function's arguments (key), so each flag gets its own independent cache entry with no manual key-building required. cacheLife("minutes") applies one of Next.js's built-in expiry profiles as a fallback expiry (a handful of minutes), in case nothing ever explicitly invalidates it. cacheTag(\feature-flag:${key}`)` is the important part for production use — it lets you invalidate exactly one flag on demand instead of waiting for the fallback expiry or flushing every cached flag at once.

💡 Tip: "use cache" requires Cache Components to be enabled in next.config.ts:
const nextConfig: NextConfig = {
  cacheComponents: true,
};
If your project isn't on Cache Components yet, use the older unstable_cache API instead — same tagging idea, just a wrapper function instead of a directive:
import { unstable_cache } from "next/cache";

const fetchFlagRow = (key: string) =>
  unstable_cache(
    async () => {
      const { data, error } = await supabaseAdmin
        .from("feature_flags")
        .select("enabled, rollout_percentage")
        .eq("key", key)
        .maybeSingle();
      return error ? null : data;
    },
    ["feature-flag", key],
    { tags: [`feature-flag:${key}`], revalidate: 60 }
  )();

Invalidating a flag the moment it changes

Caching only pays off if flipping a flag actually takes effect quickly. Instead of waiting out cacheLife's fallback window, invalidate the specific tag the moment an admin updates the row:

// actions/toggle-feature-flag.ts
"use server";

import { revalidateTag } from "next/cache";
import { supabaseAdmin } from "@/lib/supabase/service-client";

export async function toggleFeatureFlag(key: string, enabled: boolean) {
  const { error } = await supabaseAdmin
    .from("feature_flags")
    .update({ enabled, updated_at: new Date().toISOString() })
    .eq("key", key);

  if (error) {
    return { error: error.message };
  }

  // Instantly invalidates only this flag's cached row — every
  // subsequent getFeatureFlag() call re-fetches fresh data.
  revalidateTag(`feature-flag:${key}`);

  return { success: true };
}

What's happening here: revalidateTag(\feature-flag:${key}`) tells Next.js's cache "anything tagged with this string is now stale" — the very next call to fetchFlagRow(key) skips the cache and re-fetches from Supabase, then caches the fresh result under the same tag. This is what makes a cached flag system still behave like an instant kill switch: the cache saves you database round trips on the read path, while revalidateTag` guarantees a write is reflected immediately, not after some fixed delay.

⚠️ Common Mistake: Updating the feature_flags table directly from the Supabase dashboard and expecting the change to show up right away. The cache has no way to know the row changed unless something calls revalidateTag() — always flip flags through a path (like the Server Action above) that revalidates the tag, or expect to wait out the cacheLife window.

Step 4: Use the Flag in a Server Component

// app/dashboard/page.tsx
import { getFeatureFlag } from "@/lib/flags/get-flag";
import { getCurrentUser } from "@/lib/auth"; // whatever your auth setup returns
import { NewDashboard } from "@/components/dashboard/new-dashboard";
import { OldDashboard } from "@/components/dashboard/old-dashboard";

export default async function DashboardPage() {
  const user = await getCurrentUser();
  const showNewDashboard = await getFeatureFlag("new-dashboard", user?.id);

  return showNewDashboard ? <NewDashboard /> : <OldDashboard />;
}

What's happening here: because DashboardPage is an async Server Component, we can await getFeatureFlag(...) directly during render — no loading spinner, no client-side fetch, no flicker between the two versions. The flag is resolved once, on the server, before any HTML reaches the browser.

Step 5: Use the Same Flag in a Server Action

Flags aren't just for showing/hiding UI — sometimes you want to gate a whole action, like a new AI feature that costs you money per call.

// actions/generate-summary.ts
"use server";

import { getFeatureFlag } from "@/lib/flags/get-flag";
import { getCurrentUser } from "@/lib/auth";

export async function generateSummary(text: string) {
  const user = await getCurrentUser();

  if (!user) {
    return { error: "You must be signed in." };
  }

  const enabled = await getFeatureFlag("ai-summary", user.id);

  if (!enabled) {
    return { error: "This feature isn't available yet." };
  }

  // ... call your AI provider here
  return { summary: "..." };
}

What's happening here: re-checking the flag inside the Server Action matters even though the button that triggers it is already hidden by the flag in the UI. A hidden button doesn't stop someone from calling the Server Action directly — the server-side check is your real gate, the UI check is just for user experience.

⚠️ Common Mistake: Only checking a flag in the UI (hiding a button) and assuming that's enough. Server Actions are callable endpoints under the hood — always re-verify anything sensitive on the server, the same way you would with authentication or authorization checks.

Part 2: Using the Vercel Flags SDK

The do-it-yourself version above works fine, but as your flag list grows you'll want a few things it doesn't give you: a typed, centralized list of every flag in your app, a way to preview flag values locally without touching the database, and a consistent pattern if you ever want to swap in a dedicated flag provider later.

That's exactly what the Flags SDK (built by the Vercel/Next.js team) solves. It's free, open source, framework-native for Next.js, and — importantly — it works with any data source, including the Supabase table you just built. You're not locked into a specific vendor.

Step 1: Install the SDK

npm install flags

Step 2: Generate a Flags Secret

The SDK uses a secret key to encrypt flag values when they're referenced by its local override tooling. Generate one with Node:

node -e "console.log(crypto.randomBytes(32).toString('base64url'))"

Copy the output into your environment variables:

# .env.local
FLAGS_SECRET=your-generated-secret-here

💡 Tip: Use a different FLAGS_SECRET value for each environment (development, preview, production). If you're deploying on Vercel, set each one with vercel env add FLAGS_SECRET production --sensitive.

Step 3: Define Your Flags in One File

This is the part that makes the SDK worth using — every flag in your app is declared once, as a typed function, in a single file.

// flags.ts
import { flag } from "flags/next";
import { getFeatureFlag } from "@/lib/flags/get-flag";
import { getCurrentUser } from "@/lib/auth";

export const newDashboardFlag = flag<boolean>({
  key: "new-dashboard",
  description: "Show the redesigned dashboard layout",
  decide: async () => {
    const user = await getCurrentUser();
    return getFeatureFlag("new-dashboard", user?.id);
  },
});

export const aiSummaryFlag = flag<boolean>({
  key: "ai-summary",
  description: "AI-generated summary panel (early rollout)",
  decide: async () => {
    const user = await getCurrentUser();
    return getFeatureFlag("ai-summary", user?.id);
  },
});

What's happening here: flag() wraps each feature into its own reusable, typed function. Notice the decide function is just calling the exact same getFeatureFlag() helper you already built in Part 1 — the SDK doesn't replace your data source, it sits on top of it. This means you get the SDK's developer experience (typed flags, the local toolbar, easy provider swaps later) while still owning your data in Supabase.

💡 Tip: Turning every flag into its own exported function means your editor's "Find All References" feature works — you can instantly see every place a flag is used, and confidently delete it once it's no longer needed.

Step 4: Use a Flag in a Page

// app/dashboard/page.tsx
import { newDashboardFlag } from "@/flags";
import { NewDashboard } from "@/components/dashboard/new-dashboard";
import { OldDashboard } from "@/components/dashboard/old-dashboard";

export default async function DashboardPage() {
  const showNewDashboard = await newDashboardFlag();

  return showNewDashboard ? <NewDashboard /> : <OldDashboard />;
}

What's happening here: calling newDashboardFlag() runs the decide function you defined in flags.ts and returns the resolved boolean. Notice there are no arguments at the call site — the flag function already knows how to figure out the current user internally. This is intentional: it keeps every call site simple and makes flags easy to reason about, since the logic for how a flag is decided lives in exactly one place.

⚠️ Common Mistake: Trying to call a flag function from a Client Component. Flags SDK flags are server-only by design — this avoids client-side loading spinners and keeps the decision logic (which might touch a database or user session) off the browser entirely. If a Client Component needs the value, resolve it in the parent Server Component and pass it down as a prop.

Step 5: Conditionally Render a Client Component

// app/dashboard/page.tsx
import { aiSummaryFlag } from "@/flags";
import { SummaryPanel } from "@/components/dashboard/summary-panel";

export default async function DashboardPage() {
  const showAiSummary = await aiSummaryFlag();

  return (
    <div className="space-y-6">
      <h1 className="text-2xl font-semibold">Dashboard</h1>
      {showAiSummary && <SummaryPanel />}
    </div>
  );
}

// components/dashboard/summary-panel.tsx
"use client";

export function SummaryPanel() {
  // Interactive logic here — the flag decision already
  // happened on the server before this component ever rendered.
  return (
    <div className="rounded-xl border p-4">
      <p className="text-sm text-muted-foreground">AI summary coming soon…</p>
    </div>
  );
}

What's happening here: the Server Component resolves the flag once and only renders <SummaryPanel /> at all if the flag is on. The Client Component itself never needs to know a flag exists — it just renders when it's asked to. This keeps the flag-checking logic entirely on the server, which is both simpler and safer than shipping the flag's raw value to the browser.

Best Practices for Feature Flags

A handful of habits that keep a growing flag system from turning into a mess:

Name flags consistently. Use a predictable pattern like kebab-case with a type hint, e.g. release-new-checkout, experiment-pricing-copy, ops-disable-emails, permission-ai-summary. It makes a flag's purpose obvious at a glance.
Default to "off" everywhere. As shown in getFeatureFlag(), an unknown, missing, or errored flag should resolve to false. Fail closed, not open.
Delete flags once they've served their purpose. A release flag that's been at 100% for a month and never gets turned off isn't a flag anymore — it's just a permanent if statement adding complexity. Remove it and the dead code branch behind it.
Never gate real security on a flag alone. A feature flag controls visibility, not authorization. Someone technically could still reach a hidden feature by calling the underlying Server Action or API route directly — always pair a flag with a real permission check for anything sensitive (see Step 5 in Part 1).
Test both states. Before shipping, manually verify your app behaves correctly with the flag both on and off — it's easy to only test the "on" path and forget the fallback still needs to work.
Keep the rollout logic deterministic. As covered in Part 1, a user should see a consistent experience across requests, not a coin flip on every page load.

     Create
       ↓
    Develop
       ↓
Internal Testing
       ↓
       5%
       ↓
      25%
       ↓
      50%
       ↓
     100%
       ↓
    Delete

Frequently Asked Questions

Do I need a third-party service like LaunchDarkly to use feature flags?

No. A single database table, like the feature_flags table built in Part 1, is enough for most SaaS apps — especially early on. Third-party feature flag platforms add real value once you need advanced targeting rules, detailed analytics per flag, or a non-technical team managing flags through a dashboard, but they're not a requirement to get started.

What's the difference between a feature flag and an environment variable?

An environment variable is set at build or deploy time and requires a redeploy to change. A feature flag is checked at runtime and can be flipped instantly without touching your deployment — that's the whole point. Use environment variables for configuration (API keys, database URLs) and feature flags for behavior that needs to change without a redeploy.

Can I use feature flags for A/B testing?

Yes — this is one of the most common uses. Instead of a simple on/off boolean, an experiment flag typically returns one of several variants (e.g. "control" or "variant-b"), and you track which variant a user saw alongside your analytics events to measure the difference in behavior.

Do feature flags have to be true/false?

No — boolean is just the simplest case. Many production flags are multivariate: instead of resolving to true/false, they resolve to one of several named values, like "control", "variant-a", or "variant-b". This is what powers most pricing, copy, and layout experiments, where you're comparing more than two options at once. The pattern in this guide extends naturally — swap the enabled boolean column for a value column (text or jsonb), and type your Flags SDK flag as flag<string>({...}) instead of flag<boolean>({...}) so decide() returns the variant name instead of a boolean. Everything else — the deterministic bucketing, the caching, the server-only checks — works exactly the same way.

Are feature flags secure enough to gate paid features?

A flag can decide whether to show a paid feature, but it should never be the only check. Always verify the user's actual subscription/permission status on the server (inside the Server Action or API route that does the real work) — the flag is a UX layer on top of that, not a replacement for it.

How many feature flags is too many?

There's no hard number, but if you regularly can't remember what a flag does or find yourself afraid to delete one, that's a sign your flag list needs cleanup. A good habit is reviewing flags monthly and removing any release flag that's been fully rolled out and stable for a few weeks.

Does checking a flag slow down my page?

If you're checking the same flags on every request, the Next.js caching approach from the Caching Feature Flag Reads with next/cache section removes most of that cost while still allowing immediate invalidation with revalidateTag().

Wrapping Up

Feature flags turn deployment and release into two separate decisions — you can ship code to production without exposing it, roll features out gradually, and flip a broken feature off in seconds instead of scrambling through a redeploy. You've now got two working approaches: a simple, fully self-owned system backed by a Supabase table, and the Vercel Flags SDK layered on top of it for a more polished, typed developer experience.

Start small — pick one risky upcoming feature, put it behind a flag using the Part 1 pattern, and get comfortable with the workflow before rolling flags out across your whole app.

Continue Learning

Supabase Auth vs Firebase Auth: Which One Should You Choose in 2026?

Thu, 20 Aug 2026 10:26:22 +0000

You're starting a new Next.js project, and before you write a single feature, you have to answer one boring but critical question: who's going to handle login?

Two names keep showing up at the top of every list — Supabase Auth and Firebase Auth. Both are free to start, both support Google/GitHub/email login, and both promise to save you from writing your own password-hashing logic. But they're built on completely different foundations, and picking the wrong one can mean months of awkward workarounds later — like discovering you need SQL joins for a permissions system, but you're stuck with Firestore's document model.

This guide breaks down exactly how Supabase Auth and Firebase Auth differ in 2026 — architecture, pricing, security, and real Next.js 16 App Router code for both — so you can pick the right one before you've built half your app on top of it.

Why This Comparison Is Tricky

Most "Supabase vs Firebase" posts compare marketing pages, not real implementation experience. The truth is these two products solve authentication very differently under the hood:

Supabase Auth is a layer on top of PostgreSQL — every user lives in a real SQL table (auth.users), and permissions are enforced with Row Level Security (RLS) policies written in SQL.
Firebase Auth is a layer on top of Firestore/Google Cloud — users live in Google's own auth system, and permissions are enforced with Firestore Security Rules, a completely different (non-SQL) rules language.

That single architectural difference is what actually decides which one fits your project — not the login form UI, which looks nearly identical on both.

Quick Answer

Choose Supabase Auth if you want a real Postgres database, SQL-based permissions (RLS), open-source flexibility, and the option to self-host later.
Choose Firebase Auth if you're already invested in Firebase or Google Cloud services, or if Firebase's managed identity infrastructure fits your application's architecture.

Now let's get into the details.

Supabase Auth vs Firebase Auth: Which Is Better for Next.js?

If you're building a Next.js SaaS application with PostgreSQL, Supabase Auth is usually the more natural choice because authentication, database access, and authorization can be designed around the same Postgres/RLS model.

Firebase Auth is a better fit when your application already uses Firebase/Google Cloud services or your data model naturally fits Firestore.

Supabase Auth vs Firebase Auth: Feature Comparison

Feature	Supabase Auth	Firebase Auth
Authentication architecture	Integrated with Supabase/PostgreSQL ecosystem	Managed identity service
Common database pairing	PostgreSQL	Firestore (NoSQL)
Free/no-cost auth tier	50,000 monthly active users (MAU)	Depends on Firebase Auth / Identity Platform configuration
Paid pricing	Included in Supabase plan quota; $0.00325/MAU over Pro quota	Identity Platform: 50,000 MAU no-cost tier on Blaze, then usage-based pricing
Email/password	✅	✅
Magic links	✅	✅ (email link sign-in)
Social OAuth (Google, GitHub, etc.)	✅	✅
Phone/SMS OTP	✅	✅
Permissions model	Row Level Security (SQL policies)	Firestore Security Rules (custom rules language)
Self-hosting	✅ Yes (fully open source)	❌ No
Open source	✅ Yes	❌ No
Next.js SSR package	`@supabase/ssr`	Firebase JS SDK + `initializeServerApp`
Best paired with	Postgres-based SaaS apps	Google Cloud / Firestore apps

💡 Tip: Both platforms' free tiers are generous enough to cover most side projects and early-stage SaaS apps completely — pricing usually isn't the deciding factor until you're well past MVP stage.

Architecture: The Real Difference

This is the part most comparison articles skip, and it's the one that actually matters.

Supabase Auth Runs on Postgres

When someone signs up with Supabase Auth, a row gets created in a special auth.users table inside your actual Postgres database. Every other table you create — profiles, posts, orders — can have a foreign key pointing straight at auth.users.id.

That means your permissions logic is just SQL:

-- Only let a user see their own orders
create policy "Users can view own orders"
on orders
for select
using (auth.uid() = user_id);

Why this matters: if your app has relational data — a user has many orders, an order has many line items, a team has many members — Postgres joins handle that naturally. You're not fighting the database to model relationships.

Firebase Auth And Firestore

Firebase Auth manages identity separately from your application data. When paired with Firestore, authorization is commonly enforced using Firestore Security Rules — a rules language, not SQL:

// firestore.rules
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /orders/{orderId} {
      allow read: if request.auth != null && request.auth.uid == resource.data.userId;
    }
  }
}

Why this matters: Firestore is a document database. There's no native JOIN. If your data is deeply relational (think: multi-tenant SaaS with teams, roles, and shared resources), you'll end up duplicating data across documents or running multiple round-trip queries to stitch things together client-side.

💡 Tip: Neither model is "wrong" — Firestore's document model is genuinely great for chat apps, real-time feeds, and simple per-user data. Postgres shines once your data has real relationships between tables.

Setting Up Supabase Auth in Next.js 16

This guide assumes Next.js 16 with the App Router, TypeScript in strict mode, and Tailwind CSS — the current defaults for any new Next.js project.

Step 1: Install Dependencies

npm install @supabase/supabase-js @supabase/ssr

What's happening here: @supabase/supabase-js is the core client library. @supabase/ssr is the package built specifically for frameworks like Next.js — it handles the tricky part of syncing auth cookies between the browser and the server so your session works correctly in Server Components, Server Actions, and the browser alike.

Step 2: Add Environment Variables

# .env.local
NEXT_PUBLIC_SUPABASE_URL=https://yourproject.supabase.co
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY=your_publishable_key

⚠️ Never expose a Supabase secret key (sb_secret_...) or legacy service_role key in client-side code. Both bypass RLS.

💡 Tip: For new Supabase projects, use the publishable key rather than the legacy anon key. Supabase is transitioning away from the legacy API keys during 2026.

Step 3: Create the Browser Client

// lib/supabase/client.ts
import { createBrowserClient } from "@supabase/ssr";

export function createClient() {
  return createBrowserClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!
  );
}

Use this inside Client Components — anywhere you need "use client".

Step 4: Create the Server Client

// lib/supabase/server.ts
import { createServerClient } from "@supabase/ssr";
import { cookies } from "next/headers";

export async function createClient() {
  const cookieStore = await cookies();

  return createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!,
    {
      cookies: {
        getAll() {
          return cookieStore.getAll();
        },
        setAll(cookiesToSet) {
          try {
            cookiesToSet.forEach(({ name, value, options }) =>
              cookieStore.set(name, value, options)
            );
          } catch {
            // Safe to ignore when called from a Server Component
          }
        },
      },
    }
  );
}

What's happening here: this client reads and writes auth cookies through Next.js's cookies() API, so a session created during login is visible to Server Components and Server Actions immediately — no manual token passing needed.

Step 5: Add the Auth Proxy (Middleware)

// utils/supabase/proxy.ts
import { createServerClient } from "@supabase/ssr";
import { NextResponse, type NextRequest } from "next/server";

export async function updateSession(request: NextRequest) {
  let supabaseResponse = NextResponse.next({ request });

  const supabase = createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!,
    {
      cookies: {
        getAll() {
          return request.cookies.getAll();
        },
        setAll(cookiesToSet, headers) {
          cookiesToSet.forEach(({ name, value }) =>
            request.cookies.set(name, value)
          );
          supabaseResponse = NextResponse.next({ request });
          cookiesToSet.forEach(({ name, value, options }) =>
            supabaseResponse.cookies.set(name, value, options)
          );
          Object.entries(headers).forEach(([key, value]) =>
            supabaseResponse.headers.set(key, value)
          );
        },
      },
    }
  );

  await supabase.auth.getClaims();

  return supabaseResponse;
}

// proxy.ts (root of project)
import { type NextRequest } from "next/server";
import { updateSession } from "@/utils/supabase/proxy";

export async function proxy(request: NextRequest) {
  return await updateSession(request);
}

export const config = {
  matcher: [
    "/((?!_next/static|_next/image|favicon.ico|.*\\.(?:svg|png|jpg|jpeg|gif|webp)$).*)",
  ],
};

⚠️ Common Mistake: Skipping this proxy file. Without it, Supabase's refresh token doesn't get renewed on every request, and users get randomly logged out mid-session — one of the most common Supabase Auth bugs beginners hit.

// actions/auth.ts
"use server";

import { redirect } from "next/navigation";
import { createClient } from "@/lib/supabase/server";

export async function login(prev: unknown, formData: FormData) {
  const supabase = await createClient();

  const { error } = await supabase.auth.signInWithPassword({
    email: formData.get("email") as string,
    password: formData.get("password") as string,
  });

  if (error) {
    return { error: error.message };
  }

  redirect("/dashboard");
}

Step 7: Protect Data with Row Level Security

This is Supabase Auth's biggest advantage — security lives at the database level, not just in your app code:

alter table profiles enable row level security;

create policy "Users can view own profile"
on profiles for select
using ((select auth.uid()) = id);

create policy "Users can update own profile"
on profiles for update
using ((select auth.uid()) = id)
with check ((select auth.uid()) = id);

Why this matters: even if someone bypasses your Next.js app entirely and hits the Supabase API directly, RLS still blocks them from seeing data that isn't theirs. Your frontend code stops being the only line of defense.

💡 If you're using Supabase Auth with multiple tables, writing RLS policies manually can become repetitive. DevStacked's Supabase RLS Policy Generator can generate strict policies based on your access pattern.

Setting Up Firebase Auth in Next.js 16

Step 1: Install Dependencies

npm install firebase firebase-admin

What's happening here: firebase is the client SDK (runs in the browser and in Server Components via Firebase's newer server app support). firebase-admin is for privileged, server-only operations like verifying tokens.

Step 2: Add Environment Variables

# .env.local
NEXT_PUBLIC_FIREBASE_API_KEY=your_api_key
NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN=yourproject.firebaseapp.com
NEXT_PUBLIC_FIREBASE_PROJECT_ID=yourproject

Step 3: Initialize Firebase (Client Side)

// lib/firebase/client.ts
import { initializeApp, getApps, getApp } from "firebase/app";
import { getAuth } from "firebase/auth";

const firebaseConfig = {
  apiKey: process.env.NEXT_PUBLIC_FIREBASE_API_KEY,
  authDomain: process.env.NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN,
  projectId: process.env.NEXT_PUBLIC_FIREBASE_PROJECT_ID,
};

const app = getApps().length ? getApp() : initializeApp(firebaseConfig);

export const auth = getAuth(app);

What's happening here: getApps().length ? getApp() : initializeApp(...) prevents Firebase from being re-initialized on every hot reload in development — a classic Firebase + Next.js gotcha if you skip this check.

// components/login-form.tsx
"use client";

import { signInWithEmailAndPassword } from "firebase/auth";
import { auth } from "@/lib/firebase/client";
import { useRouter } from "next/navigation";
import { useState } from "react";

export function LoginForm() {
  const router = useRouter();
  const [error, setError] = useState("");

  const handleSubmit = async (e: React.FormEvent<HTMLFormElement>) => {
    e.preventDefault();
    const form = new FormData(e.currentTarget);

    try {
      await signInWithEmailAndPassword(
        auth,
        form.get("email") as string,
        form.get("password") as string
      );
      router.push("/dashboard");
    } catch (err) {
      setError(err instanceof Error ? err.message : "Login failed");
    }
  };

  return (
    <form onSubmit={handleSubmit}>
      <input name="email" type="email" required />
      <input name="password" type="password" required />
      <button type="submit">Sign in</button>
      {error && <p>{error}</p>}
    </form>
  );
}

⚠️ Common Mistake: Doing all your auth logic client-side and assuming that's enough for SSR. Firebase's client SDK doesn't automatically make the logged-in user visible to your Next.js Server Components — you need a separate step to bridge that gap (next).

Step 5: Bridge the Session to the Server

Firebase's newer Firebase Server App feature lets you read the authenticated user inside Server Components:

// lib/firebase/server.ts
import { cookies } from "next/headers";
import { initializeApp, initializeServerApp } from "firebase/app";
import { getAuth } from "firebase/auth";

export async function getAuthenticatedAppForUser() {
  const authIdToken = (await cookies()).get("__session")?.value;

  const firebaseServerApp = initializeServerApp(initializeApp(), {
    authIdToken,
  });

  const auth = getAuth(firebaseServerApp);
  await auth.authStateReady();

  return { firebaseServerApp, currentUser: auth.currentUser };
}

Learn more Firebase Server App here

What's happening here: the client sets a __session cookie containing the Firebase ID token after login (you write this cookie yourself, typically via a small API route or onIdTokenChanged listener). The server then rebuilds an authenticated Firebase app instance from that cookie — this is meaningfully more manual than Supabase's @supabase/ssr package, which handles cookie syncing for you out of the box.

Note: This example demonstrates the server-side bridge rather than a complete production session-cookie implementation. In production, use a secure HTTP-only session cookie and validate it server-side.

⚠️ Common Mistake: Assuming Firebase Auth "just works" with Server Components the way it works with a client-only SPA. The App Router's server/client split means you need this extra bridging step — it's the single biggest source of Firebase + Next.js App Router complaints online.

Step 6: Protect Data with Firestore Security Rules

// firestore.rules
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /profiles/{userId} {
      allow read, update: if request.auth != null && request.auth.uid == userId;
    }
  }
}

Firestore rules are enforced server-side by Google's infrastructure, similar in spirit to RLS — but written in a proprietary rules language instead of SQL, so there's a real learning curve if your team already knows SQL but not Firestore's rule syntax.

Pricing Comparison

	Supabase Auth	Firebase Auth
Free tier	50,000 MAU	Depends on Firebase Auth / Identity Platform configuration
Paid tier	Included in Supabase plan quota; additional MAU billed after quota	Usage-based pricing with Identity Platform
Self-hosting	✅ Available	❌ Not available

Both platforms offer generous options for early-stage projects, although the exact limits and pricing depend on the plan and services you use. The real cost difference shows up later: Supabase gives you a self-hosting escape hatch if you ever want to leave the MAU pricing model entirely; Firebase does not.

Security Considerations for Both

Regardless of which you choose, keep these in mind for Next.js 16:

Never trust client-side auth checks alone. Whether you're using Supabase or Firebase, always re-verify the session inside Server Actions and Route Handlers — a hidden button in the UI doesn't stop a direct API call.
proxy.ts (formerly middleware.ts) is a UX nicety, not your security boundary. Both Supabase's session refresh and any Firebase token check you add there can be bypassed by calling your backend directly — the real gate is the check inside your Server Action or database rule.
Default new users to the lowest-privilege role. Never let a signup form set its own role or is_admin field — assign it server-side.

When Should You Use Supabase Auth?

You want a real relational database (Postgres) under your app, not just auth.
Your app has complex relationships — teams, roles, shared resources, multi-tenancy.
You want the option to self-host later, or you like knowing you could.
You're already comfortable with SQL, or want to learn it.

When Should You Use Firebase Auth?

You're already using Firestore, Cloud Functions, Firebase Cloud Messaging, or Google Analytics.
Your data model is simple and document-shaped (a user has a profile, a handful of settings — no deep relational joins).
You want Google's massive scale and long production track record specifically for mobile + web apps together.
Your team already knows Firestore Security Rules.

Decision Table

If you need...	Better choice
Next.js + PostgreSQL	🟢 Supabase
SQL + relational data	🟢 Supabase
RLS-based authorization	🟢 Supabase
Self-hosting	🟢 Supabase
Firestore	🟢 Firebase
Firebase ecosystem	🟢 Firebase
Google Cloud integration	🟢 Firebase
Mobile + web Firebase stack	🟢 Firebase
Complex relational SaaS	🟢 Supabase
Document-oriented data	🟢 Firebase

Frequently Asked Questions

Can I switch from Firebase Auth to Supabase Auth later?

Yes, but it's real migration work. You'll need to migrate users and identities, account for password-hash compatibility and provider configuration, and rebuild authorization rules from your Firebase/Security Rules model into Supabase RLS.

Which one is easier for a complete beginner?

Firebase Auth's client-only setup (no SSR bridging) is slightly faster to get a basic login working. But Supabase Auth's @supabase/ssr package makes Next.js App Router integration smoother once you add server-side checks, which almost every real app eventually needs.

Yes — Supabase Auth supports Google, GitHub, Apple, Discord, and dozens of other OAuth providers, configured directly from the Supabase dashboard with no extra backend code required.

Is Firebase Auth open source?

No. Firebase Auth is a fully managed Google Cloud service — you can't self-host it or inspect its internals. Supabase Auth (part of the broader Supabase platform, built on the open-source GoTrue project) is open source and can be self-hosted.

Do I need Row Level Security if I'm already checking auth in my Next.js code?

RLS protects your database from application-level mistakes and direct client access, but it does not protect against misuse of a secret/service-role key because those elevated keys bypass RLS.

Wrapping Up

Supabase Auth and Firebase Auth both get you a working login system fast — the real decision comes down to what's underneath: a relational Postgres database with SQL-based security, or Firestore's document model with Google's rules language. If your app has real relationships between users, teams, and data, Supabase's Postgres foundation will save you pain down the road. If you're already deep in the Google Cloud ecosystem, Firebase Auth keeps everything under one roof.

Whichever you pick, remember the same rule applies to both: UI checks are for user experience, and server-side/database-level checks are your actual security boundary.

Continue Learning

Helpful Free Tools

Supabase RLS Policy Generator — generate strict, pattern-specific Row Level Security policies in seconds instead of hand-writing SQL.
Zod Schema Generator — generate validated schemas for your auth forms straight from JSON or TypeScript, including a ready-to-use Server Action.

🐾 Cat Guardian — Protect. Identify. Find.

Mon, 17 Aug 2026 15:12:42 +0000

I live with seven cats: Kiara, Golia, Meias, Vaquinha, Tigrinha, Peluda, and Gamora.

They all have different personalities, different appearances, and different routines.

And, like many pet owners, there is one thing that has always worried me:

What if one of them gets lost?

That question became the starting point for Cat Guardian.

What I Built

Cat Guardian is a privacy-first digital safety passport for cats.

The idea is simple: give each cat a digital identity containing the information that could actually help if they ever go missing.

The platform provides:

🐈 Digital identity for each cat
🩺 Health records and vaccination tracking
🧠 AI-assisted visual identification
🏷️ Dynamic QR collar tags
🚨 Lost Mode
📱 Public rescue passport
🔐 Privacy-preserving contact between finder and owner
🌎 English and Brazilian Portuguese localization

The problem

When a pet goes missing, useful information is often scattered across photos, veterinary records, paper documents, and the owner's memory.

Traditional collar tags can also expose personal information such as phone numbers or addresses.

I wanted a different approach.

The QR code attached to the collar doesn't expose the owner's contact information.

Instead, when someone finds the cat, they can scan the QR code and access a public rescue profile.

If the owner has activated Lost Mode, the finder can submit a sighting.

The owner is then notified through a secure backend relay.

Owner
  │
  ▼
Cat Guardian
  │
  ├── Digital Identity
  ├── Health Records
  ├── AI Profile
  └── QR Collar Tag
          │
          ▼
      Lost Mode
          │
          ▼
     Finder scans QR
          │
          ▼
    Public Rescue Card
          │
          ▼
     Submit Sighting
          │
          ▼
       Owner notified

The goal isn't to replace GPS trackers or microchips.

It is to make the information surrounding a lost pet available, structured, and safer to share.

Why AI?

I didn't want to add AI simply because this was an AI-related challenge.

I wanted to use it where it could provide practical value.

Gemini is used to analyze visual characteristics such as coat patterns, eye color, and distinctive markings and generate a structured identification profile.

The application also provides informational preventive wellness guidance, while explicitly keeping medical diagnosis and treatment outside its scope.

AI-generated profiles are also localized according to the user's language.

Demo

🌐 Open the Live Demo →

The application includes a Demo Mode, so you can explore the main experience without creating an account.

The demo contains my seven cats:

Kiara · Golia · Meias · Vaquinha · Tigrinha · Peluda · Gamora

Try the Lost & Found flow with the demo data and explore how a finder would interact with a cat's public rescue passport.

Key flows

1. Register a cat

Create a digital identity and add health information.

2. Generate a QR collar tag

The QR code points to the cat's public safety passport.

3. Activate Lost Mode

The owner can mark the cat as missing.

4. Finder scans the QR code

The finder sees the relevant rescue information without seeing the owner's private contact details.

5. Submit a sighting

The finder can send information about where and when the cat was seen.

6. Owner receives the notification

The backend relays the sighting to the owner through Resend.

Code

💻 GitHub Repository →

The project is open source and built with:

React 19
Vite 6
TypeScript
Supabase PostgreSQL
Supabase Auth
Row Level Security
Gemini
Ollama
Mistral 7B
OpenCoder 8B
Resend
i18next / react-i18next
Vitest
React Testing Library
ESLint

How I Built It

This project was also an experiment in AI-assisted software engineering.

I used my own AI Software Engineering Framework 2.0 to orchestrate the development process.

The goal was not simply to ask an LLM to generate the application.

Instead, I treated AI agents as specialized members of an engineering workflow.

Human Supervisor
       │
       ▼
Chief of Staff
       │
       ▼
   Risk Router
    /   |   \
   ▼    ▼    ▼
Mistral OpenCoder Gemini
   \    |    /
    \   |   /
      Jidoka
         │
         ▼
   Human Approval
         │
         ▼
       Merge

Risk-based agent routing

Simple and low-risk tasks were delegated to local models running through Ollama.

🟢 Mistral 7B

Used for tasks such as:

documentation
simple UI changes
repetitive work

🟡 OpenCoder 8B

Used for:

CRUD
forms
implementation tasks

🔴 Gemini

Used for higher-risk tasks such as:

authentication
Row Level Security
AI integrations
architectural decisions

This allowed me to keep the more capable model focused on tasks where it provided the most value.

Jidoka Quality Gate

Every implementation had to pass a validation pipeline:

Lint
  ↓
Typecheck
  ↓
Tests
  ↓
Build
  ↓
Human Approval

If a validation step failed, the workflow stopped instead of allowing the problem to propagate.

This follows the Jidoka / Andon Cord principle from my framework:

When an anomaly is detected, stop the process and fix it before continuing.

The final release candidate passed:

Gate	Result
ESLint	✅ PASS
TypeScript	✅ PASS
Vitest	✅ 21/21 PASS
Production Build	✅ PASS

Privacy-first architecture

The public rescue passport deliberately does not expose:

owner's email
phone number
physical address

The finder communicates through a backend relay.

Sightings are persisted in PostgreSQL and the owner is notified through the Resend API.

This creates a simple separation:

Finder
  │
  ▼
Public Rescue Passport
  │
  ▼
Sighting
  │
  ▼
Backend
  ├── PostgreSQL
  └── Resend
          │
          ▼
        Owner

The finder can help without gaining direct access to the owner's private contact information.

Internationalization

English is the default language, with Brazilian Portuguese as a secondary locale.

I also wanted AI-generated information to respect localization.

The localized AI profiles are stored in PostgreSQL using JSONB:

{
  "en": {
    "description": "...",
    "personality": "..."
  },
  "pt-BR": {
    "description": "...",
    "personality": "..."
  }
}

This keeps the cat's identity data together while allowing the presentation to adapt to the user's language.

Design System

The application uses a custom Midnight Guardian design system.

The visual language combines:

Midnight Navy
Lavender
Emerald
Amber
Coral

The goal was to make the application feel like a safety product rather than a generic pet CRUD application.

🔐 Privacy & Safety

Privacy was treated as a product requirement rather than an afterthought.

The public QR page is intentionally limited to information that can help identify and recover the cat.

Owner PII is not rendered publicly.

The system also does not attempt to provide veterinary diagnosis.

Cat Guardian provides informational preventive wellness guidance and does not replace professional veterinary advice.

🚧 Current Limitations

Cat Guardian is a hackathon prototype.

It does not currently provide:

real-time GPS tracking;
GPS collar hardware integration;
veterinary diagnosis;
guaranteed pet recovery.

These could be explored in future versions.

For this challenge, I intentionally focused on the digital identity, QR-based rescue flow, privacy-preserving communication, and AI-assisted identification.

🎯 What I Learned

The biggest challenge wasn't building the features.

It was deciding what not to build.

It would have been easy to add GPS, maps, mobile applications, IoT devices, blockchain, push notifications, and many other features.

But the core idea was much simpler:

Give a cat a digital identity that can help protect, identify, and reunite them with their owner.

Everything else had to support that idea.

And the project became much stronger because of that constraint.

🐾 Built for seven cats

Cat Guardian started with a very personal question:

What information would I want to have if one of my cats disappeared tomorrow?

I would want their photo.

Their identifying characteristics.

Their health information.

Their vaccination history.

Their microchip information.

And, most importantly:

I would want the person who found them to have a safe way to contact me.

That's Cat Guardian.

Built for:

Kiara · Golia · Meias · Vaquinha · Tigrinha · Peluda · Gamora

🐾

Prize Categories

I'm submitting Cat Guardian for:

🏆 Best Use of Google AI

Gemini is used meaningfully in the application for:

AI-assisted visual identification profiles
feline characteristic analysis
preventive wellness assistance
localized AI-generated content

Google AI is also used as the high-risk agent in the AI-assisted engineering workflow.

🔗 Links

🌐 Live Demo

💻 GitHub Repository

Build a Todo App with Next.js 16 and Supabase (2026 Guide)

Tue, 21 Jul 2026 04:06:26 +0000

In this guide, we’ll build a production-ready Todo App using:

Next.js 16
Supabase
TypeScript
Tailwind CSS
Server Actions
Authentication
Row Level Security (RLS)

This tutorial focuses more on logic and architecture rather than UI design.

By the end of this guide, you'll have:

Authentication with Supabase
Protected routes
Todo CRUD operations
Row Level Security (RLS)
Form validation with Zod
Server Actions
Secure session handling

What We’re Building

Our Todo App will include:

User Registration
User Login
Protected Dashboard
Create Todo
Complete Todo
Delete Todo
Secure Database Access with RLS

Prerequisites

Before starting, make sure you have:

Node.js installed
A Supabase account
Basic understanding of React and Next.js

Folder Structure

proxy.ts
src
├── actions
│   ├── auth.ts
│   └── todo.ts
├── app
│   ├── layout.tsx
│   ├── (auth)
│   │   ├── layout.tsx
│   │   ├── login
│   │   │   └── page.tsx
│   │   ├── register
│   │   │   └── page.tsx
│   ├── (private)
│   |   ├── layout.tsx
│   |   ├── page.tsx
│   |   ├── create
│   │   │   └── page.tsx
├── components
│   ├── form-error.tsx
│   ├── input.tsx
│   ├── loading-button.tsx
│   ├── navbar.tsx
│   └── todo-actions.tsx
├── utils
│   ├── supabase
│   |   ├── client.ts
│   |   ├── proxy.ts
│   |   └── server.ts
│   ├── validators
│   |   ├── auth.ts
│   │   └── todo.ts

Create a Next.js 16 Project

Run the following command:

npx create-next-app@latest todo-app

Choose options according to your preferences.

Recommended setup:

TypeScript
Tailwind CSS
App Router
React Compiler
src/ directory

Now move into the project:

cd todo-app

Setup Supabase

Go to Supabase Dashboard:

Create a New Project

Click New Project
Enter project name
Enter database password
Select region
Enable automatic RLS
Click Create Project

Add Environment Variables

Inside your project Dashboard:

Under Get Connected section
Click Frameworks

Copy the environment variables.

Create .env.local in your project root:

NEXT_PUBLIC_SUPABASE_URL=
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY=

Install Supabase Packages

Run:

npm install @supabase/supabase-js @supabase/ssr

We’ll also install Zod later for validation.

Understanding Supabase Clients

Supabase provides two client types:

Browser Client

Used inside Client Components.

Server Client

Used inside:

Server Components
Server Actions
Route Handlers

Create Supabase Browser Client

Create:

/src/utils/supabase/client.ts

import { createBrowserClient } from "@supabase/ssr";

export const createClient = () =>
  createBrowserClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!
  );

Create Supabase Server Client

Create:

/src/utils/supabase/server.ts

import { createServerClient } from "@supabase/ssr";
import { cookies } from "next/headers";

export async function createClient() {
  const cookieStore = await cookies();

  return createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!,
    {
      cookies: {
        getAll() {
          return cookieStore.getAll();
        },

        setAll(cookiesToSet) {
          try {
            cookiesToSet.forEach(({ name, value, options }) =>
              cookieStore.set(name, value, options)
            );
          } catch {
            // Ignore if called from Server Component
          }
        },
      },
    }
  );
}

Setup Supabase Session Middleware

Create:

/src/utils/supabase/proxy.ts

import { createServerClient } from "@supabase/ssr";
import { NextResponse, type NextRequest } from "next/server";

export async function updateSession(request: NextRequest) {
  let supabaseResponse = NextResponse.next({
    request,
  });

  const supabase = createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!,
    {
      cookies: {
        getAll() {
          return request.cookies.getAll();
        },

        setAll(cookiesToSet, headers) {
          cookiesToSet.forEach(({ name, value }) =>
            request.cookies.set(name, value)
          );

          supabaseResponse = NextResponse.next({
            request,
          });

          cookiesToSet.forEach(({ name, value, options }) =>
            supabaseResponse.cookies.set(name, value, options)
          );

          Object.entries(headers).forEach(([key, value]) =>
            supabaseResponse.headers.set(key, value)
          );
        },
      },
    }
  );

  await supabase.auth.getClaims();

  return supabaseResponse;
}

Setup Next.js Middleware

Create:

/src/proxy.ts

import { type NextRequest } from "next/server";
import { updateSession } from "@/utils/supabase/proxy";

export async function proxy(request: NextRequest) {
  return await updateSession(request);
}

export const config = {
  matcher: [
    /*
     * Match all request paths except for the ones starting with:
     * - _next/static (static files)
     * - _next/image (image optimization files)
     * - favicon.ico (favicon file)
     * Feel free to modify this pattern to include more paths.
    */
    "/((?!_next/static|_next/image|favicon.ico|.*\\.(?:svg|png|jpg|jpeg|gif|webp)$).*)",
  ],
};

Create Route Groups

We’ll use route groups for better organization.

app
 ├── (auth)
 └── (private)

Route groups help organize routes without affecting URLs.
Learn more about Nextjs Route Groups.

Create Auth Layout

Create:

/app/(auth)/layout.tsx

export default function AuthLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <div className="bg-gray-900 flex items-center justify-center flex-1">
      {children}
    </div>
  );
}

Create:

/app/(auth)/login/page.tsx

"use client";

import { login } from "@/actions/auth";
import FormError from "@/components/form-error";
import Input from "@/components/input";
import LoadingButton from "@/components/loading-button";
import Image from "next/image";
import Link from "next/link";
import { useActionState } from "react";

export default function Login() {
  const [state, formAction] = useActionState(login, {
    errors: {
      email: [],
      password: [],
      formError: "",
    },
    data: {
      email: "",
      password: "",
    },
  });

  return (
    <div className="flex flex-col justify-center w-full">
      <div className="sm:mx-auto sm:w-full sm:max-w-sm">
        <Image
          src="https://tailwindcss.com/plus-assets/img/logos/mark.svg?color=indigo&shade=500"
          alt="Logo"
          className="mx-auto"
          width={50}
          height={50}
        />

        <h2 className="mt-10 text-center text-2xl/9 font-bold tracking-tight text-white">
          Sign in to your account
        </h2>
      </div>

      <div className="mt-10 sm:mx-auto sm:w-full sm:max-w-sm">
        <form action={formAction} className="space-y-6">
          <Input
            defaultValue={state?.data?.email || ""}
            name="email"
            type="email"
            label="Email address"
          />

          <FormError errors={state.errors.email} />

          <Input
            defaultValue={state?.data?.password || ""}
            name="password"
            type="password"
            label="Password"
          />

          <FormError errors={state.errors.password} />

          <LoadingButton title="Sign in" />

          <FormError errors={state?.errors?.formError} />
        </form>

        <p className="mt-10 text-center text-sm/6 text-gray-400">
          Not a member?{" "}
          <Link
            href="/register"
            className="font-semibold text-indigo-400 hover:text-indigo-300"
          >
            Register
          </Link>
        </p>
      </div>
    </div>
  );
}

Important Note About Input Names

The name attribute is extremely important because we later access form values using:

formData.get("email")

If names don’t match, your form won’t work correctly.

Create Reusable Input Component

Create:

/src/components/input.tsx

interface InputProps {
  name: string;
  label?: string;
  type?: string;
  defaultValue?: string;
  required?: boolean;
}

const Input = ({
  name,
  label,
  type = "text",
  defaultValue,
  required = true,
}: InputProps) => {
  return (
    <div>
      {label && (
        <label
          htmlFor={name}
          className="block text-sm/6 font-medium text-gray-100"
        >
          {label}
        </label>
      )}

      <div className="mt-2">
        <input
          id={name}
          type={type}
          name={name}
          defaultValue={defaultValue}
          required={required}
          autoComplete={type === "email" ? "email" : undefined}
          className="block w-full rounded-md bg-white/5 px-3 py-1.5 text-base text-white outline-1 outline-white/10"
        />
      </div>
    </div>
  );
};

export default Input;

Create Loading Button

Create:

/src/components/loading-button.tsx

"use client";

import { useFormStatus } from "react-dom";

const LoadingButton = ({
  title,
  className = "",
}: {
  title: string;
  className?: string;
}) => {
  const { pending } = useFormStatus();

  return (
    <button
      disabled={pending}
      type="submit"
      className={`cursor-pointer flex w-full justify-center rounded-md bg-indigo-500 px-3 py-1.5 text-white ${className}`}
    >
      {pending ? "Loading..." : title}
    </button>
  );
};

export default LoadingButton;

What is useFormStatus?

useFormStatus() gives information about the latest form submission state.

We use it to:

Disable button while submitting
Show loading state
Prevent duplicate submissions

Create Form Error Component

Create:

/src/components/form-error.tsx

export default function FormError({
  errors,
}: {
  errors?: string | string[];
}) {
  if (!errors || (Array.isArray(errors) && errors.length === 0)) {
    return null;
  }

  return (
    <p aria-live="polite" className="text-sm text-red-500">
      {typeof errors === "string" ? errors : errors.join(", ")}
    </p>
  );
}

Install Zod

Run:

npm install zod

Create Auth Validation Schema

Create:

/src/utils/validators/auth.ts

import z from "zod";

export const authSchema = z.object({
  email: z.email(),
  password: z
    .string()
    .min(6, "Password must be at least 6 characters long")
    .max(100, "Password must not exceed 100 characters"),
});

Create:

/src/actions/auth.ts

"use server";

import { redirect } from "next/navigation";
import { createClient } from "@/utils/supabase/server";
import { authSchema } from "@/utils/validators/auth";

export async function login(prev: unknown, formData: FormData) {
  const data = {
    email: formData.get("email") as string,
    password: formData.get("password") as string,
  };

  const validatedFields = authSchema.safeParse(data);

  if (!validatedFields.success) {
    return {
      data,
      errors: {
        ...validatedFields.error.flatten().fieldErrors,
        formError: "",
      },
    };
  }

  const supabase = await createClient();

  const { error } = await supabase.auth.signInWithPassword(
    validatedFields.data
  );

  if (error) {
    return {
      data,
      errors: {
        formError: error.message,
        email: [],
        password: [],
      },
    };
  }

  redirect("/");
}

Here’s what happens:

Get form values using formData
Validate using Zod
Call Supabase Auth API
Redirect user after successful login

Because this is a Server Action, we must use the server Supabase client.

Create Register Page

Create:

/app/(auth)/register/page.tsx

Use the same structure as login page but replace:

import { signup } from "@/actions/auth";

and:

<LoadingButton title="Sign up" />

Add this inside:

/src/actions/auth.ts

export async function signup(prev: unknown, formData: FormData) {
  const data = {
    email: formData.get("email") as string,
    password: formData.get("password") as string,
  };

  const validatedFields = authSchema.safeParse(data);

  if (!validatedFields.success) {
    return {
      data,
      errors: {
        ...validatedFields.error.flatten().fieldErrors,
        formError: "",
      },
    };
  }

  const supabase = await createClient();

  const { error } = await supabase.auth.signUp(validatedFields.data);

  if (error) {
    return {
      data,
      errors: {
        formError: error.message,
        email: [],
        password: [],
      },
    };
  }

  redirect("/");
}

Supabase may require email confirmation depending on project settings after signup.

Create Private Layout

Create:

/app/(private)/layout.tsx

import Navbar from "@/components/navbar";

export default function PrivateLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <>
      <Navbar />

      <div className="mt-16">{children}</div>
    </>
  );
}

Create:

/src/components/navbar.tsx

import { logout } from "@/actions/auth";
import { createClient } from "@/utils/supabase/server";
import LoadingButton from "./loading-button";
import Link from "next/link";

const Navbar = async () => {
  const supabase = await createClient();

  const {
    data: { user },
  } = await supabase.auth.getUser();

  return (
    <div className="w-full flex items-center gap-4 p-4 bg-gray-800 justify-between">
      <div className="text-lg font-bold">
        Hi {user?.email}
      </div>

      <div className="flex items-center gap-4">
        <nav className="flex items-center gap-4">
          <Link href="/">Home</Link>
          <Link href="/create">Create Todo</Link>
        </nav>

        <form action={logout}>
          <LoadingButton title="Logout" />
        </form>
      </div>
    </div>
  );
};

export default Navbar;

Create Logout Action

Add this to:

/src/actions/auth.ts

export async function logout() {
  const supabase = await createClient();

  const { data: claimsData } = await supabase.auth.getClaims();

  if (claimsData?.claims) {
    await supabase.auth.signOut();
  }

  redirect("/login");
}

Protect Private Routes

Right now, users can manually access protected pages.

We need route protection.

Update:

/src/utils/supabase/proxy.ts

Replace this

await supabase.auth.getClaims()

With

const { data } = await supabase.auth.getClaims();

const user = data?.claims;
const publicRoutes = ["/login", "/register"];

if (user && publicRoutes.includes(request.nextUrl.pathname)) {
  const url = request.nextUrl.clone();
  url.pathname = "/";
  return NextResponse.redirect(url);
}

if (!user && !publicRoutes.includes(request.nextUrl.pathname)) {
  const url = request.nextUrl.clone();
  url.pathname = "/login";
  return NextResponse.redirect(url);
}

Understanding Logic

Here’s what happens:

Get User
Create Public Routes
First if block checks if the user is logged in & trying to access public routes then navigates user to Home
Second if block checks if the user is not logged in & trying to access private routes then navigates user to Login

How Route Protection Works

Public Routes

Anyone can access:

/login
/register

Private Routes

Only authenticated users can access them.

Additional Protection

Logged-in users cannot revisit auth pages.

Create Todos Table

Open:

Supabase Project Dashboard
From sidebar click SQL Editor

Run:

create table todos (
  id uuid primary key default gen_random_uuid(),
  user_id uuid references auth.users(id) on delete cascade not null,
  title text not null,
  completed boolean default false,
  created_at timestamptz default now()
);

Add Row Level Security Policies

Run:

create policy "Users can view own todos"
on todos
for select
using (auth.uid() = user_id);

create policy "Users can insert own todos"
on todos
for insert
with check (auth.uid() = user_id);

create policy "Users can update own todos"
on todos
for update
using (auth.uid() = user_id);

create policy "Users can delete own todos"
on todos
for delete
using (auth.uid() = user_id);

Why RLS is Important

Without RLS:

Any user could access all data.

With RLS:

Users can only access their own data.

This is one of the most important security features in Supabase.

Create Todo Validation Schema

Create:

/src/utils/validators/todo.ts

import z from "zod";

export const todoSchema = z.object({
  title: z
    .string()
    .min(2, "Title must be at least 2 characters long")
    .max(100, "Title must not exceed 100 characters"),
});

Create Todo Form

Create:

/app/(private)/create/page.tsx

"use client";

import { createTodo } from "@/actions/todo";
import FormError from "@/components/form-error";
import Input from "@/components/input";
import LoadingButton from "@/components/loading-button";
import { useActionState } from "react";

const CreateTodo = () => {
  const [state, formAction] = useActionState(createTodo, {
    error: "",
    data: {
      title: "",
    },
  });

  return (
    <div className="mt-10 sm:mx-auto sm:w-full sm:max-w-sm">
      <form action={formAction} className="space-y-6">
        <Input
          defaultValue={state?.data?.title || ""}
          name="title"
          label="Todo Title"
        />

        <FormError errors={state?.error} />

        <LoadingButton title="Create Todo" />
      </form>
    </div>
  );
};

export default CreateTodo;

Create Todo Action

Create:

/src/actions/todo.ts

"use server";

import { todoSchema } from "@/utils/validators/todo";
import { createClient } from "@/utils/supabase/server";
import { redirect } from "next/navigation";

export async function createTodo(
  prev: unknown,
  formData: FormData
) {
  const supabase = await createClient();

  const data = {
    title: formData.get("title") as string,
  };

  const validatedFields = todoSchema.safeParse(data);

  if (!validatedFields.success) {
    return {
      data,
      error:
        validatedFields.error.flatten().fieldErrors.title?.[0],
    };
  }

  const {
    data: { user },
  } = await supabase.auth.getUser();

  if (!user) {
    return {
      data,
      error: "Please login first",
    };
  }

  const { error } = await supabase.from("todos").insert({
    title: validatedFields.data.title,
    user_id: user.id,
  });

  if (error) {
    return {
      data,
      error: error.message,
    };
  }

  redirect("/");
}

Understanding the Create Todo Action

Here’s what happens:

Get form values using formData
Validate using Zod
Get logged in user
Call Supabase Auth API
Redirect user after successful insert

Create Home Page

Move:

/app/page.tsx

to:

/app/(private)/page.tsx

Now update it:

import TodoActions from "@/components/todo-actions";
import { createClient } from "@/utils/supabase/server";

export default async function Home() {
  const supabase = await createClient();

  const { data } = await supabase
    .from("todos")
    .select("*")
    .order("created_at", {
      ascending: false,
    });

  return (
    <div className="overflow-x-auto rounded-2xl border border-gray-200 bg-white shadow-sm max-w-xl mx-auto">
      <table className="divide-y divide-gray-200 w-full">
        <thead className="bg-gray-50">
          <tr>
            {['Todo', 'Status', 'Actions'].map((header) => (
              <th
                key={header}
                className="px-6 py-4 text-left text-sm font-semibold text-gray-700">
                {header}
              </th>
            ))}
          </tr>
        </thead>

        <tbody className="divide-y divide-gray-100 bg-white">
          {data?.map((todo) => (
            <tr
              key={todo.id}
              className="transition-colors hover:bg-gray-50"
            >
              <td className="px-6 py-4">
                <p className="font-medium text-gray-900">
                  {todo.title}
                </p>
              </td>

              <td className="px-6 py-4">
                <span
                  className={`inline-flex rounded-full px-3 py-1 text-xs font-medium ${todo.completed
                    ? "bg-green-100 text-green-700"
                    : "bg-yellow-100 text-yellow-700"
                    }`}
                >
                  {todo.completed ? "Completed" : "Pending"}
                </span>
              </td>

              <td className="px-6 py-4">
                <TodoActions todoId={todo.id} isCompleted={todo.completed} />
              </td>
            </tr>
          ))}
        </tbody>
      </table>

      {data?.length === 0 && (
        <div className="py-10 text-center text-sm text-gray-500">
          No todos found
        </div>
      )}
    </div>
  );
}

We’re fetching todos in descending order so that the latest todo comes at top.

Create Todo Actions Component

Create:

/src/components/todo-actions.tsx

'use client';

import { handleTodoAction } from "@/actions/todo";
import { useActionState } from "react";

const TodoActions = ({ todoId, isCompleted }: { todoId: string; isCompleted: boolean; }) => {
    const [_, action, isPending] = useActionState(handleTodoAction, undefined);

    const completeTodo = () => action({ todoId, action: "complete" });
    const deleteTodo = () => action({ todoId, action: "delete" });

    return (
        <form className="flex justify-end gap-3">
            {!isCompleted &&
                <button
                    formAction={completeTodo}
                    disabled={isPending}
                    className="rounded-lg disabled:opacity-50 bg-blue-500 px-4 py-2 text-sm font-medium text-white transition hover:bg-blue-600"
                >
                    Complete
                </button>
            }
            <button
                formAction={deleteTodo}
                disabled={isPending}
                className="rounded-lg disabled:opacity-50 bg-red-500 px-4 py-2 text-sm font-medium text-white transition hover:bg-red-600"
            >
                Delete
            </button>
        </form>
    )
}

export default TodoActions

Complete and Delete Todo Action

Add inside:

/src/actions/todo.ts

import { revalidatePath } from "next/cache";

export async function handleTodoAction(prev: unknown, data: { todoId: string; action: "delete" | "complete" }) {

    const { todoId, action } = data;

    if (!todoId) return;

    const supabase = await createClient()
    const { data: { user } } = await supabase.auth.getUser();

    if (!user) return;

    if (action === 'delete') {
        await supabase
            .from("todos")
            .delete()
            .eq("id", todoId)
            .eq("user_id", user.id);
    } else {
        await supabase
            .from("todos")
            .update({
                completed: true,
            })
            .eq("id", todoId)
            .eq("user_id", user.id);
    }
    revalidatePath('/');
}

Final Result

You now have a fully functional Todo App with:

Next.js 16
Supabase Authentication
Protected Routes
Server Actions
Zod Validation
Secure RLS Policies
CRUD Operations

Conclusion

This project demonstrates a modern full-stack architecture using:

Next.js 16
Server Actions
Supabase
RLS
Authentication

Even though it’s a simple Todo App, the structure is production-ready and scalable.

You can now build larger applications using the same architecture and patterns.

Useful Resources

Source Code: View on GitHub

Neon vs Supabase: Feature Comparison, Pros

Sat, 20 Jun 2026 14:10:00 +0000

A detailed technical comparison of Neon and Supabase as managed Postgres platforms in 2026. Neon is a serverless Postgres engine with disaggregated compute/storage, copy-on-write branching, autoscaling, and scale-to-zero billing. Supabase is a backend-as-a-service bundling auth, realtime, storage, edge functions, and auto-generated APIs around a dedicated Postgres VM. Key differences covered include branching semantics (Neon's full-data COW vs Supabase's schema-only branches), pricing models (usage-based vs fixed per-project), connection pooling approaches, PITR, read replicas, AI/MCP tooling, and application-layer services. The verdict: choose Neon for pure serverless Postgres needs (CI environments, bursty workloads, RDS migrations, agent tooling); choose Supabase when the bundled BaaS stack saves meaningful integration time.

Eunify: Cross-Platform Continuity System for Android and MacOS

Sun, 17 May 2026 22:12:01 +0000

I Was Just Solving a Problem that I Face as an Android Phone User
Working With MacOS. I Am Sure There's Someone Else Out There With
Similar Challenges

I developed Eunify, a continuity platform engineered to create a seamless, native-feeling ecosystem between macOS and Android. By bridging these two distinct operating systems, Eunify eliminates workflow friction and ensures uninterrupted cross-device synchronization for productivity and communication.

Core Features

Universal Clipboard: Instantly synchronize your clipboard across operating systems. Text or media copied on your macOS machine is immediately available to paste on your Android device.

Fluid Browser Handoff: Maintain uninterrupted browsing sessions across devices. You can drag and drop an active tab into Eunify on macOS to instantly launch it on your Android device, or push a tab from Android to pop up seamlessly on your Mac.

Bidirectional File Transfer: Securely and rapidly send files directly back and forth between your macOS and Android devices without relying on external cloud services.

Biometric Authentication Integration: Enhance your security workflow by leveraging your Android device's native biometric sensors to unlock your macOS laptop.

Video Call Continuity: Effortlessly hand off active video calls from your macOS machine to your Android device, allowing you to transition from your desk to mobile without dropping the connection.

Trial by Fire: From Garbage Excel to Relational Graph with Python and Pandas

Mon, 27 Apr 2026 05:59:10 +0000

1. The Hook: Industrial Data Entropy

In standard academic theory, data sets are inherently clean. In the active reality of the industrial supply chain, obsolete ERPs continually export garbage arrays.

Receiving a flat Bill of Materials systematically exported from a legacy database immediately binds you to processing massive structural entropy: entirely void parameter cells, anomalous blank spacing hidden inside critical part numbers (e.g., " SN74LS00N "), unstandardized component manufacturer nomenclatures (inconsistently shifting between capitals and disparate acronyms like "ti"), and severe mixed data typing where strict numerals conflict natively with raw text variables.

Pushing this raw flat algorithmic entropy directly forward into a live relational matrix triggers a complete referential integrity failure. The process inherently requires deploying a clean staging environment.

2. The ETL Pipeline (Extract, Transform, Load)

Securing the database perimeter requires a rigorous intermediate layer. We employ Pandas, effectively operating as the strictly objective gatekeeper to our foundational PostgreSQL database.

Before a solitary piece of hardware telemetry reaches the backend schemas, the dedicated Python layer strictly enforces dataset standardization. We routinely execute hard operations securely using .str.strip(), .str.title(), and .fillna() to properly homogenize external manufacturer part numbers (MPNs), completely delete volatile residual spaces, and explicitly enforce explicit valid ENUM classifications replacing null lifecycle constraints natively prior to API linkage.

def load_and_clean_data(filepath: str) -> pd.DataFrame:
    df = pd.read_csv(filepath)
    
    # 1. Radical space elimination and uppercase standardization (Avoids hardcoding)
    df['Manufacturer_PN'] = df['Manufacturer_PN'].str.strip().str.upper()
    df['Manufacturer'] = df['Manufacturer'].str.strip().str.upper()
    
    # 2. Enforced data typing (Guaranteed numerical quantities)
    df['Quantity_per_Assembly'] = pd.to_numeric(
        df['Quantity_per_Assembly'].astype(str).str.strip(), 
        errors='coerce'
    ).fillna(1).astype(int)
    
    # 3. Containment of missing values
    df['Lifecycle'] = df['Lifecycle'].replace(r'^\s*$', np.nan, regex=True).fillna('Active')
    
    return df

3. The Graph Challenge (Shattering the Flat Table)

A Bill of Materials mathematically operates internally as a hierarchical tree structure natively, not a flat dimension stack.

In order to systematically populate the highly restrictive bom_lines array cleanly avoiding the database exclusive CHECK integrity blocker explicitly coded earlier, the python automation segregates and systematically separates the initial two-dimensional DataFrame sequentially into two independent logical grouping vectors.

Applying this distinct data segmentation strictly ensures the entire tree graphs properly:

Loop 1: Explicitly tying Final Parent Products (End_Product_SKU) entirely to specific internal Subassembly containers (Assembly_PN).
Loop 2: Structurally tying Internal Subassemblies (Assembly_PN) strictly natively downward to explicit Base Component items (Component_PN).

This absolute directional differentiation operates cleanly resolving integration faults natively satisfying the mutually exclusive table constraints enforced inside Supabase, correctly mimicking highly accurate factory layout trees algorithmically.

4. The Golden Rule: Ingestion Idempotency

Before a standard data module successfully reaches enterprise standard operation it strictly requires satisfying system Idempotency. This establishes directly that any localized operations engineer can forcefully execute the extraction module recursively infinite sequential times utilizing identical hardware array data completely strictly avoiding destroying structural records nor accidentally generating unconstrained graph hierarchy duplication.

Exploiting primitive INSERT API calls natively corrupts the database integrity by duplicating the graph edges. Instead, the implementation forcefully deploys the upsert() functions logically integrated seamlessly through the Supabase SDK backend architecture utilizing strictly declared Postgres UNIQUE keys firmly established systematically across the specific domains (sku directly crossing global product ranges, internal_pn binding isolated component IDs, and mpn natively locking foreign market parts respectively).

Executing automated telemetry pushes immediately executes cleanly verifying redundant array vectors explicitly reporting live structural compliance seamlessly across loop iterations:

--- Ingestando Products (Idempotente) ---
Upserted 3 products.
--- Ingestando Internal Parts (Idempotente) ---
Upserted 18 internal parts (assemblies & components).
--- Ingestando Manufacturer Parts Telemetry (Idempotente) ---
Upserted 16 manufacturer external parts.
--- Ingestando AML (Mapeo Interno -> Externo) ---
No new AML links to insert (Idempotent success).
--- Ingestando BOM Lines (Grafo Bidireccional Segregado) ---
Mapeando relaciones: Producto Final -> Subensamblaje...
Mapeando relaciones: Subensamblaje -> Componente...
El Grafo BOM está completamente sincronizado (Idempotent success).

[OK] Migración a entorno relacional completada al 100%.

The Sandbox: Execute it Yourself

In Operations Engineering, code is worth more than theory. I have prepared an interactive and secure environment (Zero Friction) for you to test this ETL pipeline.

You don't need to install anything or configure databases. The script will spin up an SQL engine in your browser's memory, ingest a corrupt CSV file, cleanse it using Pandas, and build the relational tree in milliseconds, demonstrating idempotency live.

Access the Interactive Google Colab Here

5. Closing & CTA (Towards the AI Brain)

The system structural data logic completely establishes pure stability. We strictly transported fundamentally corrupt, stagnant standard tabular Excel files completely across explicit programming loops directly natively injecting refined node values natively filling a vastly superior PostgreSQL relational database firmly.

The core foundations remain entirely structural and secure. We possess a natively stable IEC 62402 compliant relational architecture structurally fused directly with a robust Python processing ETL node securely operating live. Crossing into the incoming operational module (Block 3), we firmly awaken complex systematic intelligence cleanly processing logic directly on hardware trees. We deploy strictly scalable Agentic AI parameters (LangChain / CrewAI) comprehensively actively connected inside the unified database constantly autonomously identifying internal financial stress resulting dynamically processing external global EOL silicon alerts. Subscribe consistently witnessing the Agentic Radar launch sequence.

The Risk Map: Architecting an Obsolescence-Immune Data Foundation

Sat, 25 Apr 2026 07:47:17 +0000

1. The Flat Table Trap (Excel is Dead)

Managing an industrial Bill of Materials (BOM) through spreadsheets is a structural deficiency. Excel provides a two-dimensional environment for a three-dimensional problem. Hardware engineering and manufacturing dependencies operate under a graph logic.

When the procurement department receives an End of Life (EOL) alert for a component, calculating the volumetric impact by searching text across multiple static documents introduces operational latency.

The UNE-EN IEC 62402:2019 standard, in its Clause 8.10 (Data Acquisition), establishes the requirement to maintain "a list of configuration sub items within an item" alongside "the identification of the items and sub items details: manufacturer, part number and specification". Achieving the level of parametric traceability demanded by the standard requires the design of a relational data model.

2. Modeling Reality: The Graph Approach (The Internal Environment)

A bill of materials is a dependency tree. To structure the internal manufacturing environment data in PostgreSQL, we define three main indexed tables:

products: Represents the end products. Includes the gross_margin parameter, required to correlate component supply risk with the financial impact on the P&L.
internal_parts: A consolidated register of components, raw materials, and sub-assemblies defined by engineering. Uses a global unique identifier (internal_pn).
bom_lines: Implements the hierarchical relationship. Defines dependencies through mutually exclusive foreign keys (parent_product_id or parent_assembly_id) to a child component (child_pn), specifying a quantity.

Technical Validation: Normalizing the data into a graph structure enables the use of recursive algorithms capable of calculating total exposure in milliseconds. If "Equipment A" requires 4 capacitors and "Equipment B" requires 12, a shortage alert on the component node propagates mathematically and automatically up the tree, cross-referencing totals against the order backlog (SLAs).

3. The Firewall: The AML Table (Approved Manufacturer List)

A core principle of industrial inventory integrity is to prevent the mixing of internal nomenclature with dynamic global market references. Omitting this separation generates traceability inconsistencies.

The architecture implements the aml (Approved Manufacturer List) table as an interface between internal hardware design and the supply chain.

This table enables the Dual-Sourcing strategy. If the bill of materials specifies the component CAP-10K (ERP code), the aml table relates this internal node to both a Texas Instruments reference (preference_level: Primary) and a validated equivalent from Analog Devices (preference_level: Secondary). Upon a supply interruption from the primary source, the relational logic allows switching demand to the secondary source without altering the base BOM.

4. The Integrated Radar (The External Environment)

Integration with global commercial dynamics is consolidated in the manufacturer_parts table.

This entity receives telemetry flows from market aggregators (SiliconExpert, IHS Markit, Accuris) through asynchronous integrations. It maintains an updated record of the manufacturer part numbers (mpn), their lifecycle state (lifecycle_status), and the estimated obsolescence date (estimated_eol_date).

5. Data Segmentation and Intellectual Property (RLS in Supabase)

Deploying this model involves managing Intellectual Property (IP) assets. Accidental or unauthorized exposure of the complete product topology is an unacceptable information security risk. Leveraging the Supabase platform allows implementing security architectures at the data layer.

To prevent external generative models (LLMs) or unprivileged users from reconstructing the complete BOM dependencies, we apply Row Level Security (RLS) directly in PostgreSQL:

-- Security: Row Level Security (RLS) policies - IP Protection
ALTER TABLE products ENABLE ROW LEVEL SECURITY;
ALTER TABLE bom_lines ENABLE ROW LEVEL SECURITY;

-- Allow general read access to authenticated logic
CREATE POLICY "Allow read access to authenticated users" 
ON products FOR SELECT TO authenticated USING (true);

-- Restrict mutations (insert/update/delete) on products and BOM lines to Admin role exclusively
CREATE POLICY "Restrict products mutations to admins" 
ON products FOR ALL TO authenticated 
USING ((auth.jwt() ->> 'role') = 'admin');

The policies restrict any modifications to the products and bom_lines tables to the "Admin" role. Additionally, the architectural design dictates that the database must parse the mathematical expansion of the tree internally and provide the external AI Agent with only the aggregated risk value, without returning the topological structure.

6. Next Steps

The relational database schema for obsolescence management is defined based on modular integrity principles.

The next step in the data architecture process will focus on integration automation. We will evaluate development in Python, using the Pandas library, to engineer an extraction, transformation, and loading (ETL) pipeline capable of ingesting BOM lists in Excel format and structurally populating them into this Supabase ecosystem. Subscribe to access this operational phase.

S&OP Engineering III: The End of Excel (Linear Programming for Supply Planning)

Wed, 01 Apr 2026 06:01:26 +0000

"We always want 4 weeks of coverage." This phrase, repeated like a mantra in every S&OP meeting on the planet, is financially toxic.

Why? Because it's a fixed rule applied to a dynamic system. If your demand in January is 200 units and in July is 20, you're forcing yourself to maintain 800 and 80 units respectively "just in case." January falls short. July immobilizes capital for no reason.

The alternative isn't more sophisticated intuition. It's mathematics.

Executive Summary: In this chapter, we connect the probabilistic forecast from Chapter 2 with a Linear Programming engine (PuLP) that calculates the exact production plan minimizing total cost (production + storage) while respecting Safety Stock constraints. We move from passive prediction to active prescription.

From Forecast to Decision: Architecture

In Chapter 1 we cleaned the signal. In Chapter 2 we predicted demand. Now we take the step Excel can't: optimize.

Our pipeline on GitHub connects to Supabase, reads the demand_forecasts table (the future we predicted), and generates a new supply_plans table. The system has evolved from descriptive (what happened?) to predictive (what will happen?) and now to prescriptive (what should I do?).

This is Operations Research. The same discipline that optimizes airline routes, military logistics, and global supply chains. And we run it with 50 lines of Python.

The Mathematics of Business

We're not going to hide the equations. They're the heart of the decision. Here's the core fragment from our SupplyOptimizer class:

# Objective Function: Minimize total cost
problem += pulp.lpSum(
    production_cost * production[t] + holding_cost * inventory[t]
    for t in range(T)
), "Total_Cost"

# Constraint: Inventory Balance (Conservation of Mass)
for t in range(T):
    prev_inv = initial_inventory if t == 0 else inventory[t - 1]
    problem += (
        inventory[t] == prev_inv + production[t] - demand[t],
        f"Balance_t{t}"
    )

# Constraint: Safety Stock (Risk Policy)
for t in range(T):
    problem += (
        inventory[t] >= safety_stock,
        f"SafetyStock_t{t}"
    )

Three engineering decisions worth explaining:

The Objective Function doesn't seek "lots of stock" or "high production." It seeks the minimum financial cost: the equilibrium between manufacturing (expensive) and storing (also expensive). The solver automatically finds the exact point where the combined cost is minimal.

The Mass Balance is a physical constraint: you can't sell what you don't have. Today's inventory equals yesterday's, plus what you produce today, minus what you sell. No magic. The equations forbid cheating.

The Safety Stock is the risk policy: never let inventory drop below a safety minimum. In our case, 1.5 months of average demand. The system calculates this, not a spreadsheet with a number pulled from thin air.

The Master Plan: From Algorithm to Business Decision

This is what the Operations Director needs to see. The algorithm doesn't produce uniformly: if it detects a massive demand spike in one period, it decides to "pre-build" inventory in preceding months to flatten the production load. If Holding Cost is high, it keeps the warehouse empty and manufactures Just-in-Time. Excel doesn't do this on its own; mathematics does.

The result from our solver with test data:

Production cost: €1,680
Storage cost: €540
Total optimized cost: €2,220

This number is not an estimate. It's the provable global minimum given the constraints. If someone proposes a cheaper plan with the same parameters, they're violating a constraint.

Open Kitchen: Play with the Solver

I distrust theories that can't be put into practice. That's why I've prepared a Google Colab where you can run the optimizer on a snapshot of our real data.

The most revealing experiment: change holding_cost to an extremely high value (e.g., €50/unit). Watch how the algorithm automatically decides to manufacture Just-in-Time and keep the warehouse practically empty. Then lower the production cost and watch it prefer to produce in bulk and store. Mathematics adapts. Excel's fixed rules don't.

Open the Interactive Google Colab

Modify the costs, capacity constraints, Safety Stock. Do engineering, not faith.

The Complete Chain: From Data to Decisions

With this third chapter, we've built an end-to-end S&OP system that goes from a dirty ERP CSV to an optimal production plan:

Next Step: Scaling to Enterprise

We now have the perfect plan in our database. But only for one product. What happens when you add 3 SKUs sharing the same factory?

In Chapter 4 we break the MVP: we inject multi-product data with radically different profiles, parallelize the forecasting with MLOps, and build a unified Linear Programming model where products compete mathematically for shared production capacity.

The difference between an Operations Director who plans and one who optimizes is an objective function between their intuition and reality.

S&OP: Why Your Excel Is Lying to You (and How to Interrogate It with Python)

Wed, 25 Mar 2026 07:22:37 +0000

In S&OP (Sales & Operations Planning) meetings, opinions are often discussed instead of facts. "I think we'll sell more", "Last month was weird".

The root problem is not the lack of business vision, it's the lack of signal integrity.

Most supply chains are managed on spreadsheets that accept anything: dates as text, blank spaces, and typos that turn a 100-unit order into 100,000. When you feed your prediction algorithm with that "garbage," you get amplified garbage (the financial Bullwhip effect).

Today we kick off the S&OP Engineering series. We're not going to talk theory; we're going to build a data architecture that audits your business automatically.

The Problem: Signal-to-Noise Ratio

In telecommunications (my original background), noise is any interference that corrupts the signal. In Supply Chain, "noise" is dirty data.

If you don't filter the noise before planning demand, you're immobilizing capital. An undetected outlier is money on fire. If your algorithm sees a false spike of 100,000 units, it will order raw materials you don't need, burning cash and taking up warehouse space. Data hygiene is not 'cleaning', it's protecting your operating margin.

The Visual Evidence

Before seeing a single line of code, look at the difference between what your ERP exports (top) and the statistical reality of your demand (bottom).

Top: Raw data with human errors. Bottom: The clean signal ready for AI algorithms.

The Solution: "Quality Valve" Architecture

To solve this, we apply First Principles Thinking. We don't need to "be more careful" with Excel. We need a system that mathematically prohibits the entry of dirty data into our "Single Source of Truth."

We've designed an automated pipeline with the following stack:

Brain: Python (Pandas + Scipy) for statistical logic.
Warehouse: Supabase (PostgreSQL) as the "Single Source of Truth."
Agent: A script that runs automatically when new files arrive.

The Code: Statistics > Intuition

We don't use fixed rules ("if greater than 1000, delete"). We use statistics. We implement the Z-Score, which measures how many standard deviations a data point is from the mean.

If a sale has a Z-Score > 3 (it's more than 3 sigmas from normality), it's mathematically unlikely to be standard behavior. The system doesn't delete it (it could be a real sale), but it flags it for audit and excludes it from automatic prediction.

Note: We use Z-Score assuming normality to simplify this example. In production scenarios with intermittent demand, we use methods like IQR (Interquartile Range) or MAD (Median Absolute Deviation) which are more robust for non-Gaussian distributions.

[Image of box plot showing Interquartile Range (IQR) and outliers]

Here's the core logic from our SupplyChainSanitizer class:

def detect_outliers_zscore(self, threshold=3):
    """
    Detects statistical anomalies using Z-Score.
    We don't delete the row (info loss), we label it.
    """
    # Calculate the standard deviation of the signal
    z_scores = np.abs(stats.zscore(self.df['qty']))
    
    # Flag what is mathematically suspicious
    self.df['is_outlier'] = z_scores > threshold
    return self

Open Kitchen: Try It Yourself

As an engineer, I distrust what I can't execute. That's why I've isolated the cleaning logic in an interactive Colab Notebook.

You don't need to install Python or configure databases. I've prepared an ephemeral environment where you can:

Generate a corrupt sales dataset (simulated).
Run the SupplyChainSanitizer cleaning engine.
See how the algorithm detects and separates the noise.

Click the button, hit "Play" on the cells, and observe data engineering in action.

Production Architecture (Behind the Scenes)

For technical profiles interested in how this scales in a real company (Datalaria Core):

Ingestion: CSVs are uploaded to a private Bucket in Supabase Storage or a local database.
Trigger: A Python worker detects the file.
Processing: Executes the cleaning in memory (Docker Container).
Persistence: Clean data is injected into PostgreSQL using Row Level Security (RLS) to ensure nobody can manually alter the financial history.

Security Note: In production, we never connect scripts with superuser permissions. We use specific Service Roles and strict RLS policies to ensure supply chain integrity.

Data Flow Visualization

The following diagram shows how "dirty" data passes through our Quality Valve before reaching the Single Source of Truth:

Legend:

Red: Raw data with noise (the problem)
Green: Clean signal ready for prediction
Orange: Anomalies labeled for human review
Blue: Centralized warehouse (Supabase)

Next Step: Scientific Prediction

Now that we have a clean database (a pure signal), we're ready to look into the future.

In the next chapter of the series, we'll connect this clean table with Facebook Prophet to generate probabilistic demand forecasts, forever abandoning Excel's simple moving averages.

Subscribe to receive Chapter 2: "Demand Planning: From Guessing to Probability".

From Zero to Hero: Create a Cyberpunk Snake Game with Real-Time Ranking using Supabase and Vanilla J

Tue, 17 Mar 2026 06:55:03 +0000

Do you remember the classic Snake from the old Nokias? Now imagine it with neon lights, synthesized music, explosive particles, and most importantly: connected to the cloud.

Web game development has experienced a renaissance thanks to the power of HTML5 Canvas and Serverless tools. In the past, if you wanted to save your players' scores to create a global leaderboard, you needed to set up a server, configure a REST API, manage databases, and pay for hosting. Today, thanks to Backend-as-a-Service (BaaS), we can do it in minutes.

In this tutorial, we are going to build "Neon Snake", an aesthetic and functional web arcade game that uses Supabase (an Open Source alternative to Firebase) to persist data in PostgreSQL.

️ The Tech Stack

We're going to keep it simple but powerful. No heavy frameworks, just the purity of the web:

Frontend: HTML5 Canvas + Vanilla JavaScript (ES6+).
Styles: Tailwind CSS (via CDN) for the user interface.
Backend: Supabase (PostgreSQL + Realtime).
Audio: Web Audio API for code-generated sound effects.

Step 1: Setting up the Backend with Supabase

Before writing a single line of JavaScript, we need our brain in the cloud. Supabase offers us a real PostgreSQL database with an automatically generated API.

Create a free account at supabase.com.
Create a new project called NeonSnake.
Go to the Table Editor section and create a new table called snake_scores.

The Magic of SQL

To streamline the process, Supabase allows you to execute SQL commands directly. Go to the SQL Editor and paste the following code. This will create the table structure and configure the security policies (RLS - Row Level Security) so your game can read and write data publicly.

-- 1. Create the scores table
create table snake_scores (
  id bigint generated by default as identity primary key,
  username text not null,
  score integer not null,
  created_at timestamp with time zone default timezone('utc'::text, now()) not null
);

-- 2. Enable Row Level Security (RLS)
alter table snake_scores enable row level security;

-- 3. Policy to allow anyone to view the ranking (Public Read)
create policy "Ver ranking publico"
on snake_scores for select
using ( true );

-- 4. Policy to allow anyone to save their record (Public Write)
create policy "Guardar puntuacion"
on snake_scores for insert
with check ( true );

Security Note: In a commercial game, we would use full user authentication. For this arcade-style demo, we allow public (anonymous) access to reduce friction so anyone can play and log their record instantly.

Finally, go to Settings > API and copy your Project URL and your anon public key. You will need them shortly.

Step 2: The Cyberpunk Frontend (HTML5 + Canvas)

Our game will live in a single index.html file. We will use Tailwind CSS for the floating menus (Game Over, Start Screen) and the <canvas> element to render the game at 60 FPS.

The basic structure is as follows:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Neon Snake 2077</title>
    <script src="[https://cdn.tailwindcss.com](https://cdn.tailwindcss.com)"></script>
    <style>
        @import url('[https://fonts.googleapis.com/css2?family=Orbitron:wght@400;700&display=swap](https://fonts.googleapis.com/css2?family=Orbitron:wght@400;700&display=swap)');
        body { font-family: 'Orbitron', sans-serif; background-color: #050505; }
        /* Neon glow effect for the canvas */
        canvas { box-shadow: 0 0 20px #0ff; border: 2px solid #0ff; }
    </style>
</head>
<body class="h-screen w-full flex items-center justify-center overflow-hidden bg-gray-900">

    <div class="relative">
        <canvas id="gameCanvas" width="400" height="400"></canvas>
        
        <div id="gameOverMenu" class="hidden absolute inset-0 bg-black/90 flex flex-col items-center justify-center z-10">
            <h2 class="text-4xl text-red-500 font-bold mb-4 drop-shadow-[0_0_10px_rgba(239,68,68,0.8)]">SYSTEM FAILURE</h2>
            <input type="text" id="usernameInput" placeholder="Enter ID..." class="bg-gray-800 text-cyan-400 p-2 rounded border border-cyan-500 mb-4 text-center outline-none">
            <button id="saveBtn" class="bg-cyan-600 hover:bg-cyan-500 text-white font-bold py-2 px-4 rounded shadow-[0_0_15px_#06b6d4] transition-all">
                UPLOAD DATA
            </button>
            
            <div id="leaderboard" class="mt-6 text-sm text-gray-300 w-64 text-left h-40 overflow-y-auto custom-scrollbar"></div>
        </div>
    </div>

    <script type="module">
        import { createClient } from '[https://cdn.jsdelivr.net/npm/@supabase/supabase-js/+esm](https://cdn.jsdelivr.net/npm/@supabase/supabase-js/+esm)'
        
        // ... Game Logic here (See step 3) ...
    </script>
</body>
</html>

Game Logic: Beyond Eating Apples

To give it that "Pro" touch and differentiate it from a basic tutorial, we implement several key mechanics in JavaScript:

Animation Loop: Using requestAnimationFrame to maintain fluidity at 60 FPS.
Particle System: An array of objects that spawn at the "food" coordinates when eaten and fade gradually, simulating a data explosion.
Dynamic Firewalls: From level 5 onwards, we generate static obstacles that the player must dodge, progressively increasing the difficulty.
Hybrid Controls:
- PC: We listen for keydown events for directional arrows.
- Mobile: We capture touchstart and touchend to calculate the gesture direction (swipe) and move the snake.

Step 3: Connecting the Dots (Integration with Supabase)

Here is where the Backend-as-a-Service magic happens. We are going to connect our Canvas to the PostgreSQL database. Inside our <script type="module"> tag:

1. Client Initialization

const supabaseUrl = 'YOUR_SUPABASE_PROJECT_URL';
const supabaseKey = 'YOUR_SUPABASE_ANON_KEY';
const supabase = createClient(supabaseUrl, supabaseKey);

2. The "Game Over" Flow

When the player loses and hits "UPLOAD DATA", we need to ensure the data is saved before showing the leaderboard. We will use async/await to control this asynchronous flow.

async function saveScore(username, score) {
    // 1. Save the score
    const { error } = await supabase
        .from('snake_scores')
        .insert([{ username: username, score: score }]);

    if (error) {
        console.error('Error uploading data:', error);
        alert('Connection error with the central server.');
        return;
    }
    
    // 2. Immediately after, update the leaderboard visually
    fetchLeaderboard();
}

3. Fetching the Ranking (Select)

We retrieve the Top 20 sorted by score in descending order to show who rules the server.

async function fetchLeaderboard() {
    const { data: scores, error } = await supabase
        .from('snake_scores')
        .select('username, score')
        .order('score', { ascending: false }) // Descending order
        .limit(20);                           // Only the top 20

    if (error) console.error('Error fetching leaderboard:', error);
    
    // Render in the DOM
    const list = document.getElementById('leaderboard');
    list.innerHTML = '<h3 class="text-cyan-400 border-b border-cyan-500 mb-2 font-bold">TOP HACKERS</h3>';
    
    scores.forEach((entry, index) => {
        // Highlight top 3 with different colors if you want
        const colorClass = index < 3 ? 'text-yellow-400' : 'text-gray-300';
        
        list.innerHTML += `
            <div class="flex justify-between py-1 border-b border-gray-800">
                <span class="${colorClass}">#${index + 1} ${entry.username}</span>
                <span class="text-cyan-300 font-mono">${entry.score}</span>
            </div>`;
    });
}

Bonus: Realtime ⚡

Do you want the ranking to update on everyone's screen if someone breaks the record at that precise moment? Supabase makes this trivial with its subscriptions:

// Subscribe to changes in the 'snake_scores' table
supabase
  .channel('public:snake_scores')
  .on('postgres_changes', 
      { event: 'INSERT', schema: 'public', table: 'snake_scores' }, 
      (payload) => {
        console.log('New record detected on the network!', payload);
        fetchLeaderboard(); // Automatically refresh the list for everyone
      }
  )
  .subscribe();

The Final Result

By putting it all together, you get a fluid and highly competitive user experience:

The user plays frantically dodging neon "Firewalls".
Upon crashing, the game stops with a visual "glitch" effect.
They enter their name (e.g., "Neo").
Upon clicking send, in milliseconds, their name appears on the leaderboard.
If their friend is playing on another mobile at the same time, they will see "Neo's" name appear on their screen without reloading the page.

And once created... all that remains is to enjoy and play

Datalaria Snake Game

Conclusion

We have moved from a simple static canvas to a Fullstack application in real-time without touching a traditional backend server (Node.js, PHP, Python) or managing infrastructure. The combination of creativity in game development with the power of BaaS tools like Supabase opens a world of possibilities for frontend developers.

The next step? I invite you to clone the project and improve it: add GitHub authentication to avoid duplicate names, create snake skins that unlock with high scores, or implement a multiplayer mode using Supabase presence channels.

The code is yours!

Did you like this tutorial? Share it on your networks with your High Scores and don't forget to check the official Supabase documentation to dive deeper.

Building Bridges with Code: How We Created a Multilingual Audio Learning Platform

Tue, 03 Feb 2026 12:16:07 +0000

Subtitle: A technical journey inside the Interim Federal Education Council’s mission to digitize and localize Civic Education using Next.js and Supabase.

Introduction: The Urgent Need for Inclusive Education
In the diverse educational landscape of Myanmar, language is often the biggest barrier to learning. For the Interim Federal Education Council (IFEC), ensuring Grade 6-9 students have access to vital Civic Education curriculum meant going beyond the standard English and Myanmar textbooks.
We faced a massive challenge: How do we take a standardized curriculum and transform it into accessible, engaging audio lessons for students speaking Kachin, Karenni, Karen, Chin, Mon, Rakhine, and Shan?
We needed a digital hub—a place where language experts could easily contribute translations, and students could easily listen. We didn't have a massive engineering team; we needed speed, reliability, and ease of use.
This is the story of how we built the IFEC Civic Education Platform from a simple idea into a live, full-stack web application.

The Solution: The "Podcast" Approach & Tech Stack
We decided on an audio-first approach. "Podcasts" are accessible, low-bandwidth, and easy to consume on mobile devices.
To build the platform, we chose a modern, powerful technology stack geared toward rapid development:
Frontend: Next.js (React): For building a fast, interactive user interface that works well on phones and laptops.

Backend & Storage: Supabase: An open-source Firebase alternative. It provided us with a real-time database to store lesson details and secure cloud storage for large MP3 and PDF files, all without needing to manage our own servers.

Phase 1: Laying the Foundation (The Backend)
Before writing a single line of frontend code, we had to model our data in Supabase. We needed two critical components:
File Storage: We created a public storage bucket named civic_podcasts to house the MP3 audio files and optional PDF scripts.
The Database: We set up a lessons table to track the metadata for every file uploaded. Key fields included:
title (Text)
grade_level (Number, 6-9)
language (Text)
audio_url & pdf_url (Links to the files in storage)

Lesson Learned: A solid data structure at the start makes the frontend development much easier later on.

Phase 2: Building the "Expert Portal" (The Upload Flow)
Our language experts are educators, not engineers. The upload process needed to be incredibly simple.
We built a secure /upload page in Next.js. It featured a straightforward form where experts select the grade and language, attach their files, and enter a shared Admin Access Code for security.
The Technical Hurdles: Building this wasn't without challenges. We encountered two major hurdles that are common in full-stack development:
Hurdle 1: The "Database Lock" (Row-Level Security): Initially, all uploads failed. Supabase is secure by default, meaning it blocks all database insertions unless explicitly allowed. We had to write specific SQL Policies to "unlock" the database for inserts, relying on our frontend access code for security.
Hurdle 2: File Conflicts: If an expert tried to re-upload a corrected version of a lesson, the storage system would reject it because a file with that name already existed. We solved this by implementing an upsert: true (update or insert) command in our code, forcing the system to overwrite old files with new versions.

Phase 3: The Student Experience (UI/UX Transformation)
Once we could get data in, we needed to get it out in an engaging way.
Our initial student view was a basic list of links. It worked, but it wasn't inspiring. We realized that for grade school students, the design needed to be vibrant and intuitive.
We transformed the interface into a modern, card-based layout. We used color-coding to create visual distinction: blue for Grade 6, teal for Grade 7, orange for Grade 8, and purple for Grade 9.
We also added crucial functionality. We realized audio wasn't always enough; some students needed to read along. We updated the upload portal to accept PDF transcripts and added a prominent " Read Script" button to the student-facing cards.

Phase 4: Distribution and Real-World Use
A great platform is useless if teachers can't share it. In many classrooms in Myanmar, sharing long URLs is impractical.
To solve the "last mile" distribution problem, we integrated a dynamic QR code directly onto the platform's homepage. A teacher can now simply open their laptop, scroll down, and have an entire classroom scan the screen to instantly load the lessons on their mobile devices.

Conclusion: From Concept to Classroom
In a very short time, we moved from an abstract requirement to a deployed, multilingual educational tool.
Today, the platform stands ready. Language administrators have a secure dashboard to manage content, and students have a colorful, engaging hub to access vital Civic Education in their mother tongue.
This project proved that with the right modern tools like Next.js and Supabase, complex logistical challenges in education can be solved efficiently, creating real impact where it’s needed most.
[Link to the live IFEC platform: https://ifec-civic-platform.vercel.app/]

What is Supabase and Supabase Edge Functions? What's the main use?

Sat, 02 Aug 2025 20:48:12 +0000

Supabase is an open-source backend-as-a-service (BaaS) platform that helps developers build secure, scalable applications quickly. It provides a suite of backend tools—similar to Firebase—but built on open standards like PostgreSQL.

What Supabase Offers (Core Features):

PostgreSQL Database – A powerful, scalable, open-source SQL database.
Auth – User authentication and authorization with support for social logins (Google, GitHub, etc.).
Realtime – Realtime updates using websockets (e.g., when database rows change).
Storage – File storage (images, videos, docs) with access control.
Edge Functions – Serverless functions that run close to the user (more below).
APIs – Auto-generated REST and GraphQL APIs for your database.
Dashboard – A web-based GUI for managing your backend.

⚡ Supabase Edge Functions

Supabase Edge Functions are serverless functions that you write in JavaScript or TypeScript and deploy to run on Deno (a secure runtime similar to Node.js but more modern).

Main Use of Edge Functions:

They are designed for handling backend logic that shouldn't live directly in the client or the database.

✅ Use Cases Include:

Custom API endpoints (e.g., payment processing, webhook handling)
Middleware logic (e.g., verifying tokens, checking user roles)
Connecting to third-party APIs (e.g., Stripe, Twilio, etc.)
Running logic on scheduled intervals (e.g., cron jobs)
Doing something that SQL triggers can’t handle

Why Use Supabase and Edge Functions Together?

Use Supabase to handle your core app data and auth.
Use Edge Functions to handle custom logic securely and efficiently.
Keep everything in one platform, tightly integrated.

quick comparison and a simple example to help you understand how Supabase Edge Functions work—especially compared to Firebase Cloud Functions.

Comparison: Supabase Edge Functions vs Firebase Functions

Feature	Supabase Edge Functions	Firebase Cloud Functions
Runtime	Deno (TypeScript-native)	Node.js
Deployment Time	Fast (\~seconds)	Slower (\~minutes)
Cold Start	Very Low (Deno edge runtime)	Can be noticeable
Region	Edge (closer to user, low latency)	Usually centralized
Language Support	TypeScript, JavaScript	JavaScript, TypeScript
Tied to Backend (DB, Auth)	Yes – deeply integrated with Supabase	Yes – integrated with Firebase
Hosting Model	Serverless, edge-deployed	Serverless, central

✅ Simple Use Case Example

Scenario:

You want to verify that a user has a valid subscription before letting them access premium content.

1. In Firebase:

You’d write a cloud function like this (Node.js):

exports.checkSubscription = functions.https.onRequest((req, res) => {
  const userId = req.body.userId;
  // Call Stripe or check Firestore
  // Return access status
});

2. In Supabase (Edge Function):

// supabase/functions/check-subscription/index.ts

import { serve } from "https://deno.land/std/http/server.ts";

serve(async (req) => {
  const { userId } = await req.json();

  // Call Stripe API, or query your Supabase DB
  const isActive = true; // pretend check

  return new Response(JSON.stringify({
    access: isActive ? "granted" : "denied"
  }), {
    headers: { "Content-Type": "application/json" },
  });
});

➕ Bonus:

You can secure this function by requiring Supabase Auth tokens and decoding them right inside the function.

How to Deploy (CLI):

supabase functions deploy check-subscription

Then call it from your frontend:

const res = await fetch("/functions/v1/check-subscription", {
  method: "POST",
  headers: { "Authorization": `Bearer ${userToken}` },
  body: JSON.stringify({ userId }),
});

How I Survived My First Full stack App with Next.js

Fri, 18 Jul 2025 12:38:28 +0000

The story begins—as it always does—with a tutorial.

I was watching yet another video and thought: “Let’s build a full stack app.” I already had a background in React, and I’d made a few full stack projects before. So this time, I chose Next.js. It looked easy, especially with the new App Router.

Why Next.js? Because it’s React at the front, backend APIs included, and server actions baked right in. No need for separate Express servers or wiring up extra routers. Also, the assumption was simple: everything is a server component unless you slap a "use client" on top. I was in.

✨ Why I Fell in Love with the App Router

One of the best things about Next.js is the App Router. You don’t need to install React Router and define routes in App.jsx. Just drop a file in the /app folder, and boom—it’s a route. It's simple. It’s fast. It works.

First Battle: The UI Fear

Here’s my harsh truth—I suck at design.

My pages looked ugly. And that really messes with you. It triggers imposter syndrome. I’d open VS Code, freeze, and think: What do I even build here? The spiral begins: “Am I even cut out for frontend dev?”

Sound familiar? Been there. This time, I didn’t let it win.

Here's how I beat the block:

Took breaks when stuck.
Drew wireframes, even if they were ugly. Just enough to give me direction.
Used inspiration from other websites. Seriously, 90% of the internet uses the same layout tricks. Why not learn from them?
Tools like Google Stitch, v0.dev, and Bolt helped generate page ideas and inspiration.

Any progress is better than no progress. Remember that.

❤️ Server Actions

God bless Server Actions.

No more creating an API route or writing fetch calls and handling them manually. Need to read from the server? Just keep the page component as a server component, use a Server Action to grab the data, and pass it down to your client components. Done.

You can use server actions inside client components too, but there are caveats. I won’t pretend I know them all—this project was me figuring things out on the fly. So I won’t preach, but here’s what worked for me:

Keep data fetching in server components.
Use server actions to mutate or fetch data.
If using forms, yes—you can still call server actions from client components.

How I Wrote Ugly Code—Fast

Not gonna lie. I was a messy developer in the beginning.

Every time I made a new page/component, I didn't care about reusability. Things got chaotic fast.

But I followed one rule: put every component inside a well-named folder. For example: /components/dashboard/Table.tsx. Later, when I needed it somewhere else, I refactored it—added props, defined interfaces, added type safety—and made it reusable.

So... am I a great React developer? Maybe not.

Am I resourceful and fast? Yes.

Best case: smart developer.

Worst case: functional chaos.

The Email Saga

Now I understand why dev’s complain about bad DX (Developer Experience) on Twitter.

Until now, I had a chill life—React + Vite, everything worked like magic. But for this project, I needed to send emails inviting users to give feedback.

I initially tried Mailjet — looked promising, solid docs, decent limits. But then... everything broke after sending just 5 emails.

I got hit with a "temporary restriction" and no real explanation. Just a vague message and complete silence. I waited three days, hoping the ban would lift. Spoiler: it didn’t.

That’s when I realized how important good developer experience really is.

If I ever build a dev tool, I’m writing great docs, clear errors, and probably a fun YouTube guide.

So, I ditched Mailjet and moved to Resend — and this time, everything just worked. Fast setup, friendly DX, and no cryptic errors.

❤️ Huge shoutout to Resend.

???? No hard feelings, Mailjet — but that experience wasn’t it.

The Broken Database Horror

After surviving all that, I wanted to brag on LinkedIn: “Hey look! I integrated payments!” Even if they were test payments—still, it’s progress.

But the horror unfolded quickly.

Understanding how payments work end-to-end—from initiation to confirmation—is critical. If you don’t, you’ll keep breaking your schema with every little change.

What I learned:

If you're dealing with third-party APIs or external systems, always:

Track their status (pending, success, failure)
Use enum fields to reflect the state
Expect that some parts of the flow are out of your control

Know what you're storing and when. Or prepare to suffer. And yes, it will become a dev horror story.

Linting + TypeScript Woes

I used to think linting was just that one VS Code extension that makes code pretty.

Then I ran npm run build.

Boom. 10,000+ lines of errors. Why? It tried to lint the auto-generated code too.

So yeah, I had to:

Fix unused variables
Replace any types
Update configs to ignore generated folders

Lesson learned: don't skip linting. TypeScript isn’t just for safety—it’s a build-saver.

Deployment & Production Nightmares

I’d spent a month building this project. Now it was time to ship. Resume-ready, you know?

I used Vercel. Guess what?

Vercel kept trying to render server pages as static. My build kept failing.

Turns out: Vercel will try to statically generate everything unless you tell it not to.

Solution:

export const dynamic = "force-dynamic";

Boom. Now it knows your page is meant to run server-side only.

Oh, and Supabase—my free DB. Connecting it was hell.

There’s a pooled connection (for normal ops)
And a direct connection (for migrations)

But Prisma didn’t play well with pooled URLs. It caused weird, unexpected issues.

Fix:

Use Supabase’s "stable connection string" for local + migrations
Use Prisma Accelerate in production with the correct URL
Add the Accelerate URL to your .env.production

After that, things worked. Kinda.

Final Thoughts

You may not have learned any technical tricks from this post. But that’s the point.

Things will break.

Abstractions will leak.

You’ll be stuck. Frustrated. Confused.

But you’re a builder. And builders show up.

That’s what matters.

❤️ Takeaway

Everyone can teach you code. I want to teach you a mindset.

If you remember just two things from this post:

Break things. That’s how you learn.
Draw wireframes. Ugly ones. It gives you momentum.

That’s it. You’ll be 10x faster than me if you just start.

Follow My Journey

I write about my dev rants, lessons, and experiments—sometimes messy, sometimes insightful. If this resonated, follow me. I don’t just rant—I teach too.

Next up: how I broke and optimized my backend.

Till then,

Break. Fix. Weep. Shine.

— Love and peace,

Your fellow dev

Farewell & Little Sendoff Gifts for Curious Minds

Thanks for sticking around! If you're curious to poke around or steal some ideas (I won't tell), here are a few goodies:

Live App:

Create Next App

GitHub Repo: https://github.com/PRASHANTSWAROOP001/feedback-nextjs-app
Wireframes (Chaos Included): https://raw.githubusercontent.com/PRASHANTSWAROOP001/contact-page/refs/heads/main/wireframe2.jpg, https://github.com/PRASHANTSWAROOP001/contact-page/blob/main/wireframe1.jpg?raw=true

Building Scalable React Native Apps with Nucleux and Supabase

Tue, 15 Jul 2025 03:35:09 +0000

Combining Supabase's powerful backend services with Nucleux's atomic state management creates a clean, scalable architecture for React Native applications. This guide shows you how to structure authentication and API services using class-based stores that naturally organize your application logic.

The Architecture Pattern

We'll build a three-layer architecture that separates concerns cleanly:

ApiService: Handles Supabase client configuration and lifecycle
SessionStore: Manages authentication state and user sessions
Auth Component: Provides the user interface for authentication

This pattern leverages Nucleux's dependency injection to create a clean separation where each layer has a single responsibility.

Setting Up the API Service

First, create a centralized API service that manages the Supabase client:

// src/services/ApiService.ts
import AsyncStorage from "@react-native-async-storage/async-storage";
import { createClient, SupabaseClient } from "@supabase/supabase-js";
import { Store } from "nucleux";
import { AppState, NativeEventSubscription, Platform } from "react-native";
import "react-native-url-polyfill/auto";

if (
  process.env.EXPO_PUBLIC_SUPABASE_URL === undefined ||
  process.env.EXPO_PUBLIC_SUPABASE_ANON_KEY === undefined
) {
  throw new Error("Missing critical environment variables");
}

class ApiService extends Store {
  public apiClient: SupabaseClient;
  private appStateSubscription: NativeEventSubscription;

  constructor() {
    super();

    this.apiClient = createClient(
      process.env.EXPO_PUBLIC_SUPABASE_URL || "",
      process.env.EXPO_PUBLIC_SUPABASE_ANON_KEY || "",
      {
        auth: {
          storage: AsyncStorage,
          autoRefreshToken: true,
          persistSession: true,
          detectSessionInUrl: false,
        },
      }
    );

    this.appStateSubscription = AppState.addEventListener("change", (state) => {
      if (state === "active") {
        this.apiClient.auth.startAutoRefresh();
      } else {
        this.apiClient.auth.stopAutoRefresh();
      }
    });
  }

  destroy() {
    this.appStateSubscription.remove();
    super.destroy();
  }
}

export default ApiService;

Key Benefits:

Centralized Configuration: Single place to manage Supabase setup
Lifecycle Management: Properly manages token refresh based on app state

Creating the Session Store

The SessionStore handles all authentication logic while staying completely decoupled from UI concerns:

// src/stores/SessionStore.ts
import ApiService from "@/services/ApiService";
import { Session, Subscription } from "@supabase/supabase-js";
import { Store } from "nucleux";

class SessionStore extends Store {
  public session = this.atom<Session | null>(null);
  public initialized = this.atom<boolean>(false);

  private apiService = this.inject(ApiService);
  private authSubscription: Subscription;

  constructor() {
    super();
    
    this.getSession();
    
    this.authSubscription = this.apiService.apiClient.auth.onAuthStateChange(
      (_, session) => {
        this.setSession(session);
      }
    ).data.subscription;
  }

  private async getSession() {
    try {
      const { data: { session } } = await this.apiService.apiClient.auth.getSession();
      this.setSession(session);
    } finally {
      this.initialized.value = true;
    }
  }

  private setSession(session: Session | null) {
    this.session.value = session;
  }

  public async signIn(email: string, password: string) {
    return this.apiService.apiClient.auth.signInWithPassword({
      email,
      password,
    });
  }

  public async signOut() {
    return this.apiService.apiClient.auth.signOut();
  }

  destroy() {
    this.authSubscription.unsubscribe();
    super.destroy();
  }
}

export default SessionStore;

Architecture Highlights:

Dependency Injection: this.inject(ApiService) automatically provides the API client
Atomic State: Only components using session or initialized re-render when these values change
Event Handling: Supabase auth changes automatically update the atomic state
Clean API: Simple methods for sign in/out that any component can use

Building the Auth Component

Finally, create a simple authentication component that consumes the session store:

// components/Auth.tsx
import SessionStore from "@/stores/SessionStore";
import { useStore, useValue } from "nucleux";
import React, { useState } from "react";
import { Alert, StyleSheet, Text, TextInput, TouchableOpacity, View } from "react-native";

export default function Auth() {
  const sessionStore = useStore(SessionStore);
  const session = useValue(sessionStore.session);
  const initialized = useValue(sessionStore.initialized);

  const [email, setEmail] = useState("");
  const [password, setPassword] = useState("");
  const [loading, setLoading] = useState(false);

  const handleSignIn = async () => {
    if (!email || !password) {
      Alert.alert("Error", "Please fill in all fields");
      return;
    }

    setLoading(true);
    try {
      const { error } = await sessionStore.signIn(email, password);
      if (error) Alert.alert("Error", error.message);
    } finally {
      setLoading(false);
    }
  };

  const handleSignOut = async () => {
    const { error } = await sessionStore.signOut();
    if (error) Alert.alert("Error", error.message);
  };

  if (!initialized) {
    return <Text>Loading...</Text>;
  }

  if (session) {
    return (
      <View style={styles.container}>
        <Text style={styles.title}>Welcome back!</Text>
        <Text>Signed in as: {session.user.email}</Text>
        <TouchableOpacity style={styles.button} onPress={handleSignOut}>
          <Text style={styles.buttonText}>Sign Out</Text>
        </TouchableOpacity>
      </View>
    );
  }

  return (
    <View style={styles.container}>
      <Text style={styles.title}>Sign In</Text>
      
      <TextInput
        style={styles.input}
        placeholder="Email"
        value={email}
        onChangeText={setEmail}
        autoCapitalize="none"
        keyboardType="email-address"
      />
      
      <TextInput
        style={styles.input}
        placeholder="Password"
        value={password}
        onChangeText={setPassword}
        secureTextEntry
      />
      
      <TouchableOpacity 
        style={[styles.button, loading && styles.buttonDisabled]} 
        onPress={handleSignIn}
        disabled={loading}
      >
        <Text style={styles.buttonText}>
          {loading ? "Signing In..." : "Sign In"}
        </Text>
      </TouchableOpacity>
    </View>
  );
}

const styles = StyleSheet.create({
  container: { flex: 1, padding: 20, justifyContent: "center" },
  title: { fontSize: 24, fontWeight: "bold", marginBottom: 20, textAlign: "center" },
  input: { borderWidth: 1, borderColor: "#ddd", padding: 12, marginBottom: 10, borderRadius: 5 },
  button: { backgroundColor: "#007AFF", padding: 12, borderRadius: 5, marginTop: 10 },
  buttonDisabled: { opacity: 0.5 },
  buttonText: { color: "white", textAlign: "center", fontWeight: "bold" },
});

Why This Architecture Works

1. Clear Separation of Concerns
Each layer has a single responsibility, making the code easier to test and maintain.

2. Automatic Reactivity
Components automatically re-render when authentication state changes, without manual subscription management.

3. Reusable Business Logic
The SessionStore can be used across multiple components without duplicating authentication logic.

4. Type Safety
TypeScript ensures you catch authentication-related bugs at compile time.

5. Easy Testing
Each store can be unit tested independently of React components.

The Result

This architecture gives you a robust foundation for React Native apps that need authentication. The SessionStore becomes the single source of truth for authentication state, while the component layer focuses purely on user interface concerns.

Want to explore more patterns? Check out the complete Nucleux documentation and see how this same approach scales to complex applications with multiple data stores and API services.

Ready to build your next React Native app? Try combining Nucleux with Supabase for a powerful, type-safe development experience.

Setting Up Next.js Authentication with Supabase: A Complete Guide

Wed, 22 Jan 2025 11:06:58 +0000

Hey there! Its been 2 weeks since my last blog. Damnnn don’t worry guys from this one i will be consistent from this time my promise.
Today, I want to walk you through implementing authentication in your Next.js application using Supabase. I recently did this for a project which i’m building these along with open source contributions(stay tuned will share more details soon ), so I thought I’d share my experience to help others navigate this process more smoothly.

The Setup: What We Need

Before diving in, make sure you have:

A Next.js project (we'll use TypeScript)
A Supabase account with a new project
The @supabase/ssr package installed

Creating Supabase Clients

The first thing we need to understand is that we'll need two different Supabase clients: one for the client-side and another for the server-side. Let's set those up!

Client-Side Setup

In utils/supabase/client.ts, we'll create our browser client:

import { createBrowserClient } from '@supabase/ssr'

export function createClient() {
  return createBrowserClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
  )
}

Server-Side Setup

For server components, we need a slightly different setup in utils/supabase/server.ts:

import { createServerClient } from '@supabase/ssr'
import { cookies } from 'next/headers'

export async function createClient() {
  const cookieStore = await cookies()

  return createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    {
      cookies: {
        getAll() {
          return cookieStore.getAll()
        },
        setAll(cookiesToSet) {
          try {
            cookiesToSet.forEach(({ name, value, options }) =>
              cookieStore.set(name, value, options)
            )
          } catch {
            // This can be ignored if you have middleware refreshing sessions
          }
        },
      },
    }
  )
}

Middleware Magic: Keeping Sessions Fresh

Here's where it gets interesting! We need middleware to handle session refreshing. Create two files:

middleware.ts at your project root:

import { type NextRequest } from 'next/server'
import { updateSession } from '@/utils/supabase/middleware'

export async function middleware(request: NextRequest) {
  return await updateSession(request)
}

export const config = {
  matcher: [
    '/((?!_next/static|_next/image|favicon.ico|.*\\.(?:svg|png|jpg|jpeg|gif|webp)$).*)',
  ],
}

And utils/supabase/middleware.ts:

import { createServerClient } from '@supabase/ssr'
import { NextResponse, type NextRequest } from 'next/server'

export async function updateSession(request: NextRequest) {
  let response = NextResponse.next({ request })
  
  const supabase = createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    {
      cookies: {
        getAll() {
          return request.cookies.getAll()
        },
        setAll(cookiesToSet) {
          cookiesToSet.forEach(({ name, value, options }) => {
            response.cookies.set(name, value, options)
          })
        },
      },
    }
  )

  await supabase.auth.getUser()
  return response
}

Now for the fun part - let's create a login page! Create app/login/page.tsx:

import { login, signup } from './actions'

export default function LoginPage() {
  return (
    <form>
      <label htmlFor="email">Email:</label>
      <input id="email" name="email" type="email" required />
      <label htmlFor="password">Password:</label>
      <input id="password" name="password" type="password" required />
      <button formAction={login}>Log in</button>
      <button formAction={signup}>Sign up</button>
    </form>
  )
}

And the corresponding actions in app/login/actions.ts:

'use server'

import { revalidatePath } from 'next/cache'
import { redirect } from 'next/navigation'
import { createClient } from '@/utils/supabase/server'

export async function login(formData: FormData) {
  const supabase = await createClient()
  
  const data = {
    email: formData.get('email') as string,
    password: formData.get('password') as string,
  }

  const { error } = await supabase.auth.signInWithPassword(data)
  
  if (error) {
    redirect('/error')
  }

  revalidatePath('/', 'layout')
  redirect('/account')
}

export async function signup(formData: FormData) {
  const supabase = await createClient()
  
  const data = {
    email: formData.get('email') as string,
    password: formData.get('password') as string,
  }

  const { error } = await supabase.auth.signUp(data)
  
  if (error) {
    redirect('/error')
  }

  revalidatePath('/', 'layout')
  redirect('/account')
}

Pro Tips and Gotchas

Always use getUser() for Protection: When protecting pages, always use supabase.auth.getUser() instead of getSession(). It's more secure because it validates the auth token with Supabase's servers every time.
Cookie Handling: Server Components can't write cookies directly, which is why we need the middleware to handle session refreshing.
Route Protection: Be careful when protecting routes - remember that cookies can be spoofed, so always verify the user session server-side.
Email Templates: Don't forget to update your Supabase email templates to support server-side auth flows. You'll want to change the confirmation URL format in your email templates.

What's Next?

Now that you have authentication set up, you might want to:

Add social authentication providers
Implement password reset functionality
Create protected API routes
Set up user profiles and additional data storage

The foundation we've built here makes adding these features relatively straightforward.

Remember to check out the Supabase docs and Next.js documentation for more detailed information and advanced features!

Happy coding!

Coder Legion - Recent posts tagged supabase

Extracting a React presence hook from a production event app

Multi-Tenant Architecture in Next.js 16 (2026)

Quick Answer: What Is Multi-Tenant Architecture?

Single-Tenant vs. Multi-Tenant: The Difference That Matters

Why This Is Tricky

The Three Data Isolation Models

Three Ways to Identify a Tenant

What We're Building

Step 1: Project Setup

Step 2: Resolve the Tenant in `proxy.ts`

Step 3: Testing Subdomains Locally

Step 4: Model Tenants and Isolation in Postgres

Write the RLS Policies

Step 5: Read the Tenant in Server Components

Writing Tenant-Scoped Data with a Server Action

Step 6: Deploy Wildcard Domains on Vercel

What About Custom Domains?

Production Checklist

Wrapping Up

Continue Learning

Free Developer Tools

Project LifeOps (Part 1): Personal Operating System Architecture and FastAPI + Supabase Backend

🗺️ LifeOps Series Roadmap

The $0/Month Architecture: How to Run Free at Scale 💡

Relational Data Modeling: Clean Polymorphism in PostgreSQL 🗄️

Why this architecture shines:

The FastAPI Backend: Modular Architecture & Strict Typing ⚡

Secure Supabase JWT Authentication

Production Hardening: Rate Limiting & Anti-Abuse 🛡️

Conclusion and What's Next 🎯

References & Useful Links 🔗

I Moved My Next.js Dashboard Logic Into Postgres. My Frontend Got Boring (And That's the Point).

What "fetching everything into React" actually looks like

Why this is the wrong layer

Moving it into an RPC function

When a view beats a function (and vice versa)

The objections worth taking seriously.

The rule of thumb

How I Built Multi-User Apps with Row-Level Security in Supabase

What RLS actually is

How I applied this in ApplyCraft

The mistakes that will burn you

Feature Flags in SaaS: A Beginner's Guide with Next.js 16 (2026)

Why This Is Tricky

What Is a Feature Flag, Exactly?

Why SaaS Products Rely on Feature Flags

Prerequisites

Part 1: Building Your Own Feature Flag System

Step 1: Create the Feature Flags Table

Step 2: Write a Deterministic Rollout Function

Step 3: Create a Server-Only Function to Read a Flag

First create a service-role Supabase client

Caching Feature Flag Reads with next/cache

Caching the flag row

Invalidating a flag the moment it changes

Step 4: Use the Flag in a Server Component

Step 5: Use the Same Flag in a Server Action

Part 2: Using the Vercel Flags SDK

Step 1: Install the SDK

Step 2: Generate a Flags Secret

Step 3: Define Your Flags in One File

Step 4: Use a Flag in a Page

Step 5: Conditionally Render a Client Component

Best Practices for Feature Flags

Frequently Asked Questions

Do I need a third-party service like LaunchDarkly to use feature flags?

What's the difference between a feature flag and an environment variable?

Can I use feature flags for A/B testing?

Do feature flags have to be true/false?

Are feature flags secure enough to gate paid features?

How many feature flags is too many?

Does checking a flag slow down my page?

Wrapping Up

Continue Learning

Supabase Auth vs Firebase Auth: Which One Should You Choose in 2026?

Why This Comparison Is Tricky

Quick Answer

Supabase Auth vs Firebase Auth: Which Is Better for Next.js?

Supabase Auth vs Firebase Auth: Feature Comparison

Caching Feature Flag Reads with `next/cache`