Sense servidors propis, Deno i un sol proveïdor: la columna vertebral

Al setembre va arribar el moment de triar tecnologia. És una conversa que en molts projectes dura mesos; nosaltres la volíem tancar en una setmana. La pregunta no era "quin stack és el millor?" sinó "quin stack ens permet anar de pressa sent dues persones i dormir tranquils en producció?".

La resposta curta: Supabase i prou per començar. Sense servidors propis, sense Kubernetes, sense Java. La resposta llarga és aquesta entrada.

El que vam descartar expressament

Hi va haver opcions que sobre el paper semblaven sensates i que vam ratllar sense pestanyejar:

• Java + Spring Boot. És el que coneixem de la feina anterior, però significa servidors per mantenir, desplegaments lents i un consum de memòria desproporcionat per a la nostra mida.
• Microserveis. Per a un equip de dos, són una manera elegant de crear-te problemes que no tens. Vam començar amb un monòlit frontend i funcions serverless.
• Servidors propis en bare metal. Atractiu a llarg termini per costos, però no per a un MVP. Quan facturem prou ens ho replantejarem.

Per què Supabase

Supabase ens dona en una sola plataforma quatre coses que d'una altra manera serien quatre contractes diferents:

1. Postgres gestionat. Una base de dades seriosa, no una NoSQL exòtica. SQL ens dona la flexibilitat de fer informes, joins i migracions predictibles.
2. RLS (Row Level Security) natiu. Crític per a multi-restaurant: cada workspace només veu el seu, garantit a nivell de base de dades. No hi ha "ai, se m'ha oblidat filtrar per restaurant_id".
3. Auth integrat. Correu, contrasenya, magic link, recuperació. Tot el que és avorrit i que hauríem de reescriure.
4. Storage. Per a fotos de carta, logos, documents. Sense haver de muntar un S3 i signar URLs a mà.

Edge functions en Deno

Per a la lògica de servidor (webhooks, integracions, jobs curts) vam triar les edge functions de Supabase, que corren sobre Deno. Tres motius:

• TypeScript directe, sense pipeline de build. Escrius i desplegues. Per a integracions puntuals és ideal.
• Arrenquen en mil·lisegons. Zero servidors ociosos, zero cost quan no es criden.
• Mateix llenguatge que el frontend. No haver de canviar el xip mental entre el client i el servidor.

Per a processos llargs (enviaments massius de correu, sincronització inicial amb TheFork) les edge functions no funcionaran. Aquests casos els anirem resolent a mesura que apareguin, probablement amb cues i workers.

El que això implica

Aquesta arquitectura té un preu: depenem molt de Supabase. Si demà canvien els preus o tenen una caiguda llarga, patim. Ho assumim a canvi de poder anar molt de pressa. I la base és Postgres estàndard, així que migrar a un altre proveïdor gestionat en el futur és feixuc però no traumàtic.

Pròxim lliurament: com vam acabar modelant les dades perquè un grup amb tres locals pugui gestionar-ho tot des d'un sol compte.