Back to 0fee
0fee

Fusionando el sitio web de marketing en el frontend

Cómo fusionamos el sitio web de marketing separado de 0fee.dev en la app frontend, pasando de 3 servicios a 2 con enrutamiento de 3 layouts.

Juste A. Gnimavo (Thales) & Claude | March 27, 2026 2 min 0fee
EN/ FR/ ES
architecturesolidjsroutingmonoreposimplification

Para la Sesión 007, 0fee.dev tenía tres servicios separados: un backend FastAPI, un panel SolidJS y un sitio web de marketing SolidJS separado. Tres servicios significaban tres procesos de build, tres contenedores Docker, tres conjuntos de dependencias para mantener y un proxy reverso nginx enrutando entre ellos basado en la ruta URL. La Sesión 008 simplificó esto a dos servicios fusionando el sitio web de marketing en la aplicación SolidJS del panel.

Antes de la fusión: tres servicios

La arquitectura tenía problemas: los estilos compartidos divergían, los componentes se duplicaban (Button, Card, Input reimplementados en ambos), había dos pipelines de build, enrutamiento nginx complejo, complicaciones de SEO y imposibilidad de compartir estado.

La fusión: Sesión 008

La fusión se ejecutó en una sola sesión: copiar componentes de marketing, corregir rutas de importación, fusionar configuraciones de Tailwind, fusionar estilos CSS, actualizar App.tsx con enrutamiento de 3 layouts, actualizar rutas y finalmente eliminar la carpeta website/.

El cambio más significativo fue reestructurar el router para soportar tres layouts distintos: Marketing (público, con navbar/footer) en la raíz, Auth (minimal centrado) para login/registro y Dashboard (protegido, con sidebar/header) en /dashboard.

Después de la fusión: dos servicios

La configuración Docker se simplificó de tres servicios frontend a uno. No más enrutamiento basado en rutas entre dos apps SolidJS.

Los beneficios incluyeron: reducción de contenedores Docker de 4 a 3, un solo comando de build npm, componentes compartidos en lugar de duplicados, estado de login disponible en páginas de marketing y menor complejidad de despliegue.

Tres lecciones: frontends separados para marketing y panel es optimización prematura a menos que tengas equipos diferentes; el enrutamiento de 3 layouts maneja cada caso de uso; y fusiona temprano, no tarde -- la fusión en la Sesión 008 fue directa porque ambas apps usaban el mismo stack tecnológico y tenían solo unas pocas sesiones de antigüedad.

La Sesión 008 fue una sesión de limpieza -- sin funcionalidades nuevas, solo simplificación arquitectónica. Cada sesión después de esta se benefició de la simplificación.


Este artículo es parte de la serie "Cómo construimos 0fee.dev". 0fee.dev es un orquestador de pagos que cubre más de 53 proveedores en más de 200 países, construido por Juste A. GNIMAVO y Claude desde Abiyán sin ningún ingeniero humano. Sigue la serie para conocer la historia completa de construcción.

Share this article:

Responses

Write a response
0/2000
Loading responses...

Related Articles

Thales & Claude deblo

El segfault que no era nuestro: cómo lanzamos el tracking del día de lanzamiento de Déblo en la noche del despliegue — analítica condicionada por entorno, atribución nativa de las tiendas, tres bugs que el compilador no podía ver y un build sin memoria que diagnosticamos en lugar de revertir

El 1 de julio de 2026 — el día del lanzamiento — el riesgo nunca fue el texto. Era que las campañas de pago salieran a ciegas. Este es el build-log de cómo desplegamos la analítica y la atribución de instalaciones de Déblo como código en la noche del lanzamiento: etiquetas GA4, Meta y LinkedIn condicionadas por entorno que se despliegan sin riesgo antes de que existan las cuentas publicitarias; atribución enrutada por los canales nativos de las tiendas en lugar del pixel web; una auditoría adversarial que atrapó tres bugs que tanto el typechecker como el build dieron por buenos; y un despliegue en Easypanel que hizo segfault en el primer build — que demostramos que no era nuestro código antes de tocar una sola línea.

18 min Jul 1, 2026
deblolaunch-dayclaude-opus-4.8claude-code +26
Thales & Claude thales

Trece agentes, cuarenta y tres minutos: la primera sesión Workflow de Claude Fable 5, y lo que un script de orquestación determinista cambia en los builds multiagente

Un prompt, trece agentes, cuarenta y tres minutos: la primera sesión de producción con Claude Fable 5 y la herramienta Workflow de Claude Code entregó un sitio web de producción completo de siete páginas más un endpoint backend de captura de leads, en un solo commit. La bitácora: el script de orquestación determinista, el patrón de inyección de contrato entre fases, la economía por agente del fan-out paralelo, y el suspenso del límite de sesión que el diario de reanudación convirtió en un no-evento.

23 min Jun 12, 2026
claude-fable-5claude-codeworkflow-toolmulti-agent +10
Thales & Claude casp

La puerta detectó su propia deriva: un día dentro de CASP con Claude Fable 5

Le entregamos al modelo Claude más autónomo hasta la fecha las llaves de CASP — la CLI open source que mantiene honestos a los agentes de código IA frente a git — con la autoridad de rechazar nuestra propia roadmap. Rechazó cinco cosas, encontró dos bugs reales en el validador al hacerle dogfooding, los corrigió bajo una puerta de dos auditores, y dejó casp check completamente en verde sobre su propio repositorio por primera vez. CASP 0.3.0 es el resultado.

15 min Jun 10, 2026
caspzerosuiteworkflowai-cto +9