How This Portfolio Is Built: Next.js 16, Browser-Language Detection and a Demo Lab
The site you are reading is a small project of its own. Here is how it picks your language, keeps its service worker honest, and why projects lead with case studies.
The stack
- Next.js 16 (App Router) with React 19 and TypeScript.
- Tailwind CSS, with light and dark themes.
- Deployed on Vercel and installable as a PWA through a service worker.
Showing the right language first
Visitors come from Indonesia and from abroad, so the site picks its language on the server, before the page is sent. The order is: the visitor's own choice from the language toggle (stored in a cookie), then the browser's Accept-Language header, and English for everyone else. Because the decision happens on the server, there is no flash of the wrong language, and search engines index the English version.
Keeping the service worker from serving stale pages
The first version cached the home page with a stale-while-revalidate strategy, so returning visitors could keep seeing an old version, or the wrong language. Page navigations now go network-first and fall back to the cache only when the visitor is offline. Static assets still come from the cache for speed.
The Interactive Lab
The lab shows how I think about systems: an architecture viewer, and a SQL sandbox that compares a database query with an edge cache. The sandbox runs against an isolated in-memory dataset, and its timings are simulated to illustrate the difference, not to benchmark real hardware.
Case studies over feature lists
Key projects open with a case study (the challenge, the architecture decisions and the measured outcome), because that tells a reader far more about how an engineer works than a list of features does.