Construye confianza al consumir la API generada automáticamente por Supabase y prepara datos listos para el front end. Aquí verás cómo leer, filtrar y ordenar posts, seleccionar solo las columnas necesarias y medir el impacto en peso y tiempo de respuesta, sin memorizar recetas: solo entendiendo el patrón correcto.
¿Cómo consultar la API de Supabase con un patrón simple?
La idea clave es aplicar siempre el mismo flujo. Así reduces complejidad y aseguras respuestas útiles para la interfaz de usuario.
Elegir la tabla: por ejemplo, posts.
Seleccionar columnas: solo lo que la pantalla necesita.
Aplicar filtros: por likes o por usuario.
Ordenar resultados: ascendente o descendente.
Este patrón permite construir casi cualquier pantalla de lectura: desde el perfil del usuario hasta el feed principal, con datos limpios y listos.
¿Qué columnas seleccionar para cada pantalla?
Cuando una vista solo requiere imagen y contador de likes, selecciona esas columnas (por ejemplo: likes, image_url, user_id) y evita traer el resto. Así no hay datos repetidos ni sin uso.
Ejemplos de selección y filtros mínimos:
// Seleccionar solo lo necesario.select('likes,image_url,user_id')// Filtrar por usuario.eq('user_id','<ID_DEL_USUARIO>')
¿Cómo leer, filtrar y ordenar posts por likes y usuario?
Primero, es posible leer todos los posts. Luego, filtrar por condición, como likes mayores a 30. En el ejemplo, la consulta devolvió cinco posts, pero estaban desordenados por cantidad de likes.
¿Cómo ordenar por likes ascendente o descendente?
Ordena por la columna de likes según lo que necesites: ranking ascendente o descendente para destacar más o menos interacción.
// Ascendente: de menor a mayor.order('likes',{ascending:true})// Descendente: de mayor a menor.order('likes',{ascending:false})
Ascendente: devuelve 31, 32, 35, 42, 44.
Descendente: devuelve 44, 42, 35, 32, 31.
Esto deja la respuesta lista para una interfaz que muestre el ranking de likes con claridad.
¿Cómo filtrar por usuario con user_id?
Si la vista es el perfil, filtra por el usuario específico usando su user_id. La respuesta incluye solo sus posts, ideal para mostrar en su página sin lógicas extra en el front end.
// Posts de un usuario.eq('user_id','<ID_DEL_USUARIO>')
Útil para la página de perfil.
Evita filtrar en el cliente o en otra consulta.
Llega ya listo desde la HTTP request.
¿Cómo optimizar la respuesta para un front end más rápido?
Seleccionar menos columnas reduce el peso de la respuesta y mejora la percepción de velocidad. En la prueba, pedir solo image_url y user_id dio una respuesta de 4 KB en 244 ms. Pedir “toda la base” subió a 10 KB y 579 ms. Más del doble de tiempo para datos que no se usan.
Selecciona campos precisos para cada pantalla.
Evita traer columnas innecesarias.
Ordena en el servidor y llega con el formato final.
¿Cómo medir peso y tiempo de la respuesta?
Herramientas como HTTPie muestran el tamaño de la respuesta y el tiempo de ejecución. Así puedes validar que tu selección de columnas y ordenamiento impacten en la experiencia real del usuario.
En adelante, cada consulta seguirá este patrón: elegir tabla, seleccionar columnas, filtrar y ordenar. Con esto podrás construir el feed y páginas como el perfil de usuario, y luego integrar storage cuando toque manejar archivos.
¿Quieres que veamos otra combinación de filtros u ordenamientos aplicada a tu pantalla actual? Comparte tu caso en los comentarios.
Vine a ver el curso porque llevo un tiempo aprendiendo supabase con pura documentación y quería consolidar mejor mis bases de la herramienta.
Pero me parece completamente impractico que se enseñe de primero el uso del REST de supabase, cuando es mil veces más simple solo usarlo o desde el postgresql directamente o con el sdk para el frontend, que es la idea de esta herramienta.
Que chevere que construya el rest pero no es la mejor manera de usarlo
Hola Valentina, es cuestión de gustos. Lo importante es que ambas formas están incluidas, más adelante usamos solo el sdk y para manejo de la data usamos el SQL Editor.
Concuerdo con esto, me super perdi tratando de obtener data desde mi POSTMAN y al final termine usando la herramienta del video jaja, si creo que incluso los devs de Supabase te dan todo para que no te vayas por el camino de consultar por REST, si no que directamente consumas la data con el sdk en tu front o API que estes construyendo...
Igual me gustaria ver una clase completamente dedicada a los filtrados y ordenamientos mas comunes que pudieramos necesitar. Un Saludo Valentina y a Erasmo si es que lee esto jeje
El ordenado y filtrado es una parte importante para dar respuestas más rápidas al usuario final
No se si a alguien mas le ha pasado lo mismo, pero intento hacer x consulta desde HTTPIE y me da este error:
{
"message": "No API key found in request",
"hint": "No apikey request header or url param was found."
}
Como se le pasa los params o api key?
Hola! a mí también me sucedió la clase pasada 😅
Yo pensaba que al no tener RLS activado no era necesaria la llave pública, pero Supabase igual la exige para cualquier request REST.
Lo que tienes que hacer es agregar estos dos headers (Los headers son información extra que no se ve) a la petición:
apikey: tu llave pública (publishable / anon key)
Authorization: Bearer + tu llave pública
Con eso ya debería funcionar sin problema
Yo uso funciones RPC en Supabase para consultar de forma más rápida y eficiente, sobre todo cuando necesito:
Joins entre tablas.
Filtros dinámicos usando variables (parámetros).
Ordenamiento variable (ORDER BY) según el campo que elija en la tabla.
Así concentro la lógica en SQL, hago una sola llamada desde la app y evito consultas múltiples o lógica extra del lado del cliente
Consumo eficiente de datos con la API de Supabase
Patrón fundamental de consulta
Para obtener datos optimizados, sigue siempre esta secuencia lógica:
Selección: Define qué columnas necesitas (select) para reducir el peso de la respuesta.
Filtrado: Aplica condiciones específicas (eq) para obtener solo los registros relevantes.
Ordenamiento: Utiliza order con parámetros asc o desc para estructurar la presentación.
Beneficios de la optimización
Rendimiento: Al solicitar solo los campos necesarios, reduces drásticamente el tamaño de la carga y el tiempo de respuesta.
Experiencia de usuario: Consultas más ligeras se traducen en aplicaciones más rápidas y fluidas.
Escalabilidad: El uso de filtros desde el endpoint evita procesar datos innecesarios en el front-end.
