Saltar a contenido

Dependencias Externas — Gastro

Cuadrante 04_EXPLANATION. Este documento explica de qué depende Gastro y por qué. No es la fuente canónica de variables, puertos ni contratos exactos: esa información vive en los 03_REFERENCE de cada sub-componente.

1. Principio de ownership

Gastro no es una app única. Es una vertical compuesta por cuatro superficies:

  • backend/: autoridad transaccional y multi-tenant.
  • frontend/marketing-site/: funnel comercial y flujos de cuenta.
  • frontend/admin-panel/: operación privada del negocio.
  • frontend/public-menu/: carta pública por slug.

Cada superficie tiene dependencias distintas, pero el backend sigue siendo la pieza central: todos los frontends dependen de sus APIs o de sus side effects.

2. Dependencias críticas de infraestructura

PostgreSQL

Es la fuente de verdad de Gastro.

Dependen de PostgreSQL:

  • tenants
  • founders
  • staff
  • categorías
  • productos
  • historial de precios
  • auditoría
  • estado de onboarding

Razón arquitectónica:

  • permite multi-tenancy fuerte con tenant_id
  • soporta RLS con app.current_tenant_id
  • sostiene constraints e índices parciales que el menú público necesita para latencia baja

Referencia exacta:

Redis

Redis es acelerador, no fuente de verdad.

Se usa para:

  • caché del menú público
  • resolución slug -> tenant_id
  • rate limiting
  • idempotencia
  • soporte auxiliar para sesión y hardening

Razón arquitectónica:

  • evita round-trips repetidos al backend para lectura pública
  • protege endpoints sensibles
  • desacopla features defensivas de la base transaccional

Referencia exacta:

Storage de imágenes: Cloudflare R2 / MinIO

Gastro no sirve imágenes binarias desde PostgreSQL.

Se usa storage externo para:

  • logos
  • portadas
  • imágenes de productos

Razón arquitectónica:

  • mantener la base transaccional ligera
  • permitir pipeline de procesamiento y compresión
  • exponer URLs públicas estables a los frontends

En local puede usarse MinIO; en despliegues reales la integración nominal es R2.

Referencia exacta:

3. Dependencias de producto y servicios externos

Gemini

Gemini se usa en ai_onboarding para extraer menú y perfil desde imágenes o PDFs.

Qué implica:

  • el onboarding IA no es completamente autónomo
  • la calidad del flujo depende de un proveedor externo de IA
  • la persistencia final sigue siendo responsabilidad del backend Gastro

Referencia:

Resend

Resend soporta:

  • recuperación de contraseña
  • verificación de email
  • comunicaciones básicas de cuenta

Qué implica:

  • los flujos de cuenta del marketing-site y del backend dependen de un proveedor de email
  • sin esta dependencia, la app puede seguir existiendo, pero algunos journeys quedan degradados

Referencia:

Foveo

La fidelización visible hoy en el admin-panel no es todavía un bounded context nativo de Gastro.

Se integra con Foveo para:

  • membresías
  • puntos
  • recompensas
  • kiosco del cajero

Qué implica:

  • loyalty hoy es una capacidad parcialmente externa al core de Gastro
  • la promesa comercial existe dentro de la vertical, pero parte de la ejecución depende del ecosistema TimeLiber

Referencia:

4. Dependencias entre sub-componentes internos

marketing-site depende de:

  • backend Gastro para signup, forgot-password, reset, verify
  • public-menu para el demo público enlazado desde el funnel
  • admin-panel como destino del login privado

admin-panel depende de:

  • backend Gastro para auth, perfil, menú, media, usuarios y platform
  • Foveo para loyalty actual
  • public-menu como destino de QR, preview y validación operativa

public-menu depende de:

  • backend Gastro para GET /api/v1/public/menu/{slug}
  • theming y contenido suministrado por tenant

La relación correcta es:

marketing-site ─┐
admin-panel ────┼──▶ backend
public-menu ────┘

admin-panel ───▶ Foveo
backend ───────▶ Gemini / Resend / R2

5. Regla documental importante

Este documento no debe duplicar:

  • tablas exactas de variables de entorno
  • defaults de puertos
  • contratos de API
  • rutas detalladas

Toda esa información pertenece a 03_REFERENCE y debe apuntar al origen canónico correspondiente.

6. Referencias canónicas