Studio
A Next.js suite of browser tools, games, and private workspaces, with Drizzle transactions and Supabase Auth, Storage, and Realtime.
- Next.js application shell
- Supabase Auth and data
- PostgreSQL and RLS
- Realtime and private Storage
The product tension
Useful tools die as unrelated demos: a new URL, a new nav, a new auth story. I needed one product a person can actually use—utilities in the browser, private files, games, and small workspaces—without turning the public portfolio into a junk drawer of every experiment.
What I built
Studio brings public utilities and account-owned workspaces into one catalog. A visitor can use a browser formatter without creating a workspace; private files and persisted workspace records follow authenticated paths.
File Manager uses private storage and signed access. Expense Tracker keeps financial records within the owning workspace. Auth owns interactive sign-in, while Studio enforces session, membership and resource authorization.
Runtime registries define the catalog, navigation and access classification. This keeps a growing collection of tools from becoming unrelated pages with inconsistent entry points.
How the system fits together
Runtime registries define the catalog and access classification. Product API routes validate requests and run Drizzle transactions against the studio schema with verified identity and RLS. File metadata stays in PostgreSQL; file objects remain in Supabase Storage. Realtime subscriptions carry updates after accepted changes.
Game actions lock the session row, validate participation and move sequence, and write the move, session state, and result together. These commands now run in TypeScript transactions rather than custom database RPCs. The Drizzle migration article explains that boundary.
The calls that shaped the build
- 01
Keep the catalog executable
Registries drive the available tools and their navigation and access rules, so the catalog stays tied to implemented routes.
- 02
Match persistence to the operation
Browser-only utilities do not need an account-owned database record. Persisted workspaces, signed file access, and game actions use authenticated product APIs.
- 03
Preserve atomic game changes
A session lock and transaction protect validation and writes together. Realtime is a delivery mechanism, not authority to accept a move.
Trust boundaries
Protected operations use verified sessions, live product access, and resource policies. Signed file access follows ownership checks. Direct browser mutations are restricted where they could bypass transaction-owned validation. Supabase Realtime does not replace authorization.
What I chose—and accepted
A shared suite needs regression checks across navigation, access, and persisted workflows. File objects and metadata also span two systems: a database transaction cannot atomically commit a Storage upload, so the file API retains compensation behavior.
Why the work matters
The deployed catalog combines public utilities with authenticated file and workspace operations. The migration kept existing API contracts while moving application queries and business commands into product-owned Drizzle transactions.
What I would improve next
Add operational measurements around signed file access and game-action latency, including failure and concurrency cases, before making performance claims about those workflows.