Com funciona RestaPro per dins

Arquitectura comprovada el 9 d’octubre de 2026. La configuració dels proveïdors pot canviar; els compromisos de disponibilitat i recuperació necessiten evidència operativa pròpia.

Stack en una imatge

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

El frontend es publica a Vercel des d’aquest monorepo. La lògica de negoci s’executa en Edge Functions Deno i PostgreSQL. El servidor antic no forma part de l’allotjament ni del procediment actual de recuperació.

Frontend

React 19, TypeScript i Vite generen l’aplicació, Admin i Pro. La Wiki utilitza Docusaurus. Tailwind CSS, TanStack React Query, React Hook Form i Zod cobreixen estils, dades i formularis. Vercel serveix els builds i les rutes configurades de cada domini.

Backend: Supabase

• PostgreSQL gestionat a Frankfurt (eu-central-1).
• 96 Edge Functions actives a la revisió del 9 d’octubre; és una fotografia d’aquella revisió.
• Auth amb sessions JWT, correu i Google OAuth; TOTP disponible a la configuració del projecte.
• Storage per a logos, portades i imatges de carta.
• Realtime per a esdeveniments de l’aplicació i pg_cron per a tasques programades.

Seguretat multi-tenant: Row Level Security (RLS)

Les polítiques RLS i les comprovacions de permisos a les Edge Functions determinen quines dades pot consultar o modificar cada membre. Aquesta separació s’ha de provar per rol, restaurant i operació; activar RLS no demostra per si sol que les polítiques siguin correctes. Les credencials de servei necessiten controls addicionals perquè poden eludir RLS.

Xifratge

El frontend utilitza HTTPS gestionat per Vercel i les connexions a Supabase requereixen TLS. Els secrets de les integracions es configuren als proveïdors i a l’entorn de les Edge Functions; no es publica el seu contingut. La configuració de TOTP no demostra que tots els comptes l’hagin activat ni que totes les rutes exigeixin un segon factor.

IA: Gemini + Pinche

Pinche utilitza Google Gemini i eines de consulta o modificació autoritzades pel backend. El model i les eines depenen de la configuració desplegada. Les condicions del tractament de dades s’han de comprovar per al servei i contracte utilitzats; no es dedueixen de les condicions d’un altre producte de Google.

Notificacions

Realtime (instantani)

Supabase Realtime distribueix esdeveniments a les sessions subscrites. La disponibilitat depèn del proveïdor, la connexió i els permisos de l’usuari.

Correu transaccional (Resend)

Resend intervé en l’enviament i la recepció de correu. L’aplicació registra els estats dels enviaments i els esdeveniments de webhook. Signatura, reintents i idempotència necessiten proves específiques: un registre processat no garanteix per si sol que una operació es completi exactament una vegada.

Pagaments: Stripe

Stripe gestiona les subscripcions, Checkout i el portal del client. L’aplicació conserva referències de clients i subscripcions, sense rebre les dades completes de la targeta. Els webhooks requereixen validació de signatura, recuperació de fallades i proves de concurrència.

Allotjament

La revisió va trobar el projecte de Vercel en un equip amb pla Pro i l’organització de Supabase a Free. El PostgreSQL auditat és a Frankfurt. Això no acredita replicació geogràfica, una regió única per a tots els proveïdors ni un SLA de recuperació.

RGPD

La ubicació de la base de dades és una part del tractament. També cal revisar les integracions, els contractes, els permisos, la retenció i els procediments d’esborrat. Més a Privacitat i RGPD.

Còpia de seguretat i recuperació

L’auditoria va verificar còpies manuals de la base de dades del 8 d’octubre: public, Auth i metadades de Storage. Els checksums i catàlegs eren vàlids, però aquelles còpies no incloïen els fitxers de Storage. No es van trobar backups gestionats accessibles ni PITR al projecte auditat.

El 9 d’octubre es va completar una nova còpia local xifrada de public, Auth i metadades de Storage juntament amb els 85 fitxers de Storage. L’assaig aïllat a PostgreSQL 17 va restaurar taules i permisos i va comprovar els fitxers de Storage. La pujada externa i la recuperació completa de Supabase, inclosos login i accés a fitxers mitjançant la seva API, continuen pendents de verificació.

S’ha preparat un flux que exporta la base de dades i tots els fitxers de Storage, valida checksums, xifra per a una clau pública GPG i permet verificar una còpia externa a Backblaze B2. El job nocturn continua inactiu fins a configurar credencials, custodiar la clau privada i validar una recuperació aïllada. El destí triat és el bucket restapro; la custòdia prevista de la clau és el gestor de contrasenyes del titular.

No hi ha una retenció de 30 dies ni un RTO inferior a quatre hores demostrats. La integritat d’un arxiu, la còpia externa i una restauració funcional són comprovacions diferents. La recuperació conjunta de base de dades i Storage necessita un període sense canvis o reconciliació, perquè l’export no és una transacció entre els dos serveis.

Monitoratge

El codi integra Sentry i logs de les Edge Functions i la base de dades. La seva presència no acredita cobertura completa, retenció ni recepció d’alertes: cal verificar aquestes condicions als serveis i assignar un responsable.

CI/CD

El workflow de GitHub Actions verifica lint, tipus, proves i build del checkout, i comprova totes les Edge Functions amb Deno 2.8.0 com a eina de CI i dependències congelades. Aquesta versió no identifica el runtime allotjat per Supabase. Comprova distribució HTTP i renderitzat del candidat amb dades sintètiques i PostgreSQL aïllat per a les regressions SQL. La configuració real de Vercel i els fluxos complets amb backend necessiten comprovacions addicionals. L’existència d’un workflow no significa que els resultats bloquegin una publicació. El procediment de lliurament ha de verificar el SHA, els checks requerits, el desplegament i el smoke posterior. Els snapshots del servidor antic no són el mecanisme de rollback de Vercel.

Continuous deployment

La lectura del 9 d’octubre de 2026 va confirmar l’assignació automàtica de dominis desactivada: la publicació utilitza promoció manual després de verificar el CI del SHA. Els Deployment Checks automàtics encara necessiten selecció i una prova de fallada; revisar l’ajust després de cada promoció.

Vercel integra el repositori i genera desplegaments per als commits. El SHA relaciona codi, CI i producció; el rollback de frontend utilitza un desplegament anterior de Vercel i no desfà una migració de base de dades. Més a Versions i publicació.