Cuando comenzamos a construir el frontend de 0fee.dev, elegimos SolidJS sobre React. La decisión fue deliberada: SolidJS ofrece reactividad verdadera sin DOM virtual, resultando en bundles más pequeños y actualizaciones más rápidas -- crítico para un panel que muestra datos de transacciones en tiempo real, gestiona claves API y maneja configuración de pagos.
La elección entre SolidJS y React se redujo a tres factores: tamaño de bundle (~7KB vs ~45KB), modelo de reactividad (señales de grano fino vs diffing de DOM virtual) y ecosistema. Para un panel de pagos donde cada kilobyte importa, el tamaño de 7KB de SolidJS fue convincente.
Arquitectura de stores
Construimos tres stores principales: auth (gestión de JWT con persistencia en localStorage), apps (CRUD de aplicaciones + claves API + proveedores) y transacciones (listado con filtros y paginación).
El sistema de 3 layouts
La Sesión 008 introdujo el sistema de enrutamiento con 3 layouts: Marketing (navbar + footer, para visitantes), Auth (minimal centrado, para login/registro) y Dashboard (sidebar + header, para desarrolladores autenticados). El componente ProtectedRoute envuelve el layout del panel, verificando autenticación y redirigiendo a /login si el usuario no está autenticado.
De datos mock a API real
La Sesión 002 creó el panel con datos codificados. La Sesión 006 lo conectó a APIs reales, lo que requirió primero corregir la autenticación -- el middleware solo soportaba claves API, no tokens de sesión. Después de agregar verificación de tokens de sesión al middleware, todas las páginas del panel pudieron obtener datos reales.
El panel creció de 5 páginas a 19, de datos mock a integración con API real, y de solo tema claro a soporte completo de modo oscuro.
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.