How the Smartzig Tools architecture was chosen
Why this lab runs as one Next.js host, Firebase Hosting in front of Cloud Run, localized routes, and a monorepo — without pretending every problem is a micro-frontend.
This site is a personal innovation lab, not a product catalog. The architecture had to match that: cheap to operate, honest about scope, and easy to extend when a new experiment appears.
The browser-facing surface is a single Next.js application (App Router, current major version). That decision trades the romance of “ten independent deployables” for one build pipeline, one set of quality gates, and one place where auth, i18n, and layout stay consistent. Micro-frontend boundaries still exist logically — tools live under protected routes and can grow into extractable modules later — but the default is composition inside one deployable until pain proves a split.
Hosting is Firebase Hosting rewriting to Cloud Run in southamerica-east1. That shape exists for a practical constraint: mapping a custom domain directly to Cloud Run is not always available in-region, while Firebase Hosting can proxy to the service. Users see www on the edge; the Node server runs where the project already operates. It is a boring integration on purpose: fewer moving parts than rolling a bespoke gateway.
Internationalization uses next-intl with locale segments and a small set of locales (en-US, pt-BR, es). Message files stay in key parity with a script checked in CI so drift does not silently break a language. That is cheaper than hardcoding marketing copy in components and scales when new strings appear.
The monorepo keeps the Spring API, Python services, and the Next host in one Git history. They deploy independently, but documentation, security notes, and workflow expectations live together. That reduces “tribal knowledge” spread across three README islands.
Secrets never ship in the client bundle: public keys use the NEXT_PUBLIC_ prefix; contact email uses a server route and optional Resend. Firebase Auth stays lazy-initialized so marketing pages still render if keys are missing in a throwaway build.
What this stack deliberately does not optimize for: multi-tenant SaaS billing, arbitrary plugin marketplaces, or premature extraction of packages before there are two consumers. Those are fine goals for other products; here they would be distraction tax.
If you copy ideas from this lab, copy the sequence: clarify the job of the site, pick hosting that matches your DNS and region reality, keep one main app until friction forces a split, and automate the checks that catch the mistakes you actually make (i18n keys, lint, tests, dependency audit). Architecture is the sum of those choices — not the diagram you draw before writing code.