Cómo funciona RestaPro por dentro

Arquitectura comprobada el 9 de octubre de 2026. La configuración de los proveedores puede cambiar; las garantías de disponibilidad y recuperación requieren evidencia operativa propia.

Stack en una imagen

Internet (HTTPS)
    ↓
Vercel (dominios, TLS y distribución del frontend)
    ↓
React 19 + TypeScript (aplicación, Admin y Pro) / Docusaurus (Wiki)
    ↓
Supabase (PostgreSQL + Edge Functions + Auth + Storage)
    ↓
Integraciones: Resend, Stripe y Google Gemini

El frontend se publica en Vercel desde este monorepo. La lógica de negocio se ejecuta en Edge Functions Deno y PostgreSQL. El servidor antiguo no forma parte del alojamiento ni del procedimiento actual de recuperación.

Frontend

React 19, TypeScript y Vite generan la aplicación, Admin y Pro. La Wiki utiliza Docusaurus. Tailwind CSS, TanStack React Query, React Hook Form y Zod cubren estilos, datos y formularios. Vercel sirve los builds y las rutas configuradas de cada dominio.

Backend: Supabase

• PostgreSQL gestionado en Frankfurt (eu-central-1).
• 96 Edge Functions activas en la revisión del 9 de octubre; es una fotografía de esa revisión.
• Auth con sesiones JWT, email y Google OAuth; TOTP disponible en la configuración del proyecto.
• Storage para logos, portadas e imágenes de carta.
• Realtime para eventos de la aplicación y pg_cron para tareas programadas.

Seguridad multi-tenant: Row Level Security (RLS)

Las políticas RLS y las comprobaciones de permisos en las Edge Functions determinan qué datos puede consultar o modificar cada miembro. Esa separación debe probarse por rol, restaurante y operación; que una tabla tenga RLS activado no demuestra por sí solo que sus políticas sean correctas. Las credenciales de servicio requieren controles adicionales porque pueden eludir RLS.

Cifrado

El frontend utiliza HTTPS gestionado por Vercel y las conexiones a Supabase requieren TLS. Los secretos de las integraciones se configuran en los proveedores y en el entorno de las Edge Functions; no se publica su contenido. La configuración de TOTP no demuestra que todas las cuentas lo hayan activado ni que todas las rutas exijan un segundo factor.

IA: Gemini + Pinche

Pinche utiliza Google Gemini y herramientas de consulta o modificación autorizadas por el backend. El modelo y las herramientas dependen de la configuración desplegada. Las condiciones sobre tratamiento de datos deben comprobarse para el servicio y contrato realmente utilizados; no se deducen de las condiciones de otro producto de Google.

Notificaciones

Realtime (instantáneo)

Supabase Realtime distribuye eventos a las sesiones suscritas. Su disponibilidad depende del proveedor, la conexión y los permisos del usuario.

Email transaccional (Resend)

Resend interviene en el envío y recepción de correo. La aplicación registra estados de los envíos y eventos de webhook. Firma, reintentos e idempotencia necesitan pruebas específicas: un registro de evento procesado no garantiza por sí solo que una operación se complete exactamente una vez.

Pagos: Stripe

Stripe gestiona las suscripciones, Checkout y el portal del cliente. La aplicación conserva referencias de clientes y suscripciones, sin recibir los datos completos de tarjeta. Los webhooks requieren validación de firma, recuperación de fallos y pruebas de concurrencia.

Alojamiento

La revisión encontró el proyecto de Vercel en el equipo con plan Pro y la organización de Supabase en Free. El PostgreSQL auditado está en Frankfurt. Esto no acredita replicación geográfica, una región única para todos los proveedores ni un SLA de recuperación.

RGPD

La ubicación de la base de datos es una parte del tratamiento. También deben revisarse las integraciones, contratos, permisos, retención y procedimientos de borrado. Más en Privacidad y RGPD.

Backup y recuperación

La auditoría verificó copias manuales de la base de datos del 8 de octubre: public, Auth y metadatos de Storage. Sus checksums y catálogos eran válidos, pero esas copias no incluían los archivos de Storage. No se encontraron backups gestionados accesibles ni PITR en el proyecto auditado.

El 9 de octubre se completó una nueva copia local cifrada de public, Auth y metadatos de Storage junto con los 85 archivos de Storage. El ensayo aislado en PostgreSQL 17 restauró tablas y permisos y comprobó los archivos de Storage. La subida externa y la recuperación completa de Supabase —incluido login y acceso a archivos por su API— siguen pendientes de verificación.

Se ha preparado un flujo que exporta la base de datos y todos los archivos de Storage, valida checksums, cifra para una clave pública GPG y permite verificar una copia externa en Backblaze B2. El job nocturno permanece inactivo hasta configurar credenciales, custodiar la clave privada y validar una recuperación aislada. El destino elegido es el bucket restapro; la custodia prevista de la clave es el gestor de contraseñas del titular.

No hay una retención de 30 días ni un RTO inferior a cuatro horas demostrados. La integridad de un archivo, su copia externa y una restauración funcional son comprobaciones distintas. La recuperación conjunta de base de datos y Storage necesita un periodo sin cambios o reconciliación, porque el export no es una transacción entre ambos servicios.

Monitorización

El código integra Sentry y logs de las Edge Functions y la base de datos. Su presencia no acredita cobertura completa, retención ni recepción de alertas: hay que verificar esas condiciones en los servicios y asignar un responsable.

CI/CD

El workflow de GitHub Actions verifica lint, tipos, pruebas y build del checkout, y comprueba todas las Edge Functions con Deno 2.8.0 como herramienta de CI y dependencias congeladas. Esa versión no identifica el runtime alojado por Supabase. Comprueba distribución HTTP y renderizado del candidato con datos sintéticos y PostgreSQL aislado para las regresiones SQL. La configuración real de Vercel y los flujos completos con backend necesitan comprobaciones adicionales. La existencia de un workflow no significa que sus resultados bloqueen una publicación. El procedimiento de entrega debe verificar el SHA, los checks requeridos, el despliegue y el smoke posterior. Los snapshots del servidor antiguo no son el mecanismo de rollback de Vercel.

Continuous deployment

La lectura del 9 de octubre de 2026 confirmó la asignación automática de dominios desactivada: la publicación utiliza promoción manual después de verificar el CI del SHA. Los Deployment Checks automáticos todavía necesitan selección y una prueba de fallo; revisar el ajuste tras cada promoción.

Vercel integra el repositorio y genera despliegues para los commits. El SHA permite relacionar código, CI y producción; el rollback de frontend utiliza un despliegue anterior de Vercel y no revierte una migración de base de datos. Más en Versionado y publicación.