The Tech Stack Behind This Site (And Why Each Piece Is Here)

People occasionally ask what runs this site. The answer is deliberately boring: a Next.js frontend, an Express API, a MySQL database, and PM2 for process management. No Kubernetes, no serverless functions, no microservices. One server, three processes, done.

Frontend: Next.js 14 (App Router)

The public-facing site is a Next.js application. Why Next? Because it gives us static generation for game pages (fast, cacheable, good for SEO) and server-side rendering for dynamic pages (search results, category listings) without maintaining two separate codebases.

Game pages use generateStaticParams — all seventeen game detail pages and seventeen guide pages are pre-rendered at build time. When you visit /games/wizardsort, you get a static HTML file served from disk. No database query, no API call. That is why the page loads in under 100ms.

Backend: Express + MySQL

The API is a straightforward Express application with a MySQL database. It handles game listings, comments, contact messages, and admin operations. No ORM — raw SQL queries with parameterized inputs. For a schema this simple (six tables), an ORM adds abstraction without saving time.

The database has games, categories, comments, contact_messages, settings, and admins. Total data size is under 2MB. MySQL is overkill for this volume, but it is reliable, well-understood, and already installed on the server.

Process management: PM2

Three Node.js processes run on the server: the API (port 3001), the Next.js frontend (port 3000), and the admin panel (served as static files by the API at /admin). PM2 keeps them alive, restarts on crash, and logs stdout/stderr to files.

Deployment

A single VPS running Ubuntu. Code is pulled from a private Git repository, dependencies installed, Next.js built, and PM2 reloaded. Total deploy time: about 90 seconds. No CI/CD pipeline, no container orchestration. For a site this size, that complexity is not justified.

What we do NOT use

• No CDN (the server is in the right region for our traffic)
• No Redis (the comment rate limiter is an in-memory Map, sufficient for one process)
• No Elasticsearch (game search is a LIKE query on title and tags, fast enough for 17 rows)
• No client-side analytics (no GA4 yet — the setting field exists but is empty)

Why boring wins

Every technology in this stack has been stable for 3+ years. None of them will break with a security update next Tuesday. The total attack surface is small, the debugging tools are mature, and any Node.js developer can read the codebase and understand it in an hour. That is worth more than any performance gain a fancier stack might offer.