Hace un par de entregas de la Newsletter hice la presentación en comunidad de mi último proyecto, FácilSEO.com.
En esta entrega te conté de dónde había salido el proyecto, por qué lo había recuperado después de tenerlo meses aparcado y qué problema intentaba resolver: dejar de hacer análisis SEO y reportes a mano cada vez que entraba un cliente nuevo.
En esa edición te enseñé la parte visible del producto.
La parte que cualquier usuario puede entender rápido: añadir proyectos, analizar URLs, ver recomendaciones, conectar Search Console, generar informes y automatizar reportes.
Pero también te dije que me estaba dejando fuera toda la parte técnica.
Y precisamente de eso va esta entrega.
FácilSEO se trata una plataforma destinada a ayudar a los análisis SEO y de rendimiento web, con el objetivo de facilitarte los análisis, la búsqueda de mejoras en tu web, la elaboración de informes y automatizaciones para ti o tus clientes.
Puedes usar el código CEROASENIOR15 en el momento del registro para tener 15 días GRATIS del plan pro (no hace falta meter tarjeta alguna ni se te cobrará nada al acabar el periodo de prueba)
Hoy quiero enseñarte cómo está montado el backend de FácilSEO y no para hacer una lista de tecnologías ni para venderte que usar Docker o colas te convierte en mejor desarrollador, porque esa sería una conclusión bastante pobre.
La idea es otra: un backend no se complica cuando tiene muchas rutas, se complica cuando no sabes qué responsabilidad tiene cada parte del sistema.
Y FácilSEO, aunque sea un MVP, no podía construirse como una simple API que recibe una URL, analiza una web y devuelve un JSON.
Sobre el papel suena sencillo: el usuario mete una URL, el backend la analiza y el frontend muestra el resultado.
Pero cuando te pones a construirlo de verdad, te das cuenta de que analizar una web no es una operación normal.
No es como hacer login. No es como guardar un proyecto. No es como actualizar un perfil de usuario.
Analizar una web implica depender de cosas que no controlas: webs lentas, errores inesperados, contenido que solo aparece tras ejecutar JavaScript, APIs externas que tardan o directamente fallan.
Y si metes todo eso dentro de una petición HTTP normal, estás comprando papeletas para tener problemas.
El backend no podía ser solo una API
Cuando empiezas en backend es normal imaginarlo así: el frontend hace una petición, Laravel la recibe, consulta la base de datos y devuelve una respuesta.
Para muchas partes de FácilSEO esto funciona perfectamente como para crear proyectos, consultar informes o actualizar configuraciones.
Todo eso encaja bien en ese modelo, pero el problema aparece con las tareas pesadas.
Un análisis SEO no debería competir con un login, un informe grande no debería afectar a la navegación del panel, un envío de email no debería bloquear una acción importante del usuario y una sincronización externa no debería ralentizar cosas que no tienen nada que ver.
Aquí apareció una de las primeras decisiones importantes: separar lo urgente de lo pesado.
La API tiene que responder rápido ya que su trabajo no es hacerlo todo, sino coordinar:
Recibe la petición, valida, guarda el estado inicial y delega el trabajo pesado.
Y esa otra parte son los workers.
Cuando un usuario lanza un análisis, el backend no lo ejecuta en ese momento, sino que registra que hay un análisis pendiente y manda un trabajo a una cola.
Después, un proceso en segundo plano recoge ese trabajo y lo ejecuta.
Cambio de mentalidad
Este cambio parece técnico, pero en realidad es de mentalidad.
Dejas de pensar en el backend como una máquina que responde a todo al instante.
Y empiezas a verlo como un sistema donde cada pieza tiene un papel claro.
La API coordina, los workers ejecutan, el usuario consulta el estado y el sistema puede seguir funcionando aunque haya tareas lentas en marcha.
Esto, cuando lo interiorizas, cambia completamente cómo diseñas backend.
FácilSEO está montado con varios servicios en Docker, pero no porque Docker sea arquitectura por sí mismo ya que docker solo te da contenedores.
La arquitectura aparece cuando decides qué responsabilidad tiene cada uno.
Aquí hay un backend principal en Laravel, una base de datos que guarda el estado persistente y luego Redis que ayuda con caché y datos temporales.
Hasta aquí, todo bastante estándar.
Lo interesante llega cuando miras las colas ya que no hay una única cola donde se mete todo, sino que hay colas separadas según el tipo de trabajo.
Análisis pesados, tareas generales, emails o s incronizaciones.
Esto, aunque parezca un detalle interno, es clave porque si metes todo en una única cola, cualquier pico de carga puede afectar a todo lo demás.
Unos cuantos análisis pesados pueden retrasar emails o una sincronización lenta puede bloquear otras tareas.
Separar colas permite aislar la carga.
Y eso no se nota en local, pero cuando hay usuarios reales ves realmente la optimización.
Una idea importante si estás empezando
Si eres junior, aquí es fácil sacar una mala conclusión.
Pensar que necesitas Docker, Redis, colas y toda esta infraestructura desde el primer día.
Y no, esa no es la lección.
La lección es otra: antes de pensar en herramientas, piensa en responsabilidades.
Cuando estés diseñando una aplicación, hazte estas preguntas:
-
Qué debe responder rápido.
-
Qué puede ejecutarse en segundo plano.
-
Qué puede fallar.
-
Qué no debería bloquear al usuario.
Si entiendes eso, la arquitectura empieza a tener sentido y las herramientas dejan de ser postureo técnico para convertirse en soluciones a problemas reales.
Al final, todo esto no va de usar más cosas, sino que va de entender mejor el problema que estás resolviendo.
Y FácilSEO me está sirviendo justo para eso: para tomar decisiones reales, con problemas reales, y ver qué pasa cuando el sistema empieza a tener vida más allá de localhost.
En las próximas entregas vamos a seguir usando FácilSEO como excusa para aprender backend de verdad.
Iremos bajando más al detalle: cómo tratar webs modernas que dependen de JavaScript, cómo está montado el renderer y cómo se diseña un sistema que sigue siendo razonable cuando empiezan a fallar cosas.
Nos leemos en la próxima,
Julián
Publicado originalmente en CERO a SENIOR.