Header Ads Widget

Ticker

6/recent/ticker-posts

Potencie los esquemas GraphQL con visualización y contenido atractivo


 

La estructura y el significado deben ser correctos

GraphQL es de hecho una API de datos atractiva para aplicaciones (y personas). Sin embargo, incluso si conoce los conceptos básicos de GraphQL, es posible que tenga problemas para hacer que las estructuras de datos de la API sean correctas y para embellecer el contenido de los datos para que sea compatible con los negocios.

¿Qué significa "bonita", de todos modos? La mayoría de la gente puede responder eso por vestidos de diseñador, flores, mascotas, bebés, etc. ¿Pero datos bonitos Resulta que en realidad hay dos dimensiones de esto: estructura (de los datos) y significado (la semántica empresarial). Si hace ambas cosas bien, sus datos están listos para funcionar.

Existe un enfoque para el análisis y el diseño basados ​​en la información, que es "New Nordic" en el sentido de que implementa los valores tradicionales de la marca nórdica, como calidad superior, funcionalidad, confiabilidad e innovación. Dentro de este contexto, a continuación se presenta una propuesta de nuevas formas de comunicar tanto la estructura como el significado del contexto empresarial en la API GraphQL. Las visualizaciones del esquema y de las consultas son partes importantes de esto.

Como sabe, GraphQL no es una base de datos, sino una API de datos, que se describe en (y se produce a partir de) un conjunto de esquemas GraphQL . Dado que mucho se basa en el esquema, debe asegurarse de que sea de alta calidad. Esa es tanto la parte de la estructura como la parte semántica del significado de los datos.

También está buscando servidores que produzcan datos de muchas fuentes diferentes, heredadas o nuevas. Cualquiera que sea el tipo de fuente, puede haber problemas de calidad. La basura que entra es igual a la basura que sale . Por esa razón, el diseño de la API GraphQL puede hacer que tenga que resolver problemas de unificación y descubrimiento de datos, como la calidad , los metadatos y la aceptación comercial . Esta es la “parte del significado” y volveremos a eso más adelante en este artículo.

Visualice la estructura con gráficos de propiedades

El esquema es un gráfico de datos que contiene conceptos relacionados en una red organizada como un gráfico dirigido. En cierto modo, se podría decir que el enfoque GraphQL hace que todo parezca un gráfico. (Que es realmente el caso, de todos modos).

Esto hace que el enfoque de gráficos de propiedades para la visualización de gráficos sea una oportunidad poderosa para el diseñador de esquemas GraphQL. Aquí hay un gráfico de propiedad representado:

gráfico de propiedad de muestra

Formato de mensaje de Internet representado como un gráfico de propiedad

Los círculos son conceptos , que son los nodos del gráfico. Un Mensaje, por ejemplo, es un concepto, y es parte de varias relaciones , como “originador” (quien envió el mensaje) o “en respuesta a” (a qué otro mensaje es este en respuesta). Las propiedades se pueden adjuntar a conceptos (nodos) y / o relaciones (bordes del gráfico).

La notación utiliza puntas de flecha para cardinalidades. En el diagrama, encontrará relaciones de uno a uno, de uno a muchos y de muchos a muchos. Aquí hay una breve explicación de los gráficos de  propiedades .

En el contexto GraphQL , el gráfico de propiedades es útil para representar la estructura del esquema:

  • Los nodos son tipos (tipos de objeto, tipos de interfaz y tipos de unión)
  • Las relaciones representan las conexiones entre tipos
  • Las propiedades son los campos de los tipos (escalares o listas)

Aquí está el tipo de mensaje con sus propiedades y relaciones en GraphQL:

type Message {
  id: ID!
  subject: String
  comments: String
  originator: Originator! @relation(name: "Originator")
  destinations: [Destination]! @relation(name: "HasDestination")
  referencing: [Message] @relation(name: "Referencing")
  in_reply_to: [Message] @relation(name: "InReplyTo")
  keywords: [Keyword] @relation(name: "Tags")
}

Tenga en cuenta que en los gráficos de propiedades, las relaciones se nombran . Esto es importante, porque esos nombres forman parte de la semántica empresarial y, al visualizarlos, es mucho más fácil revisar y discutir el significado que impone la estructura. En el ejemplo, Graphcool ‘s @relation directiva se utiliza para obtener los nombres de las relaciones en el esquema.

La representación del gráfico de propiedades es considerablemente más compacta que los "cuadros y flechas" que se encuentran en la mayoría de los enfoques de diagramación. En el espacio GraphQL, hay una herramienta llamada GraphQL Voyager . La Voyager se basa en una biblioteca de diagramas estándar, que se muestra en el estilo de "cuadros y flechas". Conseguir un agarre sólido de la estructura en, digamos, 5 u 8 tipos de objetos no es fácil.

La representación del gráfico de propiedades es más compacta y ha tenido éxito durante los últimos 15 años, y proviene de los países nórdicos. Neo4J , con sede en Malmö, inventó el modelo de gráfico de propiedades como modelo de datos y ahora es un actor líder en el segmento de bases de datos de gráficos en todo el mundo.

En este punto, nos hemos ocupado de la visualización de esquemas, y eso hace que GraphQL sea bonito y bueno:

  • Alineación con la terminología y las definiciones comerciales (campos de estructura y contenido)
  • Entender esquemas complejos, estructurados como gráficos

Una mirada más profunda a los gráficos de propiedades aplicados a GraphQL

Las consultas y sus resultados utilizan el mismo nombre, etc. que en el esquema, y ​​los datos resultantes están estructurados como estructuras de árbol jerárquicas , que también se pueden representar como gráficos de propiedades. Un escenario: supongamos que se necesita un resultado de consulta, que tiene su raíz en el originador. Lo primero que debe hacer es transformar un poco el gráfico de propiedades del esquema para que tenga el Originador en la parte superior:

Originador en la parte superior

Gráfico de propiedades editado con el originador en la parte superior.

A partir de eso, es fácil comprender que el conjunto de resultados podría verse así:

Conjunto resultante

Tenga en cuenta que el gráfico que se muestra arriba también es un gráfico de propiedades, ahora solo una versión "bonzai" de una parte (estructurada en árbol) del gráfico de esquema, y ​​una retorcida, además.

Los gráficos de propiedades son claramente muy relevantes para los desarrolladores de GraphQL. Facilitan significativamente el análisis de los datos disponibles y ayudan a organizar el esquema API resultante y las estructuras de consulta. Hecho esto, también nos hemos ocupado de:

  • Exposición correcta de la estructura de las relaciones inherentes a los datos expuestos (resultado de la consulta)
  • Manejo de recorridos de relaciones de muchos a muchos para producir un árbol de resultados (tanto el esquema como el resultado de la consulta).

La visualización es una representación intuitivamente comprensible (bastante buena) de la terminología empresarial y de las aplicaciones que se puede discutir con los empresarios.

Lidiar con el significado y el contenido

Obtener la semántica correcta

La calidad del contenido de los resultados de la API depende de la semántica empresarial y de los datos reales entregados por la API. Ya tratamos con la estructura y la terminología en los gráficos de propiedades anteriores, por lo que ahora necesitamos manejar el contenido de los datos reales correctamente.

Sin embargo, recuerde que el significado y el contenido van de la mano. Si cambia la semántica, es posible que deba refactorizar los datos.

10 consejos para embellecer el contenido de datos de gráficos

En cuanto a los problemas de unificación y descubrimiento de datos, hay (demasiada) información al respecto en Internet y en libros (incluidos dos de los míos). En el contexto GraphQL, debe estar atento a estos 10 temas más importantes:

  • Incluir nombres comerciales en la API
  • Identidad y singularidad
  • Presentando las llaves
  • Presentando cambios de estado
  • Presentar versiones de datos
  • Presentando fechas y horas
  • Presentar relaciones y referencias faltantes
  • Qué objetos y qué relaciones
  • Presentando el nivel correcto de detalle
  • Buenas relaciones

La cantidad de trabajo que se necesita en el lado del solucionador realmente depende de los problemas, que en parte están fuera de su control:

  • La calidad de las fuentes de datos por sí mismas (estructura, significado y contenido)
  • Conflictos derivados de la unificación de datos de múltiples fuentes (tanto ascendentes como descendentes)

Echemos un vistazo breve a los 10 problemas más importantes para hacer que el contenido de datos sea bonito y listo para usar:

  • Incluir nombres comerciales en la API : posibles conflictos de nombres. Utilice los gráficos de propiedades para alinear su negocio.
  • Identidad y singularidad : la singularidad son las reglas de nivel empresarial para la determinación de la singularidad de la instancia de datos. Con frecuencia, se trata de una combinación de "claves" de nivel empresarial, como número de seguro social, número de empleado, código postal, número de producto, etc.
    Identidades el resultado combinado de la singularidad de los tipos participantes. Una línea de pedido, por ejemplo, es única para la combinación de número de pedido (del tipo de pedido) y número de línea de pedido (del tipo de línea de pedido). En la mayoría de los sistemas de TI, la identidad se garantiza mediante un campo de identificación único (la clave principal en las bases de datos relacionales) u otros tipos de claves sustitutas. Obviamente, los conflictos de ID en múltiples bases de datos de origen deben resolverse. También tenga en cuenta que los requisitos posteriores de los datos de la API GraphQL pueden establecer requisitos distintos para la entrega de identidad y unicidad de la API.
  • Presentación de las claves : si los campos de identidad de ID adecuados no están disponibles, tal vez la capa de resolución debería encargarse de eso. En la mayoría de los casos, se necesitan en la API.
  • Presentación de cambios de estado : muchos tipos de objetos comerciales pasan por una secuencia de estados a lo largo de sus ciclos de vida. Se debe tener cuidado al planificar si un cambio de estado es solo un cambio de una propiedad, o si debe generar una nueva identidad.
  • Presentación de versiones de datos : también vale la pena considerar el control de versiones del contenido de datos. ¿Se deben versionar los datos (puede ser un requisito comercial, sobre todo en el sector financiero)? ¿Cómo se debe presentar el control de versiones? ¿Al menos una fecha y tal vez también una bandera de "Última versión" por conveniencia?
  • Presentación de fechas y horas : la fecha y la hora no son actualmente tipos de datos escalares en GraphQL. Depende de usted utilizar tipos definidos por el usuario. Eche un vistazo al proyecto GraphQL ISO Date en Github.
  • Presentar relaciones y referencias faltantes : esta es una consideración clásica sobre "NULL" o no. GraphQL admite NULL, por lo que puede usar eso. También puede utilizar valores predeterminados como "Desconocido" o similares.
  • Qué objetos y qué relaciones : No siempre se le ofrecen los tipos de objetos correctos y las relaciones correctas en las fuentes de datos. Es posible que deba ser selectivo y es posible que deba transformar y / o generalizar algunos de los datos expuestos.
  • Presentar el nivel correcto de detalle : relacionado con lo anterior, asegúrese de seleccionar el nivel correcto de abstracción en toda la interfaz. ¿Quién hace las agregaciones? ¿El resolutor o la aplicación?
  • Buenas relaciones : relacionadas con lo anterior, asegúrese de representar bien las relaciones. Tenga cuidado con la información que reside en una relación. No puede hacer eso en GraphQL, por lo que es posible que deba inventar un nuevo tipo de objeto para ese propósito. Lo mismo ocurre con muchos a muchos. Tenga cuidado cuando los recorra en las consultas. Si el esquema no es correcto, o si los datos tienen redundancias, corre el riesgo de crear productos cartesianos y "consultas del infierno".

Pensamientos finales

El enfoque GraphQL tiene muchos beneficios que los profesionales de datos experimentados admirarán. Tiene un buen potencial de ser algo duradero; Los conjuntos de resultados estructurados y autodescriptivos son buenos para todos. Las tecnologías heredadas para interactuar con los datos eran tan buenas como podían en el momento en que surgieron, pero eso no es lo suficientemente bueno hoy. GraphQL es todavía joven, pero está madurando, y todos podrían beneficiarse de tener visualizaciones de gráficos allí. ¡Lo mismo ocurre con una versión visual e interactiva de GraphIQL, para usuarios finales!

Ah, y recuerde: la información se basa en la confianza, y si los empresarios no confían o no comprenden los datos que se les presentan, ¡dejarán de usarlos!

Esté preparado para hacer el trabajo adicional, si es necesario, según las circunstancias. Asegúrate de que lo que ofreces sea visual y bonito. Entonces, ya puedes irte.

Publicar un comentario

0 Comentarios