Sin servidores propios, Deno y un solo proveedor: la columna vertebral

En septiembre llegó el momento de elegir tecnología. Es una conversación que en muchos proyectos dura meses; nosotros la quisimos cerrar en una semana. La pregunta no era "¿qué stack es el mejor?" sino "¿qué stack nos permite ir rápido siendo dos personas y dormir tranquilos en producción?".

La respuesta corta: Supabase y nada más para empezar. Sin servidores propios, sin Kubernetes, sin Java. La respuesta larga es esta entrada.

Lo que descartamos a propósito

Hubo opciones que sobre el papel parecían sensatas y que tachamos sin pestañear:

• Java + Spring Boot. Es lo que conocemos del trabajo anterior, pero significa servidores que mantener, despliegues lentos y un consumo de memoria desproporcionado para nuestro tamaño.
• Microservicios. Para un equipo de dos, son una forma elegante de crear problemas que no tienes. Empezamos con un monolito frontend y funciones serverless.
• Servidores propios en bare metal. Atractivo a largo plazo por costes, pero no para un MVP. Cuando facturemos lo suficiente nos lo replantearemos.

Por qué Supabase

Supabase nos da en una sola plataforma cuatro cosas que de otra forma serían cuatro contratos distintos:

1. Postgres gestionado. Una base de datos seria, no una NoSQL exótica. SQL nos da la flexibilidad de hacer reportes, joins, y migraciones predecibles.
2. RLS (Row Level Security) nativo. Crítico para multi-restaurante: cada workspace solo ve lo suyo, garantizado a nivel de base de datos. No hay "ay, se me olvidó filtrar por restaurant_id".
3. Auth integrado. Email, password, magic link, recuperación. Todo lo aburrido que tendríamos que reescribir.
4. Storage. Para fotos de carta, logos, documentos. Sin tener que montar un S3 y firmar URLs a mano.

Edge functions en Deno

Para la lógica de servidor (webhooks, integraciones, jobs cortos) elegimos las edge functions de Supabase, que corren sobre Deno. Tres motivos:

• TypeScript directo, sin pipeline de build. Escribes y despliegas. Para integraciones puntuales es ideal.
• Arrancan en milisegundos. Cero servidores ociosos, cero coste cuando no se llaman.
• Mismo lenguaje que el frontend. No tener que cambiar el chip mental entre el cliente y el servidor.

Para procesos largos (envíos masivos de email, sincronización inicial con TheFork) las edge functions no van a funcionar. Esos casos los iremos resolviendo según aparezcan, probablemente con colas y workers.

Lo que esto implica

Esta arquitectura tiene un precio: dependemos mucho de Supabase. Si mañana cambian sus precios o tienen una caída larga, sufrimos. Lo asumimos a cambio de poder ir muy rápido. Y la base es Postgres estándar, así que migrar a otro proveedor gestionado en el futuro es trabajoso pero no traumático.

Próxima entrega: cómo terminamos modelando los datos para que un grupo con tres locales pueda gestionar todo desde una sola cuenta.