Arquitectura antes que código: por qué estoy construyendo un laboratorio multi-stack
Elegir una tecnología por tendencia suele salir caro. Especialmente cuando el objetivo no es crear un prototipo rápido, sino construir una plataforma mantenible, escalable y sostenible a largo plazo.
Por eso, antes de desarrollar el SaaS principal en el que trabajaré próximamente, he decidido dedicar tiempo a algo menos vistoso, pero mucho más importante: un laboratorio de decisiones arquitectónicas.
El repositorio alxarafe/saas: un banco de pruebas, no un producto
El repositorio alxarafe/saas no nace como producto final. Su objetivo es servir como entorno de evaluación técnica para comparar distintos stacks backend bajo exactamente las mismas condiciones.
Actualmente implementa una API equivalente en varios lenguajes y runtimes:
- PHP
- Python
- Node.js
- Kotlin
- Go
Todos comparten:
- el mismo contrato HTTP
- la misma estructura de endpoints
- la misma persistencia sobre PostgreSQL
- y la misma batería de tests automatizados mediante Bruno
La idea es sencilla: reducir al máximo las diferencias externas para poder evaluar lo importante.
No me interesa únicamente el rendimiento bruto. También quiero medir aspectos que muchas veces se descubren demasiado tarde:
- complejidad accidental
- cantidad de boilerplate
- ergonomía del lenguaje
- claridad arquitectónica
- facilidad de testeo
- experiencia de desarrollo (DX)
- y coste de mantenimiento futuro
Comparar tecnologías en igualdad de condiciones
Uno de los objetivos principales del laboratorio es evitar comparativas injustas.
Por ejemplo, no tiene sentido comparar:
- un framework enterprise completo en un lenguaje
- contra un servidor HTTP mínimo en otro
Por eso todas las implementaciones intentan mantener el mismo nivel de responsabilidad y complejidad funcional.
El resultado es un entorno reproducible que permite ejecutar exactamente los mismos tests sobre todos los stacks y observar diferencias reales de comportamiento, latencia y simplicidad.
El WMS y la Arquitectura Hexagonal
En paralelo, sigo avanzando en otro proyecto importante: un WMS (Warehouse Management System).
Ese proyecto me está sirviendo para profundizar en:
- Arquitectura Hexagonal
- separación de responsabilidades
- puertos y adaptadores
- testing desacoplado
- y diseño orientado al dominio
Más que centrarme en frameworks concretos, me interesa construir sistemas donde la lógica de negocio no dependa de detalles de infraestructura.
Ingeniería antes que herramientas
La tecnología cambia constantemente. Lo que permanece es la capacidad de tomar buenas decisiones de arquitectura.
Por eso este laboratorio tiene más valor para mí que empezar directamente el producto final. Porque una decisión tecnológica equivocada puede acompañar un proyecto durante años.
Hoy existen herramientas extraordinarias, incluida la IA, que aceleran muchísimo el desarrollo. Pero la velocidad no sustituye al criterio técnico. Las herramientas ayudan a construir más rápido; la arquitectura es lo que determina si merece la pena mantener lo construido dentro de cinco años.
Esta fase no trata de “escribir código cuanto antes”. Trata de entender qué stack ofrece el mejor equilibrio entre simplicidad, rendimiento, mantenibilidad y capacidad de evolución para el tipo de software que quiero desarrollar.