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.