Explorando el Data Mesh impulsado por 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

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

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

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.

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.

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.

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.

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.

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

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.