Todo sobre GraphQL

de hablarles hoy. Entonces, ¿quién soy yo rápidamente antes de entrar en qué estamos hablando? Mi nombre es Sedghi, soy Líder Técnico en Tyk. Lidero a un grupo de ingenieros de ventas y consultores muy talentosos. Y hablamos con clientes de todo el mundo y de empresas de todos los tamaños sobre GraphQL, sobre REST, sobre API, sobre Kubernetes y Docker. Es una posición muy afortunada estar en la intersección de muchos dominios diferentes.

GraphQL es una tendencia emergente. ¿Y qué es Tyk? Somos un proveedor de puerta de enlace de API de código abierto y ahora ofrecemos gestión completa del ciclo de vida de la API. Así que siéntanse libres de ir a tyk.io y tener una idea de lo que es. Entonces, ¿qué vamos a hacer hoy? Voy a importar algunas API REST en Tyk. Tenemos una colección de API REST, las vamos a importar en nuestra gestión de API. Vamos a convertir automáticamente las API REST en una API GraphQL. Y eso es todo, vamos a obtener beneficios. Les voy a mostrar lo fácil que es hacerlo. Y entonces, ¿qué tenemos? Tenemos un punto final REST de usuario que tiene un ID, nombre, nombre de usuario, correo electrónico y luego publicaciones. Y estas publicaciones son un array que se refiere a todas las publicaciones realizadas por este usuario. Una publicación tiene estos campos, y luego tiene comentarios, y un comentario es un array de este tipo. Y estos son tres puntos finales diferentes. Voy a componer esto en una única API GraphQL para ustedes, y podemos hablar sobre los enfoques diferentes.

Muy bien, vamos allá. Aquí estamos, estoy en el panel de control de gestión de API, no vamos a entrar en los detalles de todas las cosas diferentes, pero pueden ver que tenemos esta API aquí, se llama GraphQL posts v2. Y ahora mismo, tenemos un tipo de usuario y un tipo de publicación. Ya he definido mis esquemas, y es una representación uno a uno de la API subyacente. Así que si voy aquí y voy a usuarios uno, quiero el recurso REST de donde el ID de usuario es uno, y me devuelve todos los datos JSON. Así que tenemos a Leanne Graham como nombre, nombre de usuario, correo electrónico, y así sucesivamente. Y he tomado estos campos de JSON, los he mapeado en este esquema GraphQL. Y luego fui e inyecté las publicaciones. Así que aquí tenemos una segunda API, y se llama publicaciones. Así que tenemos todas las publicaciones que pertenecen

a este usuario. Puedes ver que es una matriz donde cada publicación tiene un ID. Y eso son dos puntos finales REST diferentes. Ahora te mostraré cómo, usando GraphQL, vamos a obtener eso usando una sola llamada a la API. Así que tenemos este usuario, donde el ID es uno. Si nunca has visto esto antes, es un GraphQL playground. Nos permite hacer consultas a los datos, tiene IntelliSense, lo cual nos ayudará a mostrar los campos que podemos solicitar. Y quiero el ID, nombre y correo electrónico del usuario donde el ID es uno. Y luego quiero todas las publicaciones. Y quiero el título y el cuerpo de cada publicación. Y si lo ejecuto, obtenemos todos los datos que acabamos de obtener de dos puntos finales separados. Y los hemos combinado en una sola llamada a la API. Hablaremos de por qué eso es poderoso en breve. Pero primero, para que puedas ver que no hay vaporware aquí, vamos a seguir adelante e inyectar comentarios como un subarreglo de publicaciones. Los comentarios se ven así. Y vamos a al punto final de comentarios y puedes ver donde el ID de la publicación es igual a X y obtienes todos los comentarios con sus IDs que pertenecen a la publicación donde el ID es Y. Así que vamos a seguir adelante e inyectar eso. Lo que voy a hacer es tomar el JSON de Swagger o la especificación de OpenAPI. Voy a ir a Tyk y luego voy a importar una API y podemos verla desde Swagger y luego copiaré el punto final aquí y lo pegaré. Así que tenemos eso. Ahí está la URL base y ahí está la versión y luego vamos a generar la API. Y así de fácil, hemos generado una API. La ruta de escucha es foobar y el tipo de autenticación es openkeyless. Así que vamos a seguir adelante y crear eso. Si vamos a Diseñador de Puntos Finales, podemos ver que hemos importado todos los puntos finales. Así que tenemos las publicaciones, las tareas pendientes, los usuarios, los álbumes, las fotos, los comentarios, y así sucesivamente. Y ahora hemos importado nuestra API. Ahora está en Tyk. Ahora lo siguiente que vamos a hacer es ir a nuestro gráfico. Vamos a definir un nuevo esquema. Así que es un tipo de comentario donde, veamos,

un comentario tiene un ID, un nombre y un correo electrónico. Así que importemos eso. Así que un ID, un nombre y un correo electrónico. Y todos son de tipo cadena. Y hagamos eso. Bien, finalmente vamos a crear un nuevo campo bajo publicaciones llamado comentarios, y eso es una matriz de tipo comentario. ¿Y luego, hemos terminado? Bueno, más o menos. Si volvemos a nuestro playground, y ups, ahora tenemos este tipo de comentarios donde puedo pedir el nombre y el correo electrónico de cada comentario. Pero obtenemos un no como respuesta. ¿Por qué? Bueno, eso es porque aún no le hemos dicho al tipo de dónde obtener los data para este campo de comentarios. Así que ahí es donde tenemos que ir y definir eso a continuación.

Así que aquí, vamos a ir a publicación, a comentarios. Voy a definir una data fuente. Voy a decir, no una existente. Vamos a definir una nueva. Es TykRest, la fuente de datos. Y luego vamos a seleccionar nuestro JSON placeholder que acabamos de importar. Y ahora incluso podemos seleccionar el punto final en sí. Y en lugar de eso, vamos a decir comentarios donde el ID de la publicación sea igual. Y luego vamos a inyectar el ID del tipo publicación y actualizar. Y le vamos a dar un nombre, punto final de comentarios, y luego actualizar y actualizar. Y ahora le hemos dicho a Tyk, bien, cuando llegue una solicitud y alguien pida un campo de comentarios que pertenezca a publicaciones, ve al punto final de comentarios e inyecta el ID de la publicación desde el objeto padre. Y ahora, si envío la misma solicitud, bueno, la arruiné. Así que eso es malo. Pero la idea es así es como debería haber funcionado. Así que dioses de la demostración y todo eso, pero no sé. De todos modos, nos quedan 45 segundos antes de terminar. Así que no voy a entrar en el modo debug y descubrir qué hice mal. Pero esa es la idea en pocas palabras. Entonces, lo que queríamos hablar era la diferencia entre hacer una solicitud de consulta para GraphQL, en comparación con REST. Y así, con REST, puedes ver que si queríamos todos estos data, no solo teníamos que ir a tres puntos finales diferentes, sino que además de eso, teníamos que descubrir las relaciones. Así que nosotros en el frontend construyendo, digamos, una página de inicio para una aplicación de redes sociales, teníamos que hacer una llamada a usuario. Y luego teníamos que hacer una segunda llamada para obtener todas las publicaciones que pertenecen a este usuario. Así que teníamos que inyectar el ID de usuario en esta llamada. Y finalmente, teníamos que ir a comentarios y comentarios e inyectar todos los IDs de publicación y hacer una llamada a la API por cada una de mis publicaciones. Así que había potencialmente docenas y docenas de llamadas a la API que teníamos que hacer. Eso ya no es así. Es solo una sola solicitud de API de GraphQL, si funcionara, y obtuvimos todos los data de una vez. Así que ahora estoy fuera de tiempo, así que voy a detenerme. Pero muchas gracias por ver.