Header Ads Widget

Ticker

6/recent/ticker-posts

Datos federados con HyperGraphQL

 ¿HyperGraphQL es la extensión de datos vinculados para GraphQL que estábamos esperando?


Los datos , en muchos sentidos, son la fuerza impulsora detrás de gran parte de lo que hace la industria de la tecnología de la información para innovar. Cada elección se basa en gran medida en la capacidad de uno para encontrar datos, asegurarlos y luego formar relaciones dentro de una red de puntos no conectados.

Por lo tanto, los datos vinculados se trata de conectar datos de una manera significativa para descubrir estas relaciones adicionales, aumentando nuestra comprensión y el valor de fuentes dispares. GraphQL es prometedor en este sentido, pero en su forma básica se limita solo a un conjunto de datos discretos o recopilados.

Ingrese HyperGraphQL . Diseñado para permitir la combinación, comparación y análisis de conjuntos de datos dispares, HyperGraphQL promete ser la nueva evolución de GraphQL con datos combinados y enlazados a la vanguardia , pero ¿cumple esta promesa? Hoy, veremos HyperGraphQL y veremos qué ofrece exactamente.

¿Qué es HyperGraphQL?

HyperGraphQL es esencialmente una evolución de GraphQL propiamente dicho y funciona como una interfaz que se utiliza para consultar y servir datos vinculados . GraphQL fue diseñado originalmente por Facebook para uso interno, pero luego se lanzó al público en 2015; este origen expone el propósito y la función reales de GraphQL. Como explicamos anteriormente , GraphQL permite a los usuarios finales indicar lo que esperan de una fuente de datos y formar la respuesta recibida de una manera y forma específicas para su posterior procesamiento. De esta manera, permite consultas y enlaces bastante expresivos entre ciertos objetos y sus relaciones, lo que impulsa el tipo de red relacional que ha llegado a dominar los datos modernos.

HyperGraphQL podría verse entonces como un desarrollo adicional de este concepto. Al ofrecer una experiencia GraphQL básica junto con una metodología más robusta de federación de datos (un tema que discutiremos en breve), HyperGraphQL ofrece una forma más significativa de vincular objetos relacionados y realizar consultas sobre ellos, incluso si esos objetos y relaciones no están contenidos exclusivamente en un base de datos singular: el concepto mismo de datos enlazados .

Linked Data, brevemente, es un concepto y un conjunto de especificaciones que ha sido desarrollado por el W3C para conectar datos en la web y vincular esos datos en forma relacional. Todo el concepto y el objetivo de los datos vinculados es tratar los datos no como conjuntos únicos y dispares, sino tratarlos como subconjuntos discretos de una especie de almacén de datos "global". Establecer una relación, vincular esos recursos y tratarlos como un elemento singular en un almacén de datos virtualizado singular es todo lo que HyperGraphQL está intentando hacer.

HyperGraphQL: una interfaz GraphQL para consultar y servir datos vinculados que admite "consultas federadas y exponer datos de múltiples servicios de datos vinculados utilizando esquemas y lenguaje de consulta GraphQL". HyperGraphQL.org

Lea también: Cómo envolver una API REST en GraphQL

Beneficios y obstáculos

Dado que HyperGraphQL se basa en GraphQL en sí, es igualmente extremadamente flexible y expresivo . Esto significa que, cuando se combina con estándares y lenguajes de consulta expresivos, los datos combinados pueden extraerse para obtener información más útil , procesable y valiosa que la que podría generar cualquier fuente singular. Esto también significa que los datos son flexibles tanto en el tránsito como en la solicitud: solo se entrega lo que se solicita y en la forma solicitada, lo que permite la flexibilidad de los recursos y una excelente escalabilidad .

El uso de HyperGraphQL también elimina gran parte del costo tradicional inherente a la generación de datos a partir de recursos combinados. Por lo general, se debe crear una base de datos física singular utilizando datos combinados, esencialmente convirtiendo muchos en uno. Si bien esto es factible, esto conduce a algunos problemas de inseguridad de datos bastante importantes y también conduce a la saturación del servidor ya que se necesitan más y más recursos de forma permanente. Al crear una base de datos virtualizada que es efímera mientras dure la acción que se está tomando, los datos se vuelven más seguros y se reducen los recursos necesarios.

Sin embargo, no todo es perfecto: HyperGraphQL introduce cierta complejidad con los datos, especialmente cuando las fuentes dispares son numerosas. Una interfaz limpia y de fácil comprensión media en cierto modo esto, pero el proceso sigue siendo muy complejo e intensivo, y en situaciones con una gran cantidad de fuentes, las ganancias en la minería de bases de datos efímeras se pueden perder rápidamente.

Por supuesto, existe un problema de seguridad que es inherente a la recopilación de macrodatos en general. Cuando se trabaja con tantos conjuntos de datos, es muy importante asegurarse de que los datos estén cifrados en tránsito. Esto es menos problemático con los datos combinados cuando controlas la base de datos singular creada; sin embargo, cuando la base de datos es virtual y efímera, esto se vuelve más complicado.

Además, los términos de los servicios de las fuentes de datos, así como las limitaciones legales locales, pueden dictar que los datos en cuestión no se pueden capturar, combinar o distribuir en primer lugar. Si bien muchas API ofrecen datos públicos para el consumo, otras fuentes de datos pueden regirse por leyes como el GDPR en la Unión Europea. Si bien esto ciertamente no es un problema para sus propios datos localizados, si ya está en cumplimiento, la importación de datos de fuentes que no cumplen con GDPR para comparación analítica y federación de datos puede pasar la responsabilidad a su propia base de datos y su propia organización. Esto debe considerarse tanto como un problema técnico como operativo.

Consulte también: ¿GraphQL se está moviendo hacia la ubicuidad?

¿Qué es la Federación de datos?

Mientras discutimos el valor de HyperGraphQL, también deberíamos tomarnos un momento para hablar sobre la federación de datos . El concepto de federación de datos es engañosamente simple: es el proceso de unir datos de fuentes dispares en una sola base de datos virtualizada , sobre la que se puede actuar como si fuera una fuente de datos singular. Esto es requerido por los procesadores de datos porque, a menudo, los datos se encuentran en una variedad de formas y ubicaciones diferentes, y ofrecer acciones basadas en estos conjuntos de datos requiere un sistema singular desde el cual extraer y hacia el cual podemos hacer referencia.

La federación de datos se facilita en HyperGraphQL mediante el uso de consultas combinables . Debido a que GraphQL por diseño devuelve datos de una manera especificada y demandada, varios conjuntos de datos pueden tener puntos de datos extraídos de sus almacenes de datos, y luego se les pueden asignar valores y unirlos con otros servicios y almacenes de datos para crear una base de datos virtual ad hoc . Cuando se hace esto, el contenido se vincula y se puede extraer valor de los datos vinculados.

Esto se hace no a través del lenguaje de consulta propiamente dicho, sino a través de la configuración de la instancia . Cuando se configura la instancia, los servicios deben identificarse, asociarse con URI y proporcionar definiciones de relación. A partir de ahí, la consulta interna puede ser como cualquier otra consulta GraphQL, pero puede devolver cantidades mucho mayores de información vinculada . En esencia, la capa de interacción es opaca mientras que la capa interna se federa entre los servicios, un método limpio y fácil para vincular datos.

Ejemplo de consulta y respuesta HyperGraphQL

Veamos un ejemplo de solicitud y respuesta de HyperGraphQL extraídas de la documentación de HyperGraphQL para obtener más contexto.

Un ejemplo de consulta HyperGraphQL se ve así:

{
  Person_GET(limit: 1, offset: 6) {
    _id
    _type
    name
    birthDate
    birthPlace {
      _id
      label(lang: "en")
      country {
        _id
        label(lang: "en")
      }
    }
  }
}

La respuesta es un objeto JSON GraphQL típico, pero aumentado con un contexto JSON-LD:

{
"extensions": {}, "data": { "Person_GET": [ { "_id": "http://dbpedia.org/resource/Sani_ol_molk", "_type": "http://dbpedia.org/ontology/Person", "name": "Mirza Abolhassan Khan Ghaffari", "birthDate": "1814-1-1", "birthPlace": { "_id": "http://dbpedia.org/resource/Kashan", "label": [ "Kashan" ], "country": { "_id": "http://dbpedia.org/resource/Iran", "label": [ "Iran" ] } } } ], "@context": { "birthPlace": "http://dbpedia.org/ontology/birthPlace", "country": "http://dbpedia.org/ontology/country", "_type": "@type", "name": "http://xmlns.com/foaf/0.1/name", "_id": "@id", "label": "http://www.w3.org/2000/01/rdf-schema#label", "people": "http://hypergraphql.org/query/Person_GET", "birthDate": "http://dbpedia.org/ontology/birthDate" } }, "errors": [] }
También relacionado: 7 beneficios únicos de usar GraphQL en microservicios

Conclusión

En conclusión, HyperGraphQL es un recurso poderoso que promete unir fuentes de datos dispares. Si bien esto agrega un valor enorme, se debe considerar la fuente de estas bases de datos; para los datos locales, las ramificaciones son menores, pero para los datos externos, abundan los problemas legales y las preocupaciones de privacidad. Como tal, HyperGraphQL debe verse como lo que es: una herramienta poderosa para considerar caso por caso.

Dicho esto, HyperGraphQL no es la solución definitiva para todas las soluciones. Los datos enlazados son valiosos, pero pueden causar un ruido significativo en conjuntos de datos que son demasiado grandes. Sin embargo, si existe la necesidad, HyperGraphQL ofrece una excelente manera de aprovechar los datos federados y debe considerarse una parte importante del conjunto de herramientas para los procesadores de datos

Publicar un comentario

0 Comentarios