Featured case study
Keeping ecommerce business rules on the server
I built this project as a full-stack clothing-store template, with the backend work centered on checkout consistency, variant inventory, protected admin operations, server-side catalog queries, and automated verification of critical flows.
Project walkthrough
These local demo videos show the project using demo data only. The desktop view is the main walkthrough, while the phone view shows how the same store experience adapts to smaller screens.
A focused gallery showing the main storefront and admin screens. The images use demo content only and are placed after the videos so the page first communicates the experience, then gives recruiters a quick scan of the key flows.
A clothing storefront needs more than product pages. Checkout has to use current server data, stock belongs to specific size/color choices, historical orders need stable purchase details, and admin actions must follow rules that cannot be bypassed from the browser.
The order endpoint does not accept product prices or delivery prices from the browser. It reloads the authenticated customer and cart, validates the selected delivery area, recomputes effective prices, checks active variants, and decrements stock inside one Prisma transaction.
Each order stores product, price, variant, customer, and delivery snapshots. A per-user idempotency key prevents the same checkout request from creating a second order, while failed stock reservations stop order creation and leave the cart intact.
Size and color are stored in ProductVariant records rather than frontend-only labels. Normalized size/color keys form a database uniqueness constraint, and each variant owns its stock and active state.
Checkout requires a selected active variant and conditionally decrements it only when enough stock remains. Cancelling a previously reserved order restores that stock; admin status changes are restricted to explicit allowed transitions.
The products API validates query shape and limits, then performs search, category filtering, ordering, and capped pagination in Prisma. The response derives availability from active variant stock instead of exposing an unbounded catalog for browser-side filtering.
Authentication uses Better Auth with Prisma-backed sessions. Admin API mutations require the ADMIN role, use same-origin checks, and can apply Redis-backed rate limits when Upstash is configured; the limiter intentionally fails open if Redis is unavailable.
Vitest/API tests cover order validation, stock reservation failures, client-supplied delivery-price rejection, rate-limit behavior, variant validation, and admin order transitions. Playwright also exercises a real customer order flow and checks the resulting price snapshot and stock change.
GitHub Actions runs type checking, linting, unit tests, a production build, and the repository license audit on pull requests and pushes to main. The Playwright suite exists separately and is not claimed here as part of that CI job.
The result is a backend-oriented full-stack project with concrete ecommerce invariants rather than a production-store claim. Payment processing is intentionally out of scope—the schema supports cash on delivery only—and the hosted demo should be treated as a portfolio environment rather than proof of production availability or scale.