PostgREST elimina el 80% del código de tu backend

BBetter Stack
Computing/SoftwareSmall Business/StartupsInternet Technology

Transcript

00:00:00¿Y si tu base de datos Postgres fuera la API y no tuvieras que escribir ningún código de backend?
00:00:05Cada vez que creas una API escribes el mismo código de backend una y otra vez. Rutas, controladores, validación, auth, todo esto solo para hablar con tu
00:00:14base de datos. Luego cambias una columna y todo se rompe. Sin código de backend personalizado. Sin controladores. Sin capa ORM.
00:00:21Eso es lo que hace PostgREST. Es el motor detrás de Supabase. Maneja tráfico pesado de producción y en solo unos minutos
00:00:29te voy a mostrar cómo.
00:00:31Ahora, si creas APIs, este tema toca los puntos de dolor más molestos de todo el stack.
00:00:40Lógica duplicada. Defines los datos en la base de datos.
00:00:44Luego defines reglas de acceso, código de backend y validación en otro lugar.
00:00:49Luego hacemos lo mismo para el manejo de respuestas en otra parte. El mismo sistema, múltiples capas, múltiples oportunidades para que las cosas fallen.
00:00:56Postgres simplifica todo esto. Tiene más de 26,000 estrellas en GitHub y lo usa Supabase a escala de producción.
00:01:03Convierte tu esquema en una API REST lista para producción en minutos. No hay ORM, ni controladores.
00:01:10La seguridad vive en la base de datos, lo que significa menos duplicación, menos mantenimiento y mucho menos tiempo conectando todas esas cosas aburridas.
00:01:19Déjame mostrarte. Si te gustan las herramientas de programación que aceleran tu flujo de trabajo, asegúrate de suscribirte.
00:01:24Publicamos videos constantemente.
00:01:26Muy bien. Ahora construyamos esto. Bien, aquí está la configuración. Tres contenedores.
00:01:32Eso es todo. Postgres, PostgREST y Swagger UI para la documentación.
00:01:38Aquí está el archivo Docker Compose. No pasa gran cosa aquí. Solo tres servicios que he conectado entre sí.
00:01:45Lo pongo en marcha con nuestro comando infalible Docker Compose. Se ejecutará y listo.
00:01:51Sin instalar dependencias. Sin configurar un servidor. Ahora, miremos la base de datos.
00:01:55Voy a ejecutar este comando de Docker aquí y ya está. Una tabla de tareas súper simple. ID, título, completado, creado, lo básico.
00:02:04Eso es realmente todo lo que pasa aquí. Pero esta es la parte donde se vuelve útil.
00:02:09Seguridad a nivel de fila (RLS). Definimos quién puede acceder a qué directamente en SQL dentro de la base de datos.
00:02:17Sin lógica de autenticación de backend en otro lugar de nuestro sistema. Aquí está la política.
00:02:22Tengo acceso total anónimo usando true con check true. Por ahora, todo está permitido. Ahora mira esto.
00:02:29Voy a consultar las tareas con este comando curl y listo. JSON completo directamente desde Postgres.
00:02:35Sin código de API. Ahora, basándonos en eso, déjame filtrarlo. Funciona de inmediato.
00:02:41Si lo ordeno, ¡pum!, ahí está. Ahora creemos otra fila, enviamos una solicitud POST con un cuerpo JSON y terminamos.
00:02:50Y ya está en la base de datos. No hay una capa ORM intentando ponerse al día aquí.
00:02:56Y aquí está la parte que realmente sorprende a la gente. Documentación Open API, Swagger UI autogenerado. Simplemente está aquí.
00:03:04Lo abro y obtenemos una API interactiva completa. Puedes explorar todo, probar endpoints, ver esquemas.
00:03:11Así que, desde cero, ahora tienes CRUD completo, filtrado, ordenación, paginación. Tienes auth básica vía RLS y docs en menos de un minuto.
00:03:21Entonces, ¿por qué la gente usa esto? Bueno, por si eso no fuera suficiente, porque el trabajo de backend tradicional tiene un impuesto.
00:03:26Y la mayor parte de ese impuesto no es trabajo de producto. Realmente lo que estamos haciendo es todo este trabajo de mantenimiento, ¿cierto?
00:03:33Si piensas en el stack normal, tal vez sea Express, Prisma, controladores, servicios, validación en un lugar.
00:03:40Luego tenemos la autenticación en otro lugar. Tu lógica de base de datos está en una parte totalmente distinta.
00:03:45Ahora compáralo con Postgres. Tu esquema define la API. Tu seguridad es RLS.
00:03:52Tus relaciones ya existen en la base de datos. Así que en lugar de crear una capa de traducción alrededor de tus datos, simplemente los exponemos correctamente.
00:04:02Eso es muy diferente. Ahora compáralo con un backend personalizado. Tienes que escribir todo tú mismo.
00:04:07Eso te da flexibilidad, sí, claro. Pero también te da mucho más código que mantener.
00:04:13Postgres se mantiene más simple. REST más Postgres. La seguridad está en la base de datos. No está dispersa en middleware o manejadores de rutas.
00:04:23Tu mantenimiento sigue siendo bajo porque tu API sigue a tu esquema. Por eso a la gente le gusta.
00:04:28Ahora, para ser justos, aquí es donde la gente tiene problemas porque cuando algo se siente tan limpio, la gente actúa como si lo resolviera todo.
00:04:34Esto no lo resuelve todo, ¿verdad? Todavía hay cosas que debemos tener en cuenta.
00:04:38Habrá compensaciones y deberías saber qué vigilar antes de tocar esto.
00:04:43Lo que a la gente le encanta aquí es algo obvio. Es rápido para construir. Puedes pasar de una idea a una API funcional muy rápido.
00:04:51Y también escala realmente bien. Además, Supabase lo demuestra.
00:04:55Ellos lo están usando. Pero las desventajas aquí son cosas como que el uso intensivo de RLS aumentará la carga de la base de datos.
00:05:02Así que debes pensar cuidadosamente cómo diseñas esto. La lógica compleja puede llevarte a muchas funciones de SQL o vistas.
00:05:10Y a algunas personas les encantará eso y otras lo odiarán. Entonces, ¿deberías usarlo o probarlo?
00:05:15Sí, para los proyectos adecuados. Si estás creando prototipos, MVPs o cualquier cosa centrada en Postgres, entonces claro, ¿por qué no intentarlo?
00:05:23Vas a avanzar más rápido. Vas a escribir menos código y obtienes valores de seguridad por defecto más fuertes al poner las reglas en la base de datos.
00:05:32Ahora, si tu aplicación tiene una lógica muy compleja, es posible que aún quieras una capa de backend delgada encima, algo pequeño, una capa BFF para casos extremos.
00:05:40Pero incluso así, Postgres puede hacer la mayor parte del trabajo pesado por debajo. Así que la gran conclusión es esta: Postgres te permite entregar más rápido, asegurar mejor y mantener menos.
00:05:50Tu base de datos se convierte en la fuente real de datos, y tu API surge de eso en lugar de convertirse en su propio sistema separado.
00:05:58Si disfrutas de estas herramientas y consejos de programación, suscríbete al canal de Better Stack. Nos vemos en otro video.

Key Takeaway

PostgREST reduce la deuda técnica y el mantenimiento al eliminar las capas de controladores y ORM, exponiendo el esquema de la base de datos como una API segura mediante el uso de Row Level Security.

Highlights

PostgREST elimina el 80% del código de backend al transformar esquemas de PostgreSQL en APIs REST funcionales de forma automática.

La herramienta utiliza Row Level Security (RLS) para gestionar la lógica de autenticación y permisos directamente dentro de la base de datos.

El sistema genera documentación interactiva Open API y Swagger UI sin necesidad de configuración manual adicional.

Supabase utiliza este motor en entornos de producción para gestionar tráfico pesado de datos a gran escala.

La infraestructura se despliega mediante tres contenedores Docker: Postgres, PostgREST y Swagger UI.

El filtrado, la ordenación y la paginación de datos están disponibles de inmediato mediante parámetros en solicitudes HTTP.

Timeline

Eliminación de capas redundantes en el desarrollo de APIs

  • Las tareas repetitivas de backend como rutas, validaciones y controladores consumen la mayor parte del tiempo de desarrollo.
  • PostgREST actúa como un motor que convierte el esquema de Postgres en una API REST lista para producción.
  • La arquitectura elimina la necesidad de sincronizar manualmente los cambios de columnas entre la base de datos y la capa de aplicación.

El desarrollo tradicional de APIs implica duplicar lógica en múltiples capas del stack tecnológico. Al definir las reglas de acceso y la estructura de datos únicamente en la base de datos, se reducen las oportunidades de fallos de sincronización. Este enfoque simplifica el mantenimiento y acelera el flujo de trabajo al evitar el uso de librerías ORM pesadas.

Configuración técnica y seguridad integrada

  • Un archivo Docker Compose con tres servicios permite poner en marcha todo el entorno sin instalar dependencias locales.
  • Las políticas de Row Level Security (RLS) definen el acceso a los datos mediante comandos SQL estándar.
  • Las consultas GET, POST y los filtros de datos devuelven respuestas JSON directamente desde el motor de la base de datos.

La implementación utiliza contenedores para Postgres, PostgREST y Swagger UI, facilitando un entorno reproducible. El control de acceso se traslada del middleware de backend a la base de datos, donde una política simple de SQL determina quién puede leer o escribir en cada fila. Las pruebas mediante comandos curl demuestran que funciones como el ordenamiento y la inserción de datos operan sin escribir una sola línea de código de API personalizado.

Comparativa entre backend tradicional y PostgREST

  • El desarrollo convencional con Express o Prisma impone un impuesto de mantenimiento que no aporta valor directo al producto.
  • La seguridad centralizada en la base de datos evita la dispersión de lógica en manejadores de rutas o middleware.
  • La API sigue automáticamente cualquier cambio realizado en el esquema de datos.

En un stack tradicional, la lógica de validación, autenticación y base de datos reside en lugares distintos. PostgREST propone que el esquema defina la API y las relaciones existentes en la base de datos se expongan correctamente. Esto resulta en una base de código más pequeña y fácil de auditar, ya que no existe una capa de traducción artificial alrededor de los datos primarios.

Limitaciones y casos de uso recomendados

  • El uso intensivo de RLS incrementa la carga computacional sobre el motor de la base de datos.
  • La lógica de negocio extremadamente compleja puede requerir el uso de funciones SQL, vistas o una capa de backend delgada (BFF).
  • Este enfoque es óptimo para prototipos, MVPs y aplicaciones centradas en el manejo eficiente de datos.

PostgREST no es una solución universal para todos los problemas de ingeniería. Si bien acelera el desarrollo inicial y escala bien, obliga a gestionar la complejidad mediante funciones de base de datos, lo cual puede ser un inconveniente para ciertos equipos. Para aplicaciones con requerimientos inusuales, se recomienda mantener una capa mínima de backend sobre PostgREST para manejar casos extremos mientras la base de datos realiza el trabajo pesado.

Community Posts

View all posts