Hace ya unas semanas te contaba que en FácilSEO la API no ejecuta todo, sino que coordina.
También hace semanas que no te enviaba una entrega puramente técnica, y la verdad es que ya tenía ganas de explicar asuntos más técnicos, sobre todo si tiene que ver con arquitectura.
Pero antes de ir a los detalles de arquitectura, quiero contarte cómo me di de bruces con la realidad hace un tiempo.
Imagina la escena: estás construyendo tu producto. Tienes tu backend montado, tus controladores listos y las pruebas en local te muestran que todo está ok.
Todo parece ir sobre ruedas.
Entonces, decides probar el analizador de FácilSEO con una web real de un cliente.
Introduces la URL, le das a analizar, tu backend hace su magia y… el reporte vuelve casi vacío.
Sí, la funcionalidad principal de tu proyecto no funciona. Te encuentras con un desastre que tiene un total de cero palabras, cero enlaces y una estructura rota.
Miras el código y revisas los logs. Lanzas un par de maldiciones pensando que te has cargado algo en el último commit.
Pero no, tu código está bien. Abres el navegador, entras a esa misma web y la ves perfectamente: llena de texto, imágenes y diseño.
¿Qué estaba pasando?
Pues que me acababa de chocar de frente contra el muro invisible de las webs modernas.
Ese día me di cuenta de que resolver ese problema no iba de añadir un simple parche o cambiar una librería. Iba a requerir replantear cómo estaba diseñando el sistema.
Porque hay problemas (de los feos, de los que te hacen rascarte la cabeza) que simplemente no aparecen hasta que sacas tu producto a la calle.
Hoy quiero contarte cómo solucioné ese choque de trenes, y por qué me llevó a tomar una de las decisiones más importantes del proyecto.
El problema de las webs modernas
Cuando empecé a montar el sistema de análisis SEO, me topé con este escenario bastante incómodo.
Resulta que muchas webs actuales no devuelven todo su contenido en el HTML inicial. En su lugar, tiran de JavaScript para cargar datos, montar componentes y renderizar la página directamente en el navegador.
Para un usuario normal esto es transparente, pero para una herramienta SEO es un dolor de cabeza.
Si haces una petición HTTP tradicional, muchas veces recibes una página casi vacía: sin estructura real, sin información fiable y, lo peor de todo, llevándote a conclusiones equivocadas.
Separar sin complicarse (el Renderer)
Para solucionar esto, en FácilSEO creé un servicio separado que se encarga exclusivamente de renderizar las páginas usando Playwright.
Básicamente, abre la web como lo haría un navegador real, ejecuta el JavaScript, espera a que cargue el contenido y devuelve el HTML final.
Esto hace que el análisis sea muchísimo más fiable.
Pero más allá de la herramienta en sí, lo realmente importante es la decisión arquitectónica de separarlo.
Este renderer vive fuera del backend principal (no está dentro de Laravel), y no es casualidad.
Es un proceso pesado, consume recursos, tarda más y puede fallar por motivos completamente distintos.
Si una web tarda mucho en cargar o el renderer cae, la API principal debe seguir funcionando sin inmutarse y sin bloquear otras peticiones.
La lección aquí es clave: no todo lo que tu backend necesita hacer tiene que vivir dentro del mismo proceso.
El monolito modular
Ojo, esto no significa que tengas que volverte loco montando microservicios.
FácilSEO no está construido así; sigue siendo un backend monolítico en Laravel, pero de forma modular.
El código está organizado por áreas con sentido: SEO, Proyectos, Billing, Posicionamiento.
No se trata de hacer una arquitectura bonita por postureo o por modas, sino de evitar que toda la lógica acabe embutida en controladores gigantescos.
Un controlador no debería saberlo todo: solo recibe la petición, valida y delega en servicios o módulos donde realmente vive la lógica.
Un backend que trabaja solo y sabe cómo fallar
Otra cosa que suele pasar desapercibida es que un backend no solo responde a los usuarios; también trabaja solo.
Envía informes, sincroniza datos con Search Console, revisa suscripciones y reintenta procesos fallidos.
Todo esto lo gestiona el scheduler, convirtiendo al backend en un sistema activo que no depende únicamente de que alguien haga clic.
Y hablando de fallos… cuando haces una demo, todo es un caso feliz o de éxito.
Pero en la vida real, Stripe puede fallar, una web puede no responder o un webhook puede perderse por el camino.
Por eso, el sistema no está pensado solo para ejecutar acciones, sino para saber recuperarse.
Hay reintentos, timeouts, gestión de estados intermedios y logs. Y es que tu sistema nunca debe asumir que todo irá bien.
Aquí radica la diferencia entre programar y construir producto:
-
Programar es conseguir que algo funcione.
-
Construir producto es conseguir que siga funcionando cuando las cosas van mal, entender qué ha pasado y que un error aislado no arrastre todo el sistema.
La idea importante si estás empezando
FácilSEO podría haberse construido mucho más rápido metiendo todo dentro de la petición, con una sola cola y controladores enormes. Y probablemente habría funcionado… en local. Pero las malas arquitecturas siempre dan la cara cuando llega el uso real.
No necesitas usar Docker, Redis o Playwright desde el día uno.
Lo que sí necesitas entender cómo separar responsabilidades: qué debe ser rápido, qué puede ir en segundo plano, qué puede fallar y qué no debe bloquear al usuario.
En FácilSEO, la regla mental es sencilla: la API coordina, los workers ejecutan, el scheduler automatiza y el renderer se pelea con las webs modernas.
Cada pieza tiene su responsabilidad.
No es perfecto, pero es mantenible.
Al final, diseñar un sistema real se resume en aceptar el caos. Asumir que las cosas externas van a fallar y prepararte para que, cuando lo hagan, el impacto sea mínimo. No se trata de usar la tecnología más puntera, sino de tomar decisiones prácticas que te dejen dormir tranquilo por las noches.
Seguiremos usando FácilSEO (y mis propios tropiezos en producción) como excusa para seguir aprendiendo. Todavía queda mucho barro en el que meternos.
Nos leemos en la próxima,
Julián
P.D.: Durante el verano, las entregas de CERO a SENIOR pasarán a ser cada dos semanas, increíblemente, para ser verano, estoy hasta arriba de trabajo y bueno, así también todos podemos desconectar y descansar un poco.
Publicado originalmente en CERO a SENIOR.