Arquitectura general

Piezas de VANTS y cómo se conectan: Worker de Cloudflare, Neon, Auth0, Neon Functions, bot y agente, recorrido de una petición, despliegues y decisiones clave.

VANTS funciona sobre un Worker de Cloudflare que sirve la web y la API, una base de datos Postgres en Neon y Auth0 para la identidad. Alrededor hay Neon Functions, un bot de Discord, un agente que vigila la plataforma y un bus de eventos que conecta los proyectos. Esta página describe cada pieza, el recorrido de una petición, los despliegues y las decisiones que condicionan el código.

Componentes

Capa	Tecnología	Dónde está
Frontend	HTML, CSS y JavaScript sin framework	vants-server/public/
Backend	Worker de Cloudflare vants: seguridad, rutas, API pública JSON, eventos de Discord e inscripciones	vants-server/worker.js
Datos	Neon Postgres, a través de la Data API y de Neon Functions	neon-functions/. El esquema se versiona en VantsBasededatos
Identidad	Auth0	vants-server/worker.js valida el JWT de la sesión contra Auth0
Pagos	Stripe, con sus webhooks en Neon Functions	neon-functions/stripe-checkout/ y neon-functions/stripe-webhook/
Bot	VANTCALL, bot de Discord en Python (discord.py)	bot/. Ver Bot de Discord
Agente	Agente VANTS: vigila la plataforma, registra incidencias y ejecuta órdenes	services/agent-service/
Eventos	VANTS-BUS, bus de eventos entre proyectos	vants-bus/. Ver Bus de eventos
Clientes	Web, launcher de escritorio Electron y app Android (TWA)	android/, y el launcher en vants-dev-launcher

Las rutas son las de Vantsgames. vants-dev-launcher añade una home en Astro con islas React y Vue (webapp/) y servicios en contenedores Docker (services/api-gateway/ y services/matchmaking-service/), pero el Worker sigue siendo el único servidor de producción. Para encontrar el archivo exacto de cada cambio, consulta Mapa del código.

Recorrido de una petición

1. El Worker recibe todas las peticiones y aplica la protección contra bots, los límites de uso y las cabeceras de seguridad.
2. Las páginas y los archivos estáticos salen de vants-server/public/.
3. Las lecturas públicas pasan por la Neon Function vantsdata, que solo acepta GET sobre una lista cerrada de tablas públicas.
4. Las escrituras van siempre a la Neon Data API. El Worker reenvía el JWT de Auth0 del usuario y la RLS de cada tabla decide si la operación se permite.

El Worker no guarda credenciales de la base de datos. Las rutas, los parámetros y las respuestas de la API están en API pública, y las tablas en Esquema de la base de datos.

Despliegues

Un push a main lanza workflows de GitHub Actions independientes, según los archivos que cambien:

Cambia	Workflow	Qué hace
scripts/, vants-server/, neon-functions/ o db/	tests	Pruebas automáticas.
db/migrations/	neon-migrate	Migraciones de la base de datos (idempotentes).
neon-functions/	neon-deploy-functions	Despliegue de las funciones de Neon.
vants-server/	cloudflare-deploy	Despliegue del Worker con wrangler deploy.

Son workflows separados: el despliegue no espera a que terminen las pruebas. Los despliegues y las migraciones comparten una cola y se ejecutan de uno en uno. Otros workflows se ejecutan con un horario, como la sincronización con FACEIT, el monitor o el agente; la lista completa está en Workflows.

Más detalle en Vantsgames, VantsBasededatos y Seguridad.

Decisiones

Las decisiones que costaría deshacer se registran en DECISIONS.md, en la raíz de Vantsgames y de vants-dev-launcher. Estas son las que más condicionan el código:

Decisión	Qué implica
D1	No se reescribe a Next.js: se mantienen el Worker, el frontend estático y Neon.
D4	Los datos de demostración llevan is_demo = true y la web los marca como DEMO.
D5	La web está preparada para español e inglés. Las páginas de torneos usan rutas con /es/ y /en/.
D6	Sin redes de analítica ni de publicidad de terceros.
D9	Los datos reales de FACEIT llegan por su Data API v4 oficial y una sincronización programada, sin scraping.
D10	pt_players es un catálogo público separado de la tabla players.
D11	La home en Astro y los servicios en contenedores complementan al Worker, que sigue siendo el único servidor de producción.
D12	Identidad visual MYKD: rojo y negro.
D13	La numeración de las migraciones está congelada: no se renombran migraciones antiguas.

Los términos propios de esta página están definidos en Glosario.