El Rey Jesús
El sitio de una iglesia que lee su contenido en vivo, y un panel para editarlo sin tocar código.
Iglesia El Rey Jesús Zona Norte, en Mar del Plata, cambia seguido horarios, eventos y noticias. Cada cambio necesitaba a alguien que supiera editar HTML. La iglesia quería que su propio equipo actualizara el sitio.
Tres decisiones que lo definieron.
- 01
Sin backend: el navegador lee Supabase y RLS lo protege
Por qué. El sitio es HTML estático, sin build. Carga siete tablas en paralelo con la anon key pública. RLS deja que el visitante lea solo filas activas y que los editores escriban.
El costo. El contenido se dibuja en el cliente: aparece después de cargar y los buscadores ven primero un esqueleto vacío.
- 02
Subidas firmadas por una sola función serverless
Por qué. El secreto de Cloudinary no puede vivir en el navegador. Una función de Vercel valida el token de Supabase y el rol del usuario, y recién ahí firma la subida.
El costo. Cada subida suma dos llamadas a Supabase. La función firma los parámetros que le lleguen, sin filtrarlos.
- 03
Un solo motor de formularios para todo el contenido
Por qué. Cada tipo de contenido es una declaración: campos, tipos, orden y visibilidad. El panel arma la lista y el formulario a partir de eso. Una sección nueva es una entrada, no una pantalla.
El costo. Lo que no entra en el formulario genérico necesita un caso especial dentro del motor.
El Rey Jesús
El sitio de una iglesia que lee su contenido en vivo, y un panel para editarlo sin tocar código.
- Rol
- Diseño y desarrollo
- Stack
- Vanilla JavaScript (ES modules), Supabase (Postgres, Auth, RLS), Cloudinary, Vercel Functions
Iglesia El Rey Jesús Zona Norte, en Mar del Plata, cambia seguido horarios, eventos y noticias. Cada cambio necesitaba a alguien que supiera editar HTML. La iglesia quería que su propio equipo actualizara el sitio.
Tres decisiones que lo definieron.
Sin backend: el navegador lee Supabase y RLS lo protege
Por qué. El sitio es HTML estático, sin build. Carga siete tablas en paralelo con la anon key pública. RLS deja que el visitante lea solo filas activas y que los editores escriban.
El costo. El contenido se dibuja en el cliente: aparece después de cargar y los buscadores ven primero un esqueleto vacío.
Subidas firmadas por una sola función serverless
Por qué. El secreto de Cloudinary no puede vivir en el navegador. Una función de Vercel valida el token de Supabase y el rol del usuario, y recién ahí firma la subida.
El costo. Cada subida suma dos llamadas a Supabase. La función firma los parámetros que le lleguen, sin filtrarlos.
Un solo motor de formularios para todo el contenido
Por qué. Cada tipo de contenido es una declaración: campos, tipos, orden y visibilidad. El panel arma la lista y el formulario a partir de eso. Una sección nueva es una entrada, no una pantalla.
El costo. Lo que no entra en el formulario genérico necesita un caso especial dentro del motor.