Overview

Mock API is a fake REST API for testing and prototyping frontend applications, built entirely on Next.js Route Handlers. It serves six interrelated resources — Users, Posts, Comments, Albums, Photos, and Todos — with full CRUD, one-level nested relationship routes, and generic query filtering, all backed by real in-memory mutations instead of faked or static responses. The project was designed around a single idea: every resource should behave identically, so the entire API is generated from a small set of factory functions rather than hand-written per-resource logic. A companion documentation frontend (the landing page and /guide) is driven by the same resource metadata that powers the API, so the docs can never drift from what's actually served.

Key Features

• Full CRUD per resource: GET (list with filtering), GET /:id, POST, PUT /:id, PATCH /:id, and DELETE /:id for all six resources — Users, Posts, Comments, Albums, Photos, Todos.
• Real in-memory persistence: writes actually mutate a shared store seeded once from deterministic, dependency-free generators (lib/seed.ts) and cached on globalThis so data survives Next.js dev-server hot reloads, only resetting on a full process restart.
• Nested relationship routes: e.g. /api/posts/1/comments or /api/users/1/albums, implemented as thin wrappers around the same filtering logic used by top-level list endpoints (createNestedListRoute).
• Generic query filtering: any top-level field on a resource can be filtered via exact-match query params, powered by a single generic list() function in lib/db.ts.
• Factory-driven route architecture: createResourceRoutes, createResourceItemRoutes, and createNestedListRoute in lib/resource-handlers.ts generate every handler, so each file under app/api/**/route.ts is a one-line wrapper — adding a resource means adding a factory call, not writing CRUD by hand.
• Deterministic seed data: 10 users, 100 posts, 500 comments, 100 albums, 5000 photos, and 200 todos generated with plain loops and word lists (no faker), giving a consistent, known starting state.
• Self-documenting API reference: lib/resource-info.ts is the single source of truth for resource metadata (labels, counts, descriptions, nested routes), consumed by both the landing page and the /guide docs page so they never go stale.
• Dark mode: class-based Tailwind v4 dark variant, applied before first paint via a beforeInteractive script that reads localStorage and falls back to prefers-color-scheme.

Technologies Used

• Next.js 16 (App Router): Route Handlers implement the entire REST API surface.
• React 19: renders the landing page and /guide documentation frontend.
• TypeScript: end-to-end type safety, anchored by a ResourceMap/ResourceName mapping that every generic data-layer helper is parameterized against.
• Tailwind CSS v4: utility-first styling, using the class-based dark strategy (@custom-variant dark).
• lucide-react: icon set used throughout the frontend.
• ESLint (flat config, eslint-config-next) + eslint-plugin-simple-import-sort: linting and import ordering.
• Prettier: formatting for TS/TSX.

Challenges and Learnings

Building a generic data layer that stays type-safe across six differently-shaped resources required a central ResourceMap/ResourceName type (lib/types.ts) that every lib/db.ts and lib/resource-handlers.ts function is keyed on, rather than writing bespoke CRUD per resource. This is what makes the route factories possible in the first place. Because Route Handler params are asynchronous (Promise<{ id: string }>) in this Next.js version, every id-based handler had to consistently await params — a deviation from older Next.js conventions that required verifying behavior directly against the installed next package's docs rather than relying on prior assumptions about the framework. Making writes "real" instead of faked, while still resetting cleanly on a full restart, meant seeding into a store cached on globalThis. A plain module-level variable would have been wiped out by Next.js's dev-server hot reloads (which re-evaluate modules), losing in-progress test data far more often than intended. Keeping the documentation in lockstep with the live API was solved by extracting all resource metadata — labels, seed counts, descriptions, nested paths — into one file (lib/resource-info.ts) consumed by both the landing page and the guide, instead of duplicating that information as hardcoded JSX in two places.

Outcome

Mock API delivers a fully functional, six-resource REST API — complete with CRUD, nested relationship routes, and query filtering — running entirely on Next.js Route Handlers with genuine in-memory persistence. Its factory-based route architecture and single source of truth for resource metadata mean adding a new resource or route is a matter of a few lines, not hand-written boilerplate, while the self-documenting landing page and guide keep the API reference perpetually accurate. The result is a lightweight, dependency-free mock backend that's fast to spin up for frontend prototyping and testing.

This project demonstrates expertise in building high-performance frontend applications, designing developer-focused user experiences, and implementing browser-native solutions that balance functionality, security, and maintainability.