GavL — Next Auctions
Built Sep–Oct 2025Realtime Bidding · Stripe Settlement · CRON Lifecycle
Real-time bid flow
DB triggers and Supabase Realtime broadcast (Next Auctions README).
Overview
Auction platforms need live multi-user bidding, automatic closure at deadline, and payment settlement without exposing privileged database access to the browser.
GavL uses Supabase Realtime for live bids, a CRON-triggered close-auctions Edge Function, and Stripe webhooks with a server-only service role to update payment state safely under RLS.
Technical Architecture
GavL is a learning build focused on real-time full-stack flows. It follows a lightweight domain-driven layout: domains hold types and Zod schemas; ports are repository interfaces; services own workflows; Supabase repositories sit behind those ports; instances wire services to infrastructure. Supabase Realtime broadcasts notifications for new bids, auction wins, and payments. A Supabase CRON job triggers the close-auctions Edge Function so auctions close at endAt. Stripe Checkout plus a verified webhook updates paidAt through a service-role client where RLS must be bypassed safely on the server only. The UI is multilingual (French, English, German via Lingui), responsive, and uses URL-driven filters, sorting, and pagination (nuqs) with Suspense and skeleton loaders.
Key features
- Real-Time Bidding Engine: Live multi-user bidding with instant updates using Supabase Realtime.
- End-to-End Auction Lifecycle: Creation, editing, bidding, automatic closure (CRON + Edge Functions), winner notifications, and payment completion.
- Stripe Payments: Secure checkout flow with webhook handling for server-side payment status updates.
- Notification System: Instant alerts for bids, auction wins, and payments across all connected clients.
- Server-Side Table Filtering: URL-driven filters, sorting, and pagination using nuqs for consistent server-client synchronization.
- Multilingual UI: Fully localized interface in French, English, and German via Lingui with locale-aware routes.
- Domain-driven architecture: Domains, ports, repositories, and services — Jest-tested workflows with URL-driven filters via nuqs.
Technologies Used
- Frontend: Next.js, React, TypeScript
- Backend & Database: Supabase (Realtime, Edge Functions, CRON, RLS)
- Payments: Stripe Checkout & Webhooks
- UI & Form Handling: Shadcn/UI, React Hook Form, Zod
- Filtering & Data Display: Nuqs, TanStack Table, Recharts (payments dashboards)
- Internationalization: Lingui — French / English / German with locale-aware routes.
- File Uploads: Uppy
- Testing: Jest
- Architecture: Domain-driven structure with domains, ports, repositories, services, and wired instances
Challenges and Learnings
Designing a multi-user bidding flow that stayed understandable while Supabase Realtime, CRON + Edge Functions, and Stripe webhooks all touched related rows. RLS had to protect normal clients while the webhook used a service-role client safely — no privileged paths exposed to the browser. Keeping notifications, auction state, and payment flags aligned across triggers required clear repository boundaries and idempotent handlers where possible.
Outcome
GavL demonstrates an end-to-end auction flow at next-auctions.vercel.app: live bidding, automated closure, Stripe settlement, realtime notifications, multilingual UI (French, English, German), dashboards with charts, and a domain-shaped codebase with Jest coverage. It complements the Web3 case studies — evidence of full-stack work on payments, realtime sync, i18n, and testing alongside on-chain experiments.
Key Metrics
- Live demo: next-auctions.vercel.app
- i18n: French / English / German (Lingui)
- Architecture: Domain-driven design — domains, ports, repositories, services; URL-driven filters via nuqs; Jest coverage
- Automation: Supabase CRON → Edge Function auction closure; Stripe webhooks → service-role client for RLS-safe payment updates
Transferable patterns: Payments + webhooks, realtime fan-out, automated lifecycle jobs, and disciplined data boundaries.
Known limitations
- Testing depth — Jest covers domain logic; there is no end-to-end browser harness in this repo yet.
- Service role trust — Stripe webhook updates intentionally bypass RLS with a server-only key; misuse would be catastrophic, so the surface stays tiny and audited.
- CRON granularity — Auction closure depends on how often the scheduled job runs; near-miss timing is bounded by that cadence.
Roadmap
- Cypress E2E — Cover login, bidding, closure, and Stripe test-mode flows in a browser.
- Admin dashboards — Richer operational views for support-style tasks.