Skip to content

Arquitectura general y organizacion tecnica

El problema que hemos querido resolver

En muchos equipos SEO el flujo de trabajo tecnico queda fragmentado: se analiza un sitio en una herramienta, los datos de rendimiento viven en otra, el seguimiento de cliente en otra y los informes se acaban reconstruyendo a mano. Nosotros hemos construido SEO Growth Engine precisamente para resolver esa fragmentacion.

Nuestro objetivo tecnico ha sido unificar analisis, accesos, reporting e historico en una misma aplicacion.

A quien va dirigido

  • Agencias SEO o de marketing digital con varios clientes.
  • Consultores independientes que necesitan orden operativo.
  • Equipos de marketing con varios sitios y distintos perfiles de acceso.

Alcance funcional implementado

Con SEO Growth Engine hemos organizado en el mismo sistema:

  • gestion de sitios;
  • usuarios y permisos por cliente o por equipo;
  • ejecuciones de analisis tecnico;
  • historico de runs y reintentos;
  • artefactos e informes HTML;
  • una capa de visibilidad IA para prompts y observaciones;
  • una estructura preparada para anadir nuevas funcionalidades.

Los bloques de la arquitectura

Nuestra arquitectura se apoya en seis piezas que trabajan juntas:

  1. Frontend Vue 3 + TypeScript Lo usamos para construir una zona SPA en login, dashboard y detalle de run, con rutas protegidas, estado global y componentes reutilizables.

  2. Django como nucleo de negocio Es la capa que sostiene autenticacion, formularios, vistas web, API JSON, permisos, modelos y reglas de negocio.

  3. ORM + base de datos El dominio de la aplicacion se persiste en modelos como Site, SiteAccess, AnalysisRun y AIVisibilityRun.

  4. Motor SEO y servicios La logica de analisis vive en engine/, mientras que dashboard/tasks/services.py coordina ejecucion, progreso, cancelacion, logs y resultados.

  5. Redis + RQ Nos permite desacoplar procesos largos para que la aplicacion no bloquee la interfaz cuando se lanza un analisis.

  6. Despliegue y publicacion En desarrollo hemos validado el stack con Docker. En la VPS se anade NGINX como proxy de entrada delante de la aplicacion.

Flujo funcional end to end

Nosotros explicamos el recorrido principal de la aplicacion asi:

Usuario -> interfaz Vue o Django -> API / vistas Django -> ORM -> PostgreSQL

Cuando el usuario lanza un proceso pesado, entra nuestra parte desacoplada:

Usuario -> formulario o accion web -> AnalysisRun / AIVisibilityRun -> Redis + RQ -> worker -> artefactos / reportes / dashboard

Justificacion de la arquitectura

Hemos elegido esta arquitectura porque separa responsabilidades y encaja con los procesos que necesitaba la aplicacion.

  • Vue nos permite organizar la zona interactiva con rutas, estado y componentes.
  • Django nos da rapidez, robustez y una capa muy clara para negocio, formularios y permisos.
  • ORM nos permite modelar el dominio con coherencia y trazabilidad.
  • Redis + RQ resuelve una necesidad real: que las ejecuciones largas no congelen la web.
  • Docker hace reproducible el entorno local.
  • NGINX en VPS separa la entrada HTTP de la aplicacion servida por Gunicorn.

Evidencias tecnicas que lo demuestran

  • frontend/src/router/index.ts: rutas del cliente y proteccion de acceso.
  • frontend/src/stores/session.ts: estado global de usuario, sitios, runs y detalle.
  • dashboard/models.py: dominio persistente del sistema.
  • dashboard/web/views.py: flujos de negocio, lanzamientos, cancelaciones y reporting.
  • dashboard/api/views.py: capa JSON para bootstrap, sesion, sitios, runs y dashboard.
  • dashboard/tasks/services.py: coordinacion del trabajo en segundo plano.
  • engine/report_data.py: construccion de datos para informe.
  • engine/ai_visibility.py: ejecucion de visibilidad IA.
  • docker-compose.yml: stack local con web, worker, db y redis.
  • deploy/nginx/seo-growth-engine.conf: configuracion de proxy para la publicacion.

Sintesis de la arquitectura

La arquitectura queda organizada por capas: interfaz, backend, persistencia, motor de analisis, cola de trabajos y despliegue. Cada bloque responde a una necesidad concreta del proyecto y se puede defender con archivos reales del repositorio.