Explorando el Data Mesh impulsado por GraphQL

Rate this content
Bookmark

Se están explorando diferentes enfoques para construir un lago de datos operativo con una API de acceso a datos fácil, así como una API de acceso a datos federada, y GraphQL abre oportunidades para habilitar estas arquitecturas al sentar las bases para un data mesh.

34 min
08 Dec, 2022

Video Summary and Transcription

Esta Charla discute los desafíos de trabajar con APIs de datos y GraphQL, incluyendo la estandarización, el rendimiento y la seguridad. Se enfatiza la necesidad de optimizar las recuperaciones de datos y empujar la lógica de autorización hacia abajo. Se explora el concepto de externalizar la autorización y utilizar un motor de GraphQL. La Charla también cubre la generación de esquemas y APIs de GraphQL, así como la implementación de seguridad a nivel de nodo. En general, el enfoque se centra en diseñar y estandarizar GraphQL para APIs de datos mientras se abordan los desafíos de autorización.

Available in English

1. Introducción a las API de datos y GraphQL

Short description:

En esta parte, Tanmay habla sobre la necesidad de una capa de API de datos para abordar los desafíos de trabajar con diferentes fuentes de datos y clientes. Destaca los beneficios de GraphQL en la selección y estructuración de datos, pero también reconoce los desafíos de estandarización, rendimiento y seguridad. Tanmay explica cómo la optimización del rendimiento puede variar según las fuentes de datos y comparte ejemplos de planes de consulta. También menciona la discusión en torno al problema N más uno en GraphQL.

Hola, amigos. Soy Tanmay, soy el cofundador y CEO de Hustler. Y voy a hablarles un poco sobre las API de datos impulsadas por GraphQL hoy. Entonces, cada vez más equipos de plataforma en diversas organizaciones están estableciendo una capa de API de datos para lidiar con este problema de tener tantas fuentes de datos diferentes y tantos tipos de clientes. Y necesitamos resolver problemas de rendimiento, estandarización y seguridad para permitir que estos clientes se muevan rápidamente. Tenemos que lidiar con el hecho de que estos datos, los datos del dominio, provienen de diferentes fuentes, bases de datos, servicios. Los clientes pueden ser internos o externos, pueden estar en el borde, pueden estar en la nube, pueden estar en las instalaciones, pueden estar dentro del mismo equipo, pueden estar en diferentes equipos. Y necesitamos una capa de API de datos que pueda absorber y resolver la estandarización de la API o proporcionar un cierto nivel de rendimiento o garantizar el cumplimiento de la seguridad. Como API de datos, GraphQL puede ser una gran opción y veremos algunos de los beneficios de GraphQL para abordar algunos de estos desafíos también. Entonces, GraphQL es una API agradable porque, como todos sabemos, nos permite seleccionar exactamente los datos que necesitamos en una sola llamada a la API. Esto tiene un impacto bastante grande si la cantidad de datos que estamos obteniendo son modelos que tienen cientos de atributos, donde podemos reducir drásticamente la carga en el sistema de datos subyacente. Cada vez más, a medida que nos movemos hacia centros sin servidor y centros de datos sin servidor, hay un impacto masivo en el ahorro de costos que también ocurre cuando podemos seleccionar exactamente los datos que necesitamos. Todos sabemos que GraphQL tiene un esquema realmente agradable y tenemos un tipo de gráfico que nos permite seleccionar exactamente la forma en que estamos obteniendo nuestra salida, pero también nos permite estructurar nuestra entrada y nuestros parámetros de manera bastante fácil. ¿Verdad? Y eso tiene un impacto en nuestra capacidad para manejar la creciente complejidad. Cuando pensamos en esta consulta aquí, cuando estoy obteniendo pedidos, estoy obteniendo pedidos donde el usuario es mayor que un valor particular en él, ordenado por el ID de usuario en orden ascendente. Proporcionar estos parámetros de entrada y argumentos es mucho más fácil con GraphQL en comparación con tratar de hacer esto con una API REST, por ejemplo. ¿Verdad? Y poder agregar esta complejidad se vuelve mucho más fácil. Cuando pensamos en tomar estas comodidades de GraphQL de las que todos somos conscientes y pensamos en estandarizar y escalar esto, nos encontramos con algunos desafíos en su núcleo. Es porque el costo de proporcionar esta flexibilidad aumentada significa que necesitamos hacer un poco más de trabajo para resolver la estandarización o el diseño del esquema y garantizar el rendimiento y resolver la autorización y la seguridad, ¿verdad? Echemos un vistazo al rendimiento, por ejemplo. Si pensamos en los tipos de fuentes de datos que tenemos y la forma en que ejecutamos una consulta en esas fuentes de datos, esa obtención óptima de datos que hacemos puede ser muy contextual. Si tomamos un ejemplo simple de obtener pedidos y el usuario para cada pedido, el nombre de usuario. Dependiendo de la topología de estos datos, podríamos tener planes de consulta variables. Por ejemplo, si proviene de la misma fuente de datos que admite la agregación JSON, si tuviera que implementar un controlador que resultara y respondiera solo con estos datos, podría hacer una sola consulta que realizaría la agregación JSON en la fuente de datos misma. Eso significa que ni siquiera estoy haciendo una unión que obtiene un producto cartesiano, estoy haciendo una consulta más eficiente que obtiene solo el pedido, el usuario está construyendo el envío, el JSON, y luego lo envía de vuelta al cliente. Digamos que proviene de dos bases de datos diferentes, en cuyo caso usaría algo como una consulta y realizaría una memorización, para no obtener entidades duplicadas en esta unión de bases de datos cruzadas. Si esto viniera de dos servicios diferentes, entonces tendría que hacer múltiples llamadas a la API, pero nuevamente, haría una forma de memorización para evitar que se obtengan entidades duplicadas dentro de la misma solicitud. Es una variación del patrón de datos. Pero la idea es que este plan de consulta depende del tipo de datos que tenemos y el mismo plan de consulta no funcionará en estas diferentes fuentes de datos. Hubo un hilo interesante que surgió en Twitter hace unas semanas, donde hablamos sobre cómo GraphQL no crea un problema N más uno, y Nick, uno de los creadores de GraphQL, comentó que, bueno, GraphQL no crea el problema N más uno. Pero debido a la forma en que normalmente pensamos en ejecutar una consulta de GraphQL, se vuelve más difícil abordar ese problema de manera

2. Desafíos de la obtención de datos y autorización

Short description:

En esta parte, Tanmay analiza los desafíos de integrar la reducción de predicados con la obtención de datos y la necesidad de empujar la lógica de autorización. Él enfatiza la importancia de optimizar la obtención de datos y explica los desafíos de hacer esto en diferentes fuentes de datos.

de manera sistemática. Y eso es más o menos lo que analizamos, y vemos cómo podemos abordar esos tipos de desafíos. Y pensamos en la autorización. Un desafío muy común es que tenemos que integrar la reducción de predicados junto con nuestra obtención de data. Nuevamente, si observamos la misma consulta donde estamos obteniendo pedidos de usuario, y digamos que esta consulta es realizada por un gerente regional que solo puede obtener pedidos realizados dentro de la región, dentro de su región. Y si hacemos una solicitud ingenua donde seleccionamos todos estos data, y luego filtramos por región, sería terrible. Obviamente no podemos hacer esto cuando tenemos millones o miles de millones de filas. Y lo que no queremos hacer es obtener esa data o seleccionar de pedidos, del modelo o tabla de pedidos o lo que sea, donde la región sea igual a la región actual. Este es el predicado y nuevamente, empujando ese predicado en nuestra obtención de data, ¿verdad? Y queremos poder empujar nuestra lógica de autorización con nuestra obtención de data tanto como sea posible. Hacer esto en diferentes fuentes de datos puede resultar desafiante, ¿verdad? Cuando pensamos en el diseño de la API, y a medida que comenzamos a aprender sobre cargas de trabajo más complicadas, quiero decir, piensa en la agregación o el filtrado complejo, o qué tipo de patrón queremos seguir para

3. Desafíos del Diseño de API de Datos

Short description:

Esta sección analiza los desafíos del diseño estandarizado al tratar con la obtención de datos, mutaciones y planificación de consultas en una API de datos. Destaca los beneficios de una mejor planificación de consultas y las mejoras de rendimiento que puede ofrecer. También aborda la necesidad de externalizar la lógica de autorización y las ventajas que conlleva. Los ejemplos proporcionados demuestran la importancia de una base técnica rigurosa en el diseño de API de datos.

mutaciones. Esto también puede ser algo en lo que debemos pensar de manera estandarizada, veamos algunos ejemplos de dónde surgen estos desafíos. Si pensamos en la obtención de datos, por ejemplo, la cantidad total de pedidos que tiene cada usuario, ¿verdad? Hay una propiedad agregada que se agrega al paquete de usuario. ¿Y cómo queremos pensar en esto? ¿Queremos agregar esto como un atributo al tipo de usuario, que es lo que haríamos convencionalmente, pero qué pasa si queremos tener ciertos argumentos para eso, para que solo obtengas esas agregaciones con una condición particular? Como solo pedidos creados o qué pasa si quieres agregar otras propiedades agregadas? ¿Qué pasa si el servicio de pedidos es un servicio totalmente diferente al servicio de usuario, ¿verdad? ¿Cómo queremos exponer las agregaciones de un servicio diferente que se está federando en una definición de modelo que proviene de un servicio completamente diferente, ¿verdad? Entonces, necesitamos una forma de pensar en el design aquí. Cuando pensamos en consultar un padre por una propiedad del hijo, ¿verdad? No es una propiedad del padre, sino una propiedad del hijo. Nuevamente, en situaciones donde esto está federado, se convierte en algo complicado de design. Y queremos tener un design estandarizado cuando pensamos en lidiar con este tipo de cargas de trabajo también. Cuando pensamos en mutaciones, tenemos dos tipos principales de mutaciones, ¿verdad? Podemos hacer este estilo Kradesh de mutaciones. Y eso es bueno porque se pueden componer bien. Puedes decir que estoy insertando un objeto y un montón de objetos relacionados juntos. O los estoy actualizando o insertando o eliminando y cosas así. O podemos pensar en un estilo no Kradesh, donde es más estilo CQR de mutación, donde tienes una mutación única para cada tipo de acción que quieres hacer. Y aunque esto es bueno, dificulta la estandarización. ¿Verdad? Entonces, quieres poder manejar bien ambos estilos. Entonces, si pensamos en abordar estos desafíos, dado que de todos modos lo haremos, cuando pensemos en una API de datos, veamos qué beneficios obtendríamos de una base técnica más rigurosa, ¿verdad? Entonces, veamos qué sucedería si tuviéramos una mejor planificación de consultas. Entonces, este conjunto de ejemplos, voy a seguir usando este ejemplo de e-commerce, donde tengo usuarios y pedidos y un servicio de logística, ¿verdad? Entonces, usamos un servicio, un servicio de pedidos y un servicio de logística, y el modelo de usuario tiene pedidos y artículos. Y el seguimiento de pedidos es como una llamada de API que realiza una lógica empresarial para interactuar con una API de FedEx o una API de UPF para obtener el estado del pedido. Si observo una consulta simple como obtener pedidos y el usuario para ese pedido, dependiendo de cómo se organice esa data, podría tener tres tipos diferentes de plan de consulta. Podría tener este buen plan donde hago n más uno. Tengo una sobrecarga de serialización, deserialización, podría hacer una agrupación donde sea posible agrupar. Y es como un cargador de data, donde tengo que hacer al menos dos llamadas de E/S. Y luego realizar la serialización y deserialización de JSON. O en el mejor de los casos, donde esta data se organiza de tal manera que puedo hacer una sola llamada. Y luego la serialización y deserialización de JSON solo en un lugar y enviarla de vuelta, ¿verdad? Y lo que hablamos, cuando pensamos en el beneficio de este plan de consulta, ¿verdad? Y vemos cómo se ve esto en la práctica, haciendo pruebas de rendimiento a aproximadamente 1000 RPS, aumentando la profundidad de obtención de data que proviene de dos servicios diferentes. Si observamos este enfoque, donde permitimos que ocurra una mejor planificación de consultas y no solo nos quedamos con un estilo de cargador de data más uno, es una gran cantidad de ganancia de performance que podemos obtener. ¿Verdad? Puedes ver que el azul es donde hay una planificación de consultas. Y el rojo es donde solo tengo un gateway de GraphQL que se está federando a dos servicios diferentes de GraphQL que han estado obteniendo de esas fuentes subyacentes, ¿verdad? Los beneficios se acumulan donde estoy obteniendo solo la parte correcta de data de la database subyacente, donde estoy realizando la cantidad mínima de serialización repetida de JSON y finalmente llegando a la forma de data que quiero tener. Cuando pensamos en el beneficio que queremos en el lado de la autorización, veamos un ejemplo donde tenemos esta API de Trap Order, ¿verdad? Donde estoy obteniendo información sobre el estado de entrega o el estado del pedido para un ID de pedido en particular. Ahora, típicamente, si quisieras tener lógica de autorización que garantice que cuando estoy realizando el pedido, solo estoy viendo el pedido que puedo ver como usuario, el pedido me pertenece. Lo que tendríamos que hacer es empujar esa lógica de autorización y pedir a las personas que han implementado la función de Trap Order que implementen esa lógica de autorización, ¿verdad? Entonces, lo que haría hoy es que en la lógica o en el controlador que realiza el Trap Order, quiero obtener la información del pedido, obtener la información del usuario de eso, obtener la información del usuario que está relacionada con ese pedido, y luego verificar una condición sobre la sesión actual y cómo está relacionada con el pedido y cómo se usa ese pedido. Y luego, dependiendo de esa condición, lo validaría y haría una llamada de API al servicio de logística real y haría cualquier lógica empresarial que se necesite para devolver ese estado del pedido, ¿verdad? Me gustaría poder externalizar esta lógica de autorización en naranja, ¿verdad? Porque estamos haciendo este recorrido de gráficos donde decimos si el input.order.user es el usuario actual, ¿verdad? Alguna condición así, me gustaría evaluar esa condición y luego hacer

4. Lógica de Autorización y Motor de GraphQL

Short description:

Esta parte analiza la necesidad de externalizar la lógica de autorización y los beneficios de centralizar la autorización. Explora la idea de predicados y agregaciones en la inversión de gráficos y la importancia de evaluar predicados relacionados. El texto también introduce el concepto de desacoplar la sintaxis y la semántica de una API de GraphQL de su ejecución mediante el uso de un motor de GraphQL. El motor utiliza un gráfico de dominio y permite componer funciones de predicado y agregación. Puede planificar consultas y obtener datos del gráfico de dominio, proporcionando un esquema de GraphQL derivado de él. El enfoque se centra en acceder al dominio a través de la API de GraphQL en lugar de tratar la API como el propio dominio.

Luego validaría y haría una llamada a la API al servicio de logística real y haría cualquier lógica empresarial que se necesite para devolver ese estado del pedido, ¿verdad? Me gustaría poder externalizar esta lógica de autorización en naranja, ¿verdad? Porque estamos haciendo este recorrido de gráficos donde decimos si el input.order.user es el usuario actual, ¿verdad? Alguna condición así, me gustaría evaluar esa condición y luego hacer que ocurra esta lógica empresarial. Puedes pensar en escenarios más complejos donde tengo múltiples consultas y tengo verificaciones de autorización repetidas. Es como hacer esta cosa de obtención de datos y inversión de gráficos que vimos en el acceso a datos básico, pero también lo estamos haciendo para la autorización también. Y los mismos beneficios que queremos en el acceso a datos, podemos comenzar a obtener esos beneficios también en la autorización. Además del hecho, por supuesto, de que ahora podemos centralizar la autorización y garantizar un grado de security y cumplimiento, la capa de API de datos en sí a través de diferentes tipos de fuentes de datos. Entonces, cuando piensas en lo que impulsa esto, una de las ideas clave que impulsa esto es la idea de predicados y agregaciones que componen la inversión de gráficos. Tomemos este ejemplo de cuando obtengo usuarios y pedidos, ¿verdad? Y si quiero hacer una consulta que obtenga un pedido donde la región del usuario sea igual a un valor particular, aquí es donde traigo una propiedad del hijo y puedo llevar esa propiedad del hijo al padre, y luego puedo evaluar un predicado en el hijo para el padre. Y no se trata solo de la sintaxis que queremos en el lado de la API de GraphQL, sino que también queremos que nuestro motor de API de datos pueda evaluar estos predicados relacionados y empujarlos hacia abajo en las fuentes de datos subyacentes siempre que sea posible. Este es un código interesante de escribir incluso si los datos estuvieran en el mismo lugar y obviamente es muy interesante pensarlo como proveniente de dos fuentes de datos diferentes, dos servicios diferentes. Y esto es lo que queremos poder hacer. Muy bien. Entonces, ¿cómo lo haríamos? Y eso será la segunda mitad de lo que hablo hoy. El primer problema aquí, o la idea clave aquí es que queremos asegurarnos de que la información correcta esté disponible en el nivel correcto. Mencioné formas de hacer GraphQL y ejecutar una consulta de GraphQL. Acopló el modelo de ejecución a la consulta de GraphQL y la estructura del esquema de GraphQL. Por ejemplo, estamos obligados a cuando estamos atendiendo una consulta que obtiene pedidos y usuarios y cosas así, estamos haciendo una inversión en anchura y estamos llamando a estas funciones de resolución de esa manera de anchura primero que está mirando la consulta de GraphQL y luego estamos ejecutando la lógica allí, ¿verdad? Cuando estamos obligados a escribir nuestra lógica de esa manera particular, entonces necesitamos una capa de datos que pueda comprender esas cosas. Y esto es muy desafiante de escribir porque genera una capa de datos en estos servicios de datos que se vuelve desafiante, ¿verdad? Piensa en todos los problemas de los que estábamos hablando. Lo que queremos hacer en cambio es pensar en desacoplar la sintaxis y la semántica de nuestra API de GraphQL de cómo se ejecuta. Pasamos de esta idea de servidor de GraphQL a un motor de GraphQL, ¿verdad? Y el motor de GraphQL utiliza un gráfico de dominio, no el esquema de GraphQL. Utiliza una descripción del dominio y una descripción de las políticas de security en ese dominio, etc., y cómo eso es suficiente para las fuentes de datos en línea. Permite una cierta forma de componer funciones de predicado y funciones de agregación. Y puede hacer esa planificación de consultas para obtener datos de ese gráfico de dominio. Y luego, sobre eso, expone un esquema de GraphQL que se deriva de ese gráfico de dominio. Pero cómo se procesa una consulta de GraphQL en particular se deja completamente al motor de GraphQL, ¿verdad? Ya sea, por ejemplo, que vaya a realizar múltiples llamadas a la API o que lo compile en una sola consulta. Esa ejecución queda en manos del motor de GraphQL. Y no estamos pensando en esto desde este punto de vista de llamar a una función de GraphQL, ¿verdad? Otra forma de pensar en esto es que es como GraphQL sin resolvers, ¿verdad? Supongo que el modelo mental al que estoy tratando de llegar aquí es decir que si tienes que construir, si tienes que pensar en tu servidor de GraphQL como llamar a una función de GraphQL, ¿verdad? Y ejecutar esa función de GraphQL, cuando llamas a una API de GraphQL, en lugar de eso, ¿qué tal si pasamos a este modelo de decir, bueno, tenemos un gráfico de nuestro dominio, y lo estamos poniendo accesible a través de una API de GraphQL. Entonces nos estamos enfocando más en el dominio, y estamos usando la API de GraphQL como una forma de acceder a ese dominio, en lugar de pensar en la API de GraphQL como nuestro dominio. Así que veamos cómo puede verse esta especificación. Miramos, ya sabes, miramos GraphQL, miramos el nivel de seguridad por fila, miramos las bases de datos de gráficos, miramos el álgebra relacional y cómo funciona la composición. Técnicas como los envoltorios de datos externos que tienen sistemas como Postgres, que ayudan a integrar diferentes tipos de sistemas en un sistema relacional.

5. Especificación de Datos de GraphQL y Gráfico de Dominio

Short description:

Podemos describir una especificación de datos de GraphQL que consta de una descripción del gráfico de dominio, seguridad a nivel de nodo y convenciones para generar el esquema y la API de GraphQL. El gráfico de dominio describe modelos, campos, aristas y comandos que el motor de GraphQL puede interpretar. En el ejemplo de comercio electrónico, el gráfico representa nodos conectados y comandos que operan en el gráfico. El motor de GraphQL puede evaluar predicados y realizar agregaciones en los nodos. Las funciones de predicado permiten la evaluación de propiedades en modelos, incluyendo el recorrido de aristas y la composición de expresiones booleanas. Esto permite evaluaciones complejas en el gráfico de dominio.

Al observar todo esto, podemos describir una especificación de datos de GraphQL que se compone de tres partes. La primera es la descripción del gráfico de dominio, que describe los modelos, aristas y comandos que forman parte de ese gráfico de dominio y provienen de diferentes fuentes de datos. Luego tenemos la noción de seguridad a nivel de nodo. Es un lenguaje de autorización y un marco de políticas que permite validar, restringir o filtrar los nodos de ese gráfico de dominio. Y finalmente, tenemos convenciones y una gramática particular para generar el esquema y la API de GraphQL a partir del gráfico de dominio subyacente, incorporando estas reglas de seguridad a nivel de nodo. ¿Correcto? Así que echemos un vistazo a cómo se ve el gráfico de dominio. Este lenguaje está destinado a describir los modelos, los campos y las aristas en el dominio. Describe comandos que pueden tomar un modelo como entrada y devolver un modelo como salida, ¿verdad? Y el motor de GraphQL puede interpretar este gráfico de dominio. Debe proporcionar funciones de predicado y funciones de agregación, funciones de paginación, y cosas así que pueden operar en ese gráfico superior. ¿Correcto?

Echemos un vistazo a cómo se ve esto con el ejemplo de comercio electrónico, ¿verdad? Y visualicémoslo. Así que si observas este gráfico de modelos, tenemos estos nodos que están conectados entre sí. Y tenemos comandos que toman un gráfico como entrada y devuelven esto como un gráfico como salida. Esto se convierte en la entrada de un motor de GraphQL que ahora puede evaluar predicados en estos nodos, ¿verdad? Y puede decir que, eh, aquí hay una expresión particular donde queremos evaluar un nodo, recorrer el gráfico y evaluar una propiedad como falsa. Queremos poder evaluar agregaciones en conjuntos de nodos, ¿verdad? Y el motor de GraphQL debe saber cómo seleccionar, transmitir, insertar, eliminar, actualizar o invocar comandos en ese gráfico en particular. Esto es lo que el motor de GraphQL debería poder hacer, dado esta entrada.

Si observas el ejemplo específico de la lista de comercio electrónico, ¿verdad? Teníamos una fuente de datos donde tenemos un modelo para un usuario que tiene un ID, un nombre y una arista a los pedidos. Tenemos pedidos que tienen ID, cantidad, ID de usuario, como campos y una arista de regreso al usuario y una arista a los artículos, que luego tiene la descripción del artículo y cosas así, ¿verdad? Tenemos la llamada de API para rastrear el pedido, donde hay un modelo de entrada que toma un ID de pedido, y verás que tiene una arista al propio modelo de pedido. Y ves el modelo de salida aquí, que es el estado del pedido, que tiene descripción, estado y cosas así, pero también una arista al modelo de pedido, ¿verdad? Ves este comando que puede tomar un modelo de entrada, que toma una entrada y devuelve una salida particular. Así es como queremos que nuestro dominio se mapee a un gráfico, ¿verdad? Un conjunto de modelos y aristas. Ahora, la parte clave de esto son las funciones de predicado, que realmente hacen que la compilación ocurra. Tan pronto como tenemos un modelo de usuario, queremos generar una función de predicado que pueda evaluar propiedades en el modelo de usuario. Podemos hacer operaciones booleanas, podemos tener un ID, el ID se puede comparar con un valor con ciertos operadores enteros, operadores de cadena, operadores de cadena de región. Pero cuando vemos una arista al pedido desde el modelo de usuario, también podemos recorrer la expresión booleana del pedido. Y también podemos recorrer una expresión booleana de agregación de pedidos. Esto es lo que nos permite decir cosas como, ya sabes, donde el usuario.total_pedidos es mayor que 10. ¿Correcto? Y así puedes crear o evaluar una propiedad del modelo de usuario componiendo entidades relacionadas también. De manera similar, en el lado del pedido, puedes hacer lo mismo donde tienes expresiones booleanas en esos campos en sí. Pero también puedes componer expresiones booleanas de las aristas, ¿verdad? Y esto es lo que nos permite tener funciones como usuario.agregado_pedido.concreto y cinco, o pedido.usuario.region es igual a no correo electrónico médico, o algo así, ¿verdad? Y esto es lo que permite esta evaluación.

6. Seguridad a Nivel de Nodo en la Especificación de la API de Datos

Short description:

Esta parte discute la implementación de la seguridad a nivel de nodo en la especificación de la API de datos. Explica cómo se utilizan las políticas de permisos y los predicados de restricción para controlar el acceso a diferentes modelos y nodos en el gráfico. Se utiliza el ejemplo de un sistema de comercio electrónico para ilustrar cómo se pueden aplicar reglas de seguridad a nivel de nodo a los modelos de usuario, los elementos de pedido y las llamadas de API de seguimiento de pedidos. También se introduce el concepto de crear un subgrafo con atributos y nodos accesibles.

para que esto suceda. Esto es lo que, como puedes ver, se mostrará en nuestro filtrado o en nuestras reglas de seguridad a nivel de nodo y cosas así se mostrarán en el argumento para una API de Rockwell y cosas así. Pasando a la seguridad a nivel de nodo, que es la segunda parte de esta especificación. Para cada modelo, podemos adjuntar una política de permisos, ¿verdad, y esa política decide qué atributos de ese modelo son accesibles, ya sabes, y un predicado de restricción que debe cumplirse para filtrar o validar este nodo en particular cuando se accede a él, ¿verdad?

Puedes modelar reglas de tipo permitir y denegar como operadores and, or y not, puedes tener múltiples políticas y puedes definir cómo quieres que se combinen varias políticas, ¿verdad? Así que puedes seleccionar partes superpuestas del gráfico, seleccionar las piezas correctas de datos de partes superpuestas del gráfico, y cosas así. Nuevamente, dando un paso atrás para ver cómo se ve esto en nuestro ejemplo de comercio electrónico, ¿verdad? En el modelo de usuario, tendríamos una regla de seguridad a nivel de nodo que dice que si el user.id es igual al id de usuario de la sesión actual, debería poder acceder a él, ¿verdad? Si miramos los elementos de pedido, puedo acceder a un elemento de pedido si ese pedido realmente me pertenece, por lo que item.order.userid es igual a mí. Si observamos nuestra llamada de API de seguimiento de pedidos, el modelo de entrada también puede recorrer la arista. Así que puedo decir que el input.order.userid debe ser igual al id de usuario de la sesión actual, por lo que puedo recorrer las entradas en el gráfico también, ¿verdad, y luego validar eso y verificar si hay ciertas cosas que están permitidas, por ejemplo, o si esos datos se pueden devolver como respuesta de ese comando, ¿verdad? Si visualizas esto desde el punto de vista del gráfico, se siente como si tuvieras este gráfico de modelo y una regla de NLS, esencialmente, una política de NLS te permite crear un subgrafo con ciertos atributos y ciertos nodos que son accesibles, ¿verdad? Si observas un comando, estás viendo que el gráfico de entrada debe validarse, que este gráfico realmente está permitido existir para este comando y luego la salida se filtra para que tengas la respuesta correcta que puedes ver al ejecutarlo.

7. Generación de Esquema y API de GraphQL

Short description:

Tenemos convenciones para generar el esquema y la API de datos de GraphQL, lo que permite obtener modelos y realizar agregaciones. Las mutaciones permiten operaciones CRUD e invocar comandos. Los beneficios incluyen un mejor rendimiento, capacidad para componer y diseñar la API, externalizar reglas de autorización y crear una capa de seguridad estandarizada. Además, la técnica se puede utilizar para construir una API de caché de datos automatizada.

ese comando, ¿verdad, y eso es más o menos lo que parece la seguridad a nivel de nodo. Finalmente, basado en estas dos cosas, tenemos convenciones para generar el esquema y la API de datos de GraphQL, ¿verdad, por ejemplo, tienes la raíz de consulta que te permite obtener modelos en sus aristas con la función de predicado, ¿verdad, por lo que puedes filtrar, puedes obtener agregaciones en listas o en listas relacionadas que te permite hacer agregaciones de usuarios y usuarios.pedido, por lo que puedes calcular usuarios, pero el promedio del monto del pedido y el número total de pedidos y cosas así o el número promedio de elementos en el pedido único y eso se puede componer bien en una sintaxis de consulta. En las mutaciones, si estás en el lado CRUD, tienes inserción, actualización, eliminación de semántica para modelos y aristas donde CRUD es posible y donde deseas exponer ese CRUD y en otros lugares tienes mutaciones para comandos donde puedes invocar esos comandos, ¿verdad, y esa convención es la que genera el esquema de GraphQL correcto a partir del subyacente. Ahora podemos ver que el beneficio aquí es, ya sabes, en el lado del rendimiento y en nuestra capacidad para componer y diseñar la API y, por supuesto, externalizar las reglas de autorización para poder crear una capa de seguridad y cumplimiento estandarizada para nuestra API de datos que es, ya sabes, un enfoque unificado en diferentes tipos de fuentes de datos. Un beneficio adicional aparte de ser declarativo y nuestra capacidad para razonar sobre las cosas a nivel de gráfico de dominio y mirar las reglas de autorización es que también puedes utilizar la misma técnica para construir una API de caché de datos automatizada.

8. Authorization Rules and Scaling

Short description:

Tomemos un ejemplo en el que tengo documentos, un equipo, de un modelo, un modelo de documento, ¿verdad, que tiene un ID y un título. Cada documento pertenece a un equipo y el equipo tiene una lista de usuarios. Las reglas de autorización en los documentos determinan si un usuario tiene permiso para operar o acceder al documento. Esta lógica es difícil de externalizar, pero ahora tenemos un enfoque para escalar y estandarizarla en modelos y aristas.

Tomemos un ejemplo en el que tengo documentos, un equipo, de un modelo, un modelo de documento, ¿verdad, que tiene un ID y un título. Y cada documento pertenece a un equipo y el equipo tiene una lista de usuarios, ¿verdad? Una regla de autorización en el documento diría que si el equipo.usuario contiene al usuario actual, tengo permiso para operar o acceder a este documento, ¿verdad? Si el usuario 1 estaba haciendo una consulta al documento, el usuario 1 pertenece al equipo 1. Y si el usuario 2, que también pertenece al equipo 1, hace una consulta al documento, queremos que ocurra un acierto en la caché. Y este acierto en la caché ahora puede ocurrir porque la regla de autorización es la misma y puede determinar que el usuario 1 y el usuario 2 van a resultar en un acierto en la caché, ¿verdad? Este tipo de lógica es difícil de externalizar a menos que externalicemos la regla de autorización en sí misma. Por lo tanto, nuestras reglas de autorización también se están convirtiendo en héroes de la caché. Y eso es lo que habrías hecho si estuvieras construyendo esto tú mismo. Pero ahora tenemos un enfoque para escalar esto y estandarizarlo en cualquier modelo que tengamos, en cualquier arista que tengamos que recorrer.

9. Summary and Authorization Challenges

Short description:

Hemos discutido el diseño y la estandarización de GraphQL para APIs de datos, así como la seguridad a nivel de nodo como método de autorización. La Especificación de Datos de GraphQL en GitHub proporciona una gramática formalizada y un espacio de pruebas para la exploración del diseño de la API. Si estás construyendo una plataforma o API de datos, me encantaría saber de ti. En una encuesta, la autorización y la seguridad fueron identificadas como la principal preocupación en las pilas de GraphQL. El rendimiento fue la segunda preocupación. En cuanto a la autorización, hay dos dimensiones principales a considerar: el rendimiento y la capacidad de externalizar la lógica de autorización. Integrar la obtención de datos y la lógica de autorización es crucial, especialmente en escenarios federados o al tratar con múltiples fuentes de datos. Filtrar los datos basados en reglas de autorización debe hacerse durante el proceso de obtención para evitar un procesamiento innecesario de datos. Reglas de autorización complejas pueden implicar recorrer el grafo y evaluar propiedades de los datos y la sesión del usuario.

Entonces, para resumir rápidamente, hemos analizado la API de datos, hemos analizado cómo podemos diseñar y estandarizar el enfoque de GraphQL para APIs de datos. Hemos analizado la seguridad a nivel de nodo como autorización. Lo hemos reunido en GitHub en la Especificación de Datos de GraphQL y también hay un espacio de pruebas allí que puedes revisar. Hay una formalización con la especificación preliminar que formaliza la gramática y hay un espacio de pruebas donde puedes ingresar ciertos modelos y aristas y ver cómo se ve la autorización y cómo se vería un diseño de API. Y puedes usar eso si estás pensando en construir una plataforma de datos o un servicio de datos o una API de datos dentro de tu organización.

Si estás haciendo algo así, me encantaría saber de ti. Me encantaría intercambiar notas, pero eso me lleva a mi tiempo. Y espero que haya sido una introducción interesante a cómo funcionan las APIs con GraphQL. Gracias. Y gracias por tu pregunta en la encuesta. Creo que fue una pregunta muy interesante. Veamos los resultados. Entonces, si miramos los resultados de tu pregunta, la pregunta fue, en tu pila de GraphQL, ¿cuál de las siguientes es la mayor preocupación o el mayor obstáculo para tus equipos? Y las opciones fueron autorización y seguridad, rendimiento, no usar GraphQL en absoluto, o tiempo invertido en ejecutar resolvers. La autorización y la seguridad fue el resultado principal. Y luego el segundo fue el rendimiento. Supongo que tal vez, por cierto, solo diré a las personas que pueden seguir haciendo preguntas en Discord si quieren, y estimaré estas preguntas. Así que pensando en tu charla, ¿cómo crees que, ya sabes, parece que el tema de la autorización y la seguridad en GraphQL sigue surgiendo en cada conversación de GraphQL? ¿Qué crees que será la mayor diferencia para las personas, digamos, si adoptamos esta idea de lo que estás sugiriendo en tu charla? Sí, creo que, así que creo que solo hay dos preocupaciones principales con la autorización, ¿verdad? Así que dejemos la seguridad de la API de GraphQL fuera y hablemos de la autorización, ¿verdad? Entonces, las cosas de seguridad de la API de GraphQL son como límite de velocidad, límite basado en costos, y cosas así que son comunes a todas las APIs, ¿verdad? Pero hay algunos aspectos únicos en GraphQL que pueden requerir que seas más específico al respecto, ¿verdad? Como tal vez el límite de velocidad debería basarse en algo que se base en la complejidad de la consulta o en la profundidad de la consulta o algo así, eso podría ser un poco único en GraphQL. Pero en general, cualquier seguridad normal de API te dará el mismo tipo de seguridad de API con GraphQL, ¿verdad? Así que eso funcionará bien, no es gran cosa. Deshabilitar la introspección, todas esas cosas estándar, no es un problema. Pero cuando pensamos en la autorización en particular, se vuelve muy interesante y desafiante en dos dimensiones, ¿verdad? La primera dimensión es el rendimiento y la segunda dimensión es la capacidad de externalizar la lógica de autorización. Lo que quiero decir con rendimiento es que a menudo notaremos que cuando estamos, especialmente en un escenario federado donde tenemos múltiples servicios o múltiples fuentes, pero incluso en una sola fuente donde estás obteniendo datos de múltiples puntos de API o múltiples tablas o lo que tengas como tu fuente ascendente. La obtención de datos y la lógica de autorización deben integrarse, ¿verdad? Un ejemplo extremadamente simple. Estoy obteniendo una lista de pedidos del sistema, ¿verdad? Cuando obtengo una lista de pedidos del sistema, solo debo obtener aquellos pedidos a los que tengo acceso. No puedes hacer una consulta a mil millones de pedidos y luego filtrar eso, ¿verdad? No puedes ir a una API ascendente y decir, sí, dame todos los pedidos que tengas. Tu servicio ascendente morirá. Tú morirás, ¿verdad? Tratando de procesar esa cantidad de datos. Y luego después de eso aplicaremos una regla de autorización para filtrar qué pedidos se pueden acceder, ¿verdad? Eso no es lo que quieres hacer, ¿verdad? Imagina que otra regla de autorización es más compleja y atraviesa el grafo. Puedes acceder a los pedidos si el gerente de cuenta del pedido.región es igual a la región del usuario actual, ¿verdad? Puedes evaluar la propiedad compleja de los datos y una propiedad compleja de la sesión del usuario para decidir si alguien está fuera de esa parte de esa información está fuera de tu

10. Desafíos de Autorización y Diseño de API

Short description:

La superposición entre la optimización de la obtención de datos y la evaluación de reglas de autorización en GraphQL plantea un desafío. Abordar GraphQL de manera ingenua sin considerar la autorización puede generar problemas. Es importante estandarizar la autorización y ubicarla en el contexto adecuado. Hay una especificación preliminar disponible para explorar el diseño de API y autorización. El objetivo es colocar la autorización en el lugar correcto y organizar el código en consecuencia. Se sugiere la creación de un grupo de trabajo para la autorización en GraphQL.

servicio actual. Exacto. ¿Podría ser correcto? Eso es cuando se vuelve complejo ¿verdad? Entonces, estamos viendo que esta superposición está ocurriendo, ¿verdad? Hay una superposición entre todo el trabajo de optimización que haríamos para obtener data en los servicios. Es muy similar a todo el trabajo de optimización que tendríamos que hacer al evaluar reglas de autorización en estos data e integrarlo con la obtención de data, ¿verdad? Estos son problemas que cualquier API tendría, pero en el contexto de GraphQL, si abordamos ingenuamente GraphQL, la razón por la que la autorización se convierte en un problema es porque no hay forma de pensar en cómo resolver este problema, ¿verdad? Si tuvieras una API REST, no te preocuparías realmente por este problema porque, quiero decir, tienes el control de la API, ¿verdad? En última instancia, el punto final de la API es algo tan simple como slash orders. Ahora puedes hacer cualquier cosa dentro de ese código, ¿verdad? Puedes hacer autorización compleja, obtención de data compleja, lo que sea, porque no proporcionaste flexibilidad. Si no proporcionas ninguna flexibilidad, depende de ti hacer lo que quieras, ¿verdad? Entonces, con GraphQL, al proporcionar esa flexibilidad, pero también integrar la autorización con esa flexibilidad, eso comienza a convertirse en un desafío importante. Sí, me gusta porque también, básicamente, una de las cosas es que cuando las personas se unen a GraphQL, tienden a colocar la autorización también en el lugar equivocado, ¿verdad? Y luego dejan, ya sabes, dejan cosas abiertas o simplemente centralizan la gestión de eso, aunque no sean las personas que realmente necesitan encargarse de la autorización o encargarse de ella. Y esto es como tratar de estandarizarlo o al menos decirle a la gente, aquí es donde pertenece. Aquí es donde alguien necesita escribir eso, tal vez. Y ¿ves, entonces crees que esto es como una especie de, digamos, una especificación adicional, como un GraphQL plus X. ¿Ves, qué ves como las primeras formas concretas para que las personas lo usen o prueben estas cosas o algo así? Sí, puse un enlace al, puse un enlace a nuestro repositorio de GitHub donde comenzamos a juntar el borrador de la especificación. Y así puedes probarlo. Es una especie de especificación. Aún no hay tiempo de ejecución. Quiero decir, lo que hemos estado haciendo en Hasura es una especie de tiempo de ejecución para la misma especificación. Entonces, si quieres la implementación de referencia de la especificación que está cerca de ella, puedes ver Hasura para ver cómo funciona. Pero si miras la especificación en sí, hay un borrador que puedes comenzar a ver y formar opiniones sobre cómo puedes comenzar a usar la especificación para tu propia API de diseño y diseño de autorización y cosas así. Sí. Teóricamente, también podemos tomar esto y luego hacer que las personas escriban hoy resolutores manuales en TypeScript, JavaScript, para definir el marco de dónde deben escribir estas cosas y luego, incluso por ahora, no usar los beneficios de ejecución, pero al menos comenzar a ordenar cosas y luego tal vez más adelante comenzar a introducir motores de ejecución más inteligentes. Exactamente. Pero al menos ahora estás comenzando a colocar tu autorización en el lugar correcto porque de lo contrario, estás poniendo tu código de autorización, tal vez puedes graficar tu esquema o algo así y eso nunca funcionará. Cosas como esas. Hagamos un grupo de trabajo. Grupo de trabajo de autorización de GraphQL. Bueno, se nos acabó el tiempo, pero tenemos cosas muy emocionantes para continuar la conversación. Primero que nada, gracias Palme. Es un placer como siempre. Fue muy, muy interesante. Gracias por esta sesión.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
Top Content
We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!
Vue.js London Live 2021Vue.js London Live 2021
24 min
Local State and Server Cache: Finding a Balance
Top Content
How many times did you implement the same flow in your application: check, if data is already fetched from the server, if yes - render the data, if not - fetch this data and then render it? I think I've done it more than ten times myself and I've seen the question about this flow more than fifty times. Unfortunately, our go-to state management library, Vuex, doesn't provide any solution for this.For GraphQL-based application, there was an alternative to use Apollo client that provided tools for working with the cache. But what if you use REST? Luckily, now we have a Vue alternative to a react-query library that provides a nice solution for working with server cache. In this talk, I will explain the distinction between local application state and local server cache and do some live coding to show how to work with the latter.
React Day Berlin 2022React Day Berlin 2022
29 min
Get rid of your API schemas with tRPC
Do you know we can replace API schemas with a lightweight and type-safe library? With tRPC you can easily replace GraphQL or REST with inferred shapes without schemas or code generation. In this talk we will understand the benefit of tRPC and how apply it in a NextJs application. If you want reduce your project complexity you can't miss this talk.

Workshops on related topic

GraphQL Galaxy 2021GraphQL Galaxy 2021
140 min
Build with SvelteKit and GraphQL
Top Content
Featured WorkshopFree
Have you ever thought about building something that doesn't require a lot of boilerplate with a tiny bundle size? In this workshop, Scott Spence will go from hello world to covering routing and using endpoints in SvelteKit. You'll set up a backend GraphQL API then use GraphQL queries with SvelteKit to display the GraphQL API data. You'll build a fast secure project that uses SvelteKit's features, then deploy it as a fully static site. This course is for the Svelte curious who haven't had extensive experience with SvelteKit and want a deeper understanding of how to use it in practical applications.

Table of contents:
- Kick-off and Svelte introduction
- Initialise frontend project
- Tour of the SvelteKit skeleton project
- Configure backend project
- Query Data with GraphQL
- Fetching data to the frontend with GraphQL
- Styling
- Svelte directives
- Routing in SvelteKit
- Endpoints in SvelteKit
- Deploying to Netlify
- Navigation
- Mutations in GraphCMS
- Sending GraphQL Mutations via SvelteKit
- Q&A
React Advanced Conference 2022React Advanced Conference 2022
95 min
End-To-End Type Safety with React, GraphQL & Prisma
Featured WorkshopFree
In this workshop, you will get a first-hand look at what end-to-end type safety is and why it is important. To accomplish this, you’ll be building a GraphQL API using modern, relevant tools which will be consumed by a React client.
Prerequisites: - Node.js installed on your machine (12.2.X / 14.X)- It is recommended (but not required) to use VS Code for the practical tasks- An IDE installed (VSCode recommended)- (Good to have)*A basic understanding of Node.js, React, and TypeScript
GraphQL Galaxy 2022GraphQL Galaxy 2022
112 min
GraphQL for React Developers
Featured Workshop
There are many advantages to using GraphQL as a datasource for frontend development, compared to REST APIs. We developers in example need to write a lot of imperative code to retrieve data to display in our applications and handle state. With GraphQL you cannot only decrease the amount of code needed around data fetching and state-management you'll also get increased flexibility, better performance and most of all an improved developer experience. In this workshop you'll learn how GraphQL can improve your work as a frontend developer and how to handle GraphQL in your frontend React application.
React Summit 2022React Summit 2022
173 min
Build a Headless WordPress App with Next.js and WPGraphQL
Top Content
WorkshopFree
In this workshop, you’ll learn how to build a Next.js app that uses Apollo Client to fetch data from a headless WordPress backend and use it to render the pages of your app. You’ll learn when you should consider a headless WordPress architecture, how to turn a WordPress backend into a GraphQL server, how to compose queries using the GraphiQL IDE, how to colocate GraphQL fragments with your components, and more.
GraphQL Galaxy 2020GraphQL Galaxy 2020
106 min
Relational Database Modeling for GraphQL
Top Content
WorkshopFree
In this workshop we'll dig deeper into data modeling. We'll start with a discussion about various database types and how they map to GraphQL. Once that groundwork is laid out, the focus will shift to specific types of databases and how to build data models that work best for GraphQL within various scenarios.
Table of contentsPart 1 - Hour 1      a. Relational Database Data Modeling      b. Comparing Relational and NoSQL Databases      c. GraphQL with the Database in mindPart 2 - Hour 2      a. Designing Relational Data Models      b. Relationship, Building MultijoinsTables      c. GraphQL & Relational Data Modeling Query Complexities
Prerequisites      a. Data modeling tool. The trainer will be using dbdiagram      b. Postgres, albeit no need to install this locally, as I'll be using a Postgres Dicker image, from Docker Hub for all examples      c. Hasura
GraphQL Galaxy 2021GraphQL Galaxy 2021
48 min
Building GraphQL APIs on top of Ethereum with The Graph
WorkshopFree
The Graph is an indexing protocol for querying networks like Ethereum, IPFS, and other blockchains. Anyone can build and publish open APIs, called subgraphs, making data easily accessible.

In this workshop you’ll learn how to build a subgraph that indexes NFT blockchain data from the Foundation smart contract. We’ll deploy the API, and learn how to perform queries to retrieve data using various types of data access patterns, implementing filters and sorting.

By the end of the workshop, you should understand how to build and deploy performant APIs to The Graph to index data from any smart contract deployed to Ethereum.