Header Ads Widget

Ticker

6/recent/ticker-posts

Revisión de GROQ, un nuevo lenguaje de consulta JSON

 


Los lenguajes de consulta son fundamentales para la naturaleza de la web moderna. A medida que los datos crecen e Internet se vuelve más compleja, el resultado natural son conjuntos de datos más grandes. Sin embargo, para actuar sobre esos datos, necesitamos tener sistemas que permitan el filtrado y la transformación.

Si bien existen muchas herramientas para este propósito, una herramienta interesante es GROQ . Como parte integral de la solución Sanity de Sanity.io, GROQ fue recientemente de código abierto . Ofrece una potente solución de código abierto para filtrar conjuntos de datos masivos.

Hoy, vamos a sumergirnos en GROQ y ver qué lo hace único. Veremos una invocación simple, así como algunas más complejas. También veremos dónde GROQ puede tener más sentido en comparación con otras ofertas y presentaremos un caso de uso para la inclusión de GROQ.

¿Qué es GROQ?

GROQ es un lenguaje de consulta basado en JSON que se desarrolló inicialmente para Sanity.io como una solución de consulta y ejecución. Si bien el trabajo en la oferta inicial comenzó en 2015, Sanity lanzó GROQ como estándar abierto en 2019. Puede ver el borrador de trabajo actual de GROQ aquí .

GROQ, abreviatura de G raph- R elational O bject  Q ueries, es principalmente un método de filtración: lleva a cabo el trabajo que se ha puesto tan de moda con implementaciones como GraphQL, lo que permite conjuntos de datos robustos, transformados y filtrados de grandes cuerpos de datos. En términos simples, GROQ tiene como objetivo describir exactamente qué información desea una aplicación y luego entregar esa información a través de una serie de transformaciones, uniones y procesamiento para presentar una respuesta deseada específica.

GROQ está fuertemente tipado y cuenta con una variedad de bibliotecas cliente para la extensibilidad. Admite parámetros y operadores complejos, así como funciones, tuberías y uniones avanzadas. Permite dividir, ordenar, proyectos, variables, condicionales; es una solución convincente de hecho. Veamos un ejemplo de uso de la documentación y analicemos algunos atributos clave de GROQ que pueden convertirlo en una buena elección.

Ejemplo

Invocación básica

Las declaraciones de GROQ se ven normalmente como un flujo de datos de izquierda a derecha: todo fluye primero a través del elemento de filtro, luego a través de funciones adicionales (como ordenar) y hacia la proyección. Como tal, cada elemento de la invocación principal fluye hacia el otro de una manera bastante sensible.

Echemos un vistazo a una consulta de ejemplo que podríamos querer ejecutar. Considere una API de música hipotética. Estamos intentando sacar un álbum de una lista de álbumes según su año de lanzamiento. Para hacer esto, podemos ejecutar la siguiente consulta:

*[_type == 'album' && releaseYear >= 1994]

Como todo documento en Sanity debe tener un tipo, _typeen esta consulta se indica que el tipo de documento consultado es el tipo "álbum". Desde aquí, usamos &&para indicar "y" y adjuntar la releaseYearsolicitud. Al usarlo releaseYear, asumimos que dicho campo existe en los datos y que contiene números a los que podemos aplicar un filtro "mayor o igual a".

Cuando ejecutamos esta consulta, obtenemos una salida limpia: todos los álbumes que tienen un año de lanzamiento igual o superior a 1994. Todo esto está muy bien, pero podemos usar proyecciones para hacerlo más útil.

Proyecciones

Se puede usar una proyección en GROQ para describir los datos que queremos de cada consulta y entregar esos datos en una forma más limpia y comprensible. Si tomamos nuestra consulta inicial y agregamos una proyección, obtenemos algo como esto:

*[_type == ‘album' && releaseYear >= 1994]{ _id, title, releaseYear }

En este ejemplo, todavía obtenemos los datos que solicitamos en el primer ejemplo; sin embargo, obtenemos varios elementos más de datos que podemos usar para filtrar y transformar. _id allowsusamos para tomar el ID de datos, el título nos permite tomar el título del álbum y releaseYearnos permite generar el año en sí en lugar de simplemente devolver todos los datos del conjunto que coinciden con la consulta.

De esta manera, hemos hecho que nuestro retorno sea mucho más eficiente y efectivo, y hemos obtenido mucha más información para la transformación y la contextualización.

Ordenar

Nuestra solicitud de datos está completa, pero aún es algo complicada. Los álbumes que extraemos de esta lista volverán en el orden en que fueron ingresados; en nuestro caso, donde queremos ver una lista cronológica de álbumes por año, esto hace que la experiencia no sea óptima. Por lo tanto, podemos usar la clasificación para ordenar nuestra salida usando la función de orden.

Transformemos nuestra solicitud:

*[_type == 'album' && releaseYear >= 1994] | order(releaseYear) {_id, title, releaseYear}

Con esta solicitud, obtenemos nuestros datos iniciales, pero los clasificamos por año de lanzamiento. Esto nos permite ver una lista cronológica de elementos: Sanity se establecerá de forma predeterminada en orden ascendente, lo que significa que veremos el más antiguo primero.

Caso de uso

GROQ es solo una de las muchas opciones de lenguaje de consulta: ¿qué lo convierte en una buena opción frente a algo como GraphQL? Primero (y más obvio), GROQ es una gran opción para una aplicación nativa de Sanity. Debido a que Sanity ha incorporado GROQ como lenguaje de consulta, tiene mucho sentido adoptar GROQ frente a otras alternativas. Dicho esto, Sanity también es compatible con GraphQL.

Quizás el argumento más fuerte a favor de GROQ es el hecho de que es relativamente delgado y expresivo. GROQ permite más consultas de forma libre de las que permiten algunas técnicas de mapeo GraphQL. Por ejemplo, podemos ver esta consulta en GraphQL (mapeada a través del mapeador GraphQL de Sanity):

{
  authors(where: {
      debutedBefore_lt: "1900-01-01T00:00:00Z", 
      name_matches: "Edga*r"
  ) {
    name,
    debutYear,
  }
}

Cuando se expresa en GROQ, obtenemos lo siguiente:


*[_type == "author" && name match "Edgar" && debutYear < 1900]{ name, debutYear }

Si bien la implementación de GROQ es quizás más compleja que la opción mapeada de GraphQL, no obstante es más compacta, al tiempo que conserva gran parte de la sintaxis clara. A medida que las solicitudes se vuelven cada vez más complejas, estos ahorros pueden tener un valor obvio para el código final.

Conclusión

GROQ es un lenguaje de consulta sólido, y para aquellos que codifican de forma nativa con Sanity, es una gran opción. Sin embargo, debe recordarse que es simplemente eso: una opción. Si funciona o no en su flujo de código o en la implementación que elija, dependerá en gran medida de la tecnología en uso, las soluciones empleadas y las demandas generales de la consulta de datos.

Debería ser obvio que GROQ se emplea mejor cuando Sanity es parte del proyecto en general. Al ser la solución incorporada para consultas, se puede aprovechar a mayores alturas de tal manera que sea transparente y fácil de integrar. Sin embargo, cuando Sanity no es parte del proyecto, la propuesta de valor cambia significativamente, ya que el uso de GROQ requiere un mayor esfuerzo de implementación.

En total, GROQ sigue siendo una gran herramienta y una a considerar cuando se busca aprovechar los lenguajes de consulta.



Publicar un comentario

0 Comentarios