Saltar al contenido principal

Cómo funciona RestaPro por dentro

Para hosteleros técnicos, partners o cualquiera que quiera entender la arquitectura sin leer código.

Stack en una imagen​

Internet (HTTPS)
    ↓
Traefik (TLS · rate limit 100 req/s + burst)
    ↓
nginx (gzip · caché inmutable · headers seguridad)
    ↓
React 19 + TypeScript (build estático)
    ↓
Supabase (PostgreSQL + Edge Functions + Auth + Storage)

Frontend estático servido por nginx, sin servidor de aplicación tradicional. Todo lo que no es UI corre en Edge Functions Deno o en PostgreSQL vía RLS.

Frontend​

  • React 19 + TypeScript + Vite.
  • Build estático compilado a HTML+JS+CSS con hashes en el nombre (caché eternamente).
  • Tailwind CSS 4 con tokens en oklch().
  • shadcn/ui + base-nova como sistema de componentes.
  • Servido por nginx en :8090.
  • TanStack React Query para state del servidor.
  • React Hook Form + Zod para formularios.

Backend: Supabase​

  • PostgreSQL gestionado en Frankfurt (EU). Cumple RGPD por diseño.
  • Edge Functions Deno: ~60 funciones serverless que corren bajo demanda.
  • Auth: JWT con refresh tokens, email+contraseña + Google OAuth.
  • Storage: para logos, portadas, imágenes de carta.
  • Realtime: notificaciones instantáneas vía WebSocket.
  • pg_cron: tareas programadas (cron de emails, expiración de propuestas, etc.).

Seguridad multi-tenant: Row Level Security (RLS)​

Cada tabla con datos de cliente tiene políticas RLS que filtran filas según el usuario logueado a nivel de PostgreSQL:

USING (workspace_id IN (
  SELECT workspace_id FROM workspace_users
  WHERE user_id = auth.uid()
))

Aunque alguien hackeara una sesión, la BD rechaza queries entre workspaces. Es seguridad a nivel de DBMS, no de aplicación.

Cifrado​

  • En tránsito: HTTPS/TLS 1.3 con certificados Let's Encrypt automatizados por Traefik.
  • En reposo: PostgreSQL cifra el volumen.
  • Contraseñas: bcrypt (no reversibles).
  • Secretos (Stripe API key, Gemini key, Resend, etc.): en Supabase Vault, no en .env ni en repositorio.

IA: Gemini + Pinche​

  • Gemini 2.5 Flash de Google con function calling.
  • Pinche: 25 herramientas (10 escritura + 15 lectura).
  • Cada llamada se logea en pinche_chat_logs para auditoría.
  • Política Vertex AI de Google: los datos no se usan para entrenar modelos.

Notificaciones​

Realtime (instantáneo)​

Cuando entra una reserva online, todos los dispositivos del equipo reciben un toast en tiempo real vía Supabase Realtime (WebSocket sobre PostgreSQL CDC).

Email transaccional (Resend)​

  • Envío de confirmaciones, recordatorios, alertas, campañas.
  • Idempotencia en webhooks (resend_processed_events): si Resend reenvía por timeout, se procesa una sola vez.
  • Email logs auditables: cada envío con timestamp, status, tokens.
  • Headers List-Unsubscribe RFC 5322 para que Gmail dé un click.

Pagos: Stripe​

  • Suscripciones gestionadas por Stripe Billing.
  • Checkout Session + Portal de cliente para pagos y autogestión.
  • Webhooks con idempotency check (stripe_processed_events).
  • RestaPro no almacena tarjetas — solo Stripe Customer ID y Subscription ID.

Alojamiento​

  • Supabase: AWS Frankfurt (EU). Replicación + backups diarios con retención 30 días.
  • CDN: Cloudflare para activos estáticos.
  • Edge Functions: latencia de servidor cercano al usuario.

RGPD​

  • Datos en Frankfurt, sin transferencias fuera de la EU sin salvaguardas.
  • Derecho al olvido vía RPC gdpr_delete_customer: anonimiza nombre, email, teléfono en customers, customer_identities, email_logs, email_queue, marketing_*. Mantiene reservas para auditoría/contabilidad.
  • Auditoría completa en activity_logs.
  • Más en Privacidad y RGPD.

Backup y recuperación​

  • Supabase backups diarios automáticos (retención 30 días).
  • Replicación geográfica.
  • En caso de borrado accidental: contactar soporte de Supabase para restore desde backup específico (RTO ~4 h).

Monitorización​

  • Sentry: captura de errores en frontend con userId + restaurant_id como tags. Filtros antibot.
  • Logs estructurados en edge functions vía createLogger con metadata.
  • Activity log en BD para acciones sensibles (cambios de rol, GDPR delete, etc.).

CI/CD​

  • GitHub Actions ejecuta lint + typecheck + tests + build en cada push.
  • Smoke tests HTTP post-deploy: si fallan, abortamos.
  • Snapshots de los últimos 10 builds en /opt/backups/restapro-dist/ para rollback rápido.

Continuous deployment​

  • Cada commit en main puede llegar a producción tras revisión manual.
  • Build ID = git SHA, visible en <meta name="restapro:build-id">.
  • Sin versionado semántico — los cambios fluyen continuamente.

Más en Versionado y publicación.

Última actualización en
ESENCA