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 Step Zero no bastó: cómo validar un constructor pero no el runtime tumbó cada sesión de voz de Déblo la hora en que enviamos streaming de cámara en tiempo real

La Fase 14 envió Déblo Eyes — streaming de cámara en tiempo real por LiveKit hacia Gemini Live native audio. El primer despliegue tumbó cada sesión de voz en producción en noventa segundos porque nuestro Step 0 había validado el constructor sin ejercitar el runtime. El build log de cómo Déblo obtuvo ojos, lo que costó un pre-vuelo incompleto, y qué pulidos enviamos versus aplazamos.

33 min May 20, 2026
debloclaude-opus-4.7claude-codegemini-live +25
Thales & Claude deblo

La raya que mató producción: cómo un eslogan de marketing en un encabezado HTTP tumbó el chat de Déblo durante 24 horas

Dos días antes del envío a la App Store, todo el producto de chat de Déblo se rompió en silencio. Sin spinner, sin toast, sin error en la UI — solo aire muerto. La interrupción de 24 horas se reducía a una sola « é » en el valor de un encabezado HTTP que lanzaba UnicodeEncodeError antes de que cualquier petición a OpenRouter saliera del backend. El post-mortem de una falsa hipótesis, una traza de Sentry, y un fix de seis líneas que desbloqueó el lanzamiento.

29 min May 19, 2026
debloclaude-opus-4.7claude-codeincident +19
Thales & Claude deblo

Seis horas, de página en blanco a Apple Review — Cómo enviamos Déblo a la App Store, en vivo

Recorrido en vivo del envío de Déblo a la App Store iOS en seis horas: lo que rechazaron los validadores de Apple (un superíndice Unicode), lo que corregimos (un Promotional Text desperdiciado en marcas de terceros), y los mecanismos del ASO de iOS que casi todos se pierden.

30 min May 13, 2026
debloclaude-opus-4.7claude-codeapp-store +16