Llevas cinco módulos aprendiendo sobre Supabase. En este módulo vemos cómo esas piezas funcionan juntas en una aplicación real, con lo que ocurre de verdad por dentro.

La aplicación que usamos como ejemplo es MiraMiEvento — un álbum privado para eventos como bodas o comuniones. Solo entran las personas invitadas, y cada una ve lo que le corresponde.

1. La persona se identifica

La aplicación muestra un campo para introducir un código. Cuando la persona lo envía, el servidor comprueba ese código contra una tabla de Supabase llamada access_codes. Si coincide, este paso identifica a la persona y le asigna permisos dentro del evento.

En una app bien construida, después de validar el código se crea o asocia una sesión segura, o se validan los permisos desde servidor, para que Supabase pueda aplicar correctamente las reglas de acceso.

2. Según tus permisos, ves datos diferentes

Con los permisos asignados, la aplicación consulta la tabla photos. Las políticas RLS comprueban qué permisos tiene esa sesión y qué datos puede ver. Si eres invitado, ves las fotos del evento. Si eres el organizador, las ves todas — incluso las que aún no están publicadas.

Las políticas se definen una vez. Supabase las aplica automáticamente a cada consulta.

3. Las fotos no están en la tabla

En la tabla photos no hay imágenes. Lo que hay es información sobre cada foto: su nombre, quién la subió, cuándo, y dónde está guardada en el Storage. Una fila de esa tabla tiene este aspecto:

nombre: "ceremonia-01.jpg"
carpeta: "boda-garcia-2026"
subida_por: "organizador"
fecha: "2026-05-10"

Cuando la aplicación quiere mostrar esa foto, usa esa dirección para ir a buscarla al Storage. Pero el bucket es privado — no puede traerla directamente, necesita permiso.

4. La aplicación genera una URL firmada

Para mostrar cada foto, la aplicación genera una URL firmada — una dirección temporal que da acceso a ese archivo durante un tiempo limitado.

Esa URL se genera solo después de comprobar que la persona tiene permiso para ver esa foto. Si no lo tiene, la URL nunca llega a generarse.

5. Alguien intenta acceder sin permiso

Las políticas RLS bloquean el acceso a la tabla: sin permisos válidos, no puede ver el registro. Y si no puede ver el registro, la aplicación no genera la URL firmada.

Un matiz importante: mientras la URL firmada no haya caducado, quien la tenga podría abrirla. Por eso debe durar poco y generarse solo después de comprobar permisos.

6. El organizador sube una foto

Cuando el organizador sube una foto, la aplicación hace dos cosas:

  • Sube el archivo al Storage
  • Crea un registro en la tabla photos con los datos de ese archivo

Si fallara la segunda, habría un archivo en el Storage sin registro en la tabla. Una aplicación bien construida comprueba que ambas han ido bien antes de confirmar que la foto está publicada.

El sistema completo

Invitada
    ↓
Introduce código → Servidor valida en access_codes → Permisos asignados ✓
    ↓
Pide ver fotos → RLS comprueba sus permisos → Ve las que le corresponden
    ↓
Quiere ver una foto → Aplicación genera URL firmada → Ve la imagen
    ↓
URL caducada o sin permisos → Acceso denegado ✗

Lo que hemos construido

Una aplicación con cuatro capas que trabajan juntas:

  • Tablas — información estructurada
  • Autenticación — sesiones o permisos que identifican a cada persona
  • Storage — archivos guardados de forma organizada
  • Seguridad — reglas que se aplican automáticamente

Esta arquitectura es la misma base de cualquier aplicación seria: una clínica, una plataforma de cursos, una tienda online. Cambian los datos, la estructura es la misma.

En el próximo módulo

Todo esto vive en Supabase. Pero para que alguien con un móvil en cualquier parte del mundo pueda acceder, la aplicación tiene que estar en internet. Eso es lo que hace Vercel.

Fuentes