glaubermag.dev.br — Proyecto Cero

Problema

Necesitaba una superficie de hiring senior y marca personal técnica: un sitio que demostrara ingeniería real — multilingüe, accesible, indexable y operable — sin landing genérica ni métricas de negocio inventadas.

Solución e impacto

SPA en React 19 + Vite con i18next (pt-BR, en-US, es-ES, fr-FR), motion según preferencia del usuario, PWA, prerender con Puppeteer para HTML estático en rutas críticas, y deploy containerizado (Docker + nginx) en Coolify. El impacto es el artefacto en sí: código abierto, CI en verde y decisiones documentadas en este case.

Arquitectura y trade-offs

Trade-off central: SPA + prerender en lugar de Next.js — menos superficie de framework y hosting simple vía nginx estático, a costa de orquestar hydrateRoot y rutas prerenderizadas en el build. i18n de URL única (cambio de idioma en el cliente) simplifica canónicos y cookies de preferencia, pero exige disciplina de parity de locales y contenido hidratado. La PWA con service worker queda en un flujo de update; el objetivo es resiliencia offline ligera, no app store.

Operación y observabilidad

GET /health com JSON `{"status":"ok"}`; monitoramento externo (Cloudflare Health Checks ou Better Stack). Lighthouse script no repositório para auditar regressões de performance. Plausible analytics opt-in — sem cookies de rastreamento por padrão.

Rendimiento

Foco en Core Web Vitals (sobre todo LCP e INP), sin scores fabricados: imágenes WebP con srcset donde aporta, secciones de la home bajo demanda, code splitting por ruta (lazy + Suspense), hydrateRoot tras el HTML prerenderizado y tooling Lighthouse en el repo para auditar regresiones. El motion respeta prefers-reduced-motion.

Calidad

Vitest en unitarias, Playwright en smoke e2e y CI con lint/test/e2e/build. Accesibilidad pragmática: contraste del tema, skip-link, focus trap en overlays y copy para lectores de pantalla en estados de carga. SEO/AEO con JSON-LD, FAQ, llms.txt y meta canónica — alineado con lo que el sitio publica de verdad.

Qué haría diferente

Eu documentaria mais cedo as decisões como ADRs públicos (agora em /adr/) e manteria o foco em trade-offs documentados nos cases. O desenho SPA+prerender continua certo para este perfil de site estático multilíngue.

Decisiones documentadas (ADR)

• ADR 002: SPA + prerender vs Next.js

  nginx estático e controle do build; custo de orquestrar prerender e hydrateRoot.

Stack

• React 19
• Vite
• i18next
• Framer Motion
• Puppeteer
• Docker
• nginx
• GitHub Actions
• Vitest
• Playwright
• PWA