Smashing Podcast Episodio 31 con Eve Porcello: ¿Qué es GraphQL?

En este episodio, estamos hablando de GraphQL. ¿Qué es y cómo resuelve algunos problemas comunes de API? Hablé con la experta Eve Porcello para averiguarlo.

Mostrar notas

• Eva en Twitter
• Compañía de Eve Moon Highway
• Aprendiendo GraphQL de O'Reilly
• Descubra su camino a través de GraphQL Wilderness: el taller GraphQL de Eve se lanzará a principios de 2021

Actualización semanal

• Cómo usar MDX almacenado en Sanity en un sitio web Next.js
  escrito por jason lengstorf
• Creación de un chatbot habilitado para PNL conversacional utilizando Dialogflow de Google
  escrito por victoria nwani
• Consideraciones éticas en la investigación de UX: la necesidad de capacitación y revisión
  escrito por Víctor Yocco
• Hacer que los sitios web sean más fáciles de hablar
  escrito por Frederick O'Brien
• Cómo diseñar una interfaz de usuario simple cuando tiene una solución compleja
  escrito por Suzanne Scacca

Transcripción

Drew McLellan: es ingeniera de software, instructora, autora y cofundadora de la empresa de capacitación y desarrollo de currículos, Moon Highway. Su carrera comenzó escribiendo especificaciones técnicas y creando diseños UX para proyectos web. Desde que comenzó Moon Highway en 2012, ha creado contenido de video para egghead.io y LinkedIn Learning, y es coautora de los libros Learning React y Learning GraphQL para O'Reilly's Media.

Drew: También es una oradora frecuente y se ha presentado en conferencias como React Rally, GraphQL Summit y OSCON. Sabemos que es una experta en GraphQL, pero ¿sabías que una vez le enseñó a un oso polar a jugar al ajedrez? Mis grandes amigos, denle la bienvenida a Eve Porcello.

Drew: Hola Eva, ¿cómo estás?

Eve Porcello: Estoy genial.

Drew: Como mencioné allí, eres un gran educador en cosas como JavaScript y React, pero hoy quería hablarte sobre una de tus otras áreas de especialización, GraphQL. Muchos de nosotros hemos oído hablar de GraphQL de alguna manera, pero es posible que no estemos completamente seguros de qué es o qué hace y, en particular, qué tipo de problema resuelve en la pila web.

Drew: Así que prepara el escenario para nosotros, por así decirlo, si soy un desarrollador front-end, ¿dónde encaja GraphQL en el ecosistema y qué función realiza para mí?

Eva: Sí. GraphQL encaja entre el front-end y el backend. Es como vivir en el medio entre los dos y brinda muchos beneficios a los desarrolladores front-end y back-end.

Eve: Si es un desarrollador front-end, puede definir todos sus requisitos de datos de front-end. Entonces, si tiene una gran lista de componentes de React, por ejemplo, podría escribir una consulta. Y eso definirá todos los campos que necesitará para completar los datos de esa página.

Eve: Ahora, con la pieza de fondo, es realmente propia, porque podemos recopilar una gran cantidad de datos de muchas fuentes diferentes. Así que tenemos datos en API REST, bases de datos y todos estos lugares diferentes. Y GraphQL nos brinda esta pequeña y agradable capa de orquestación para realmente dar sentido al caos de dónde están todos nuestros datos. Así que es realmente útil para todo el mundo en toda la pila.

Drew: Entonces es básicamente una tecnología basada en API, ¿no es así? Se encuentra entre su front-end y su back-end y proporciona algún tipo de API, ¿es correcto?

Eva: Sí, eso es exactamente correcto. Exactamente.

Drew: Creo que, durante la última década, el estándar de oro para las API ha sido el descanso. Entonces, si tiene una aplicación del lado del cliente y necesita completarla con datos del backend, crearía un punto final de API REST y lo consultaría. Entonces, ¿dónde cae ese modelo? ¿Y cuándo podríamos necesitar que GraphQL venga y lo resuelva por nosotros?

Eve: Bueno, el problema con el que GraphQL realmente nos ayuda, una especie de problema dorado, la solución dorada, supongo, que proporciona GraphQL es que con REST estamos extrayendo una gran cantidad de datos. Entonces, si tengo usuarios de barra o productos de barra, eso me devolverá todos los datos cada vez que llegue a la ruta.

Eve: Con GraphQL, podemos ser un poco más exigentes con los datos que queremos. Entonces, si solo necesito cuatro campos de un objeto que tiene cien, podré identificar realmente esos campos y no tener que cargar datos, o cargar todos esos datos, debería decir, en su dispositivo, porque eso es mucho trabajo extra, especialmente para su teléfono.

Drew: He visto y trabajado con API REST en el pasado que tienen un campo opcional donde puede pasar una lista de los datos que desea recuperar, o puede aumentar lo que regresa con cosas adicionales. Y supongo que eso es identificar este problema, ¿no es así? Eso quiere decir que no siempre desea recuperar los mismos datos cada vez. Entonces, ¿GraphQL formaliza ese enfoque de permitir que el front-end especifique qué devolverá el backend, en términos de datos?

Eva: Sí, exactamente. Entonces, su consulta se convierte en cómo pregunta, cómo filtra, cómo capta cualquier tipo de información desde cualquier lugar.

Eve: También creo que es importante tener en cuenta que no tenemos que derribar todas nuestras API REST para poder trabajar con GraphQL de manera realmente exitosa. Muchas de las implementaciones más exitosas de GraphQL que he visto, son envoltorios alrededor de las API REST. Y la consulta de GraphQL realmente le brinda una forma de pensar qué datos necesita. Y luego, tal vez algunos de sus datos provengan de nuestros usuarios y productos, por ejemplo, algunos de los datos provienen de REST, algunos de ellos provienen de una base de datos.

Drew: Supongo que el escenario familiar es que puede tener un punto final en su sitio web que devuelve información sobre un usuario para mostrar el encabezado. Podría darte su nombre de usuario y su avatar. Y selecciona eso en cada página y completa los datos, pero luego encuentra otro lugar en su aplicación donde necesita mostrar su nombre completo.

Drew: Entonces agregas eso al punto final y comienza a devolverlo. Y luego haces la sección de administración de tu cuenta, y necesitas como su dirección postal. Entonces eso también lo devuelve ese punto final.

Drew: Y antes de que te des cuenta, ese punto final está devolviendo una gran carga útil que cuesta bastante en el backend para armar, y obviamente mucho para descargar.

Drew: Y eso ha sido seleccionado en cada página solo para mostrar un avatar. Así que supongo que ese es el tipo de problema que crece con el tiempo, en el que era tan fácil caer, particularmente en equipos grandes, que GraphQL está encima de ese problema. Sabe cómo resolver eso, y está diseñado para resolverlo.

Eva: Exacto. Y sí, creo que toda la idea de un esquema GraphQL, creo que es realmente, se habla menos que la parte del lenguaje de consulta de GraphQL. Pero realmente siento que el esquema en particular nos brinda este sistema de tipo agradable para la API.

Eve: Entonces, cualquier miembro del equipo, gerentes, desarrolladores front-end, desarrolladores back-end, cualquiera que realmente esté tratando con datos puede unirse, unirse en torno a qué datos realmente queremos servir en esta API, y luego todos saben cuál es esa fuente. la verdad es que pueden construir sus propias partes de la aplicación basándose en eso.

Eve: Así que hay algunas cosas complicadas de gestión de esquemas que surgen con eso también. Pero en cuanto a pasar de los microservicios a los monolitos, estamos haciendo eso, pero aún obteniendo todos los beneficios que nos gustan de los microservicios.

Drew: ¿Y entiendo correctamente que la forma típica de configurar un sistema GraphQL es que tendrías básicamente una ruta, que es el punto final al que envías todas tus consultas para que no tengas que... A menudo uno de los lo más difícil es decidir qué nombrar y cuál debería ser la ruta en la que debería estar esta consulta en particular. Se trata de usuarios y productos que regresan, ¿debería ser recortar algo a los usuarios o recortar algo al producto?

Drew: Con GraphQL, solo tiene un punto final al que solo envía sus consultas y obtiene una respuesta adecuada.

Eva: Exacto. Si. Es un punto final único. Supongo que todavía estás lidiando con problemas de nomenclatura porque estás nombrando todo en el Esquema. Pero en cuanto a, siento que muchas empresas que han hecho grandes apuestas en microservicios, todos dicen, ¿qué terminales tenemos? ¿Dónde están? ¿Cómo se documentan? Y con GraphQL, tenemos un lugar, un tipo de diccionario para buscar cualquier cosa que queramos saber sobre cómo funciona la API.

Drew: Entonces, estoy muy familiarizado con otros lenguajes de consulta, como SQL es un ejemplo obvio de un lenguaje de consulta que muchos desarrolladores web conocerán. Y las consultas en eso toman la forma de casi como un comando. Es una cadena de texto, ¿no es así? Seleccione esto de eso, dónde, lo que sea. ¿Qué formato toman las consultas con GraphQL?

Eve: Sigue siendo una cadena de tecnología, pero no define de dónde viene esa lógica. Y gran parte de la lógica se traslada de nuevo al servidor. Entonces, el servidor GraphQL, la API de GraphQL, es realmente responsable de decir: "Obtenga estos datos de donde están, fíltrelos según estos parámetros".

Eve: Pero en el lenguaje de consulta, está muy orientado al campo. Entonces solo agregamos campos para cualquier cosa que queramos recuperar. Por supuesto, también podemos poner filtros en esas consultas. Pero creo que es un poco menos directo acerca de dónde proviene esa información. Gran parte de la funcionalidad está integrada en el servidor.

Drew: Entonces puedes mezclar y combinar en una consulta. Puede realizar una solicitud que traiga muchos tipos diferentes de datos en una sola solicitud. ¿Está bien?

Eva: Sí, eso es absolutamente correcto. Por lo tanto, puede enviar una consulta para tantos campos como permita su servidor y recuperar todo tipo de datos anidados. Pero así es realmente como funciona, conectamos diferentes tipos en los campos. Así que supongo que reciclaremos mi idea de usuarios y productos, pero el usuario puede tener un campo de productos que devuelve una lista de productos. Todos ellos están asociados con otros tipos también. Entonces, tan profundamente anidada como queramos que vaya la consulta, podemos hacerlo.

Drew: Entonces, ¿eso significa recuperar los datos para una vista típica en su aplicación web que puede tener todo tipo de cosas sucediendo, que puede hacer una sola solicitud al backend y obtener todo de una sola vez sin necesidad de hacer diferentes consultas a diferentes puntos finales, porque todo es una sola cosa?

Eva: Sí. Ese es exactamente el objetivo completo, es solo una consulta única, definir cada campo que desee y luego devolverlo en una respuesta.

Drew: Y las consultas están basadas en JSON, ¿es así?

Eve: La consulta en sí es una cadena de texto, pero normalmente devuelve datos JSON. Entonces, si tengo los campos, entonces mi respuesta JSON coincide exactamente, por lo que está muy claro lo que obtienes cuando envías esa consulta, porque la respuesta de datos se ve exactamente igual.

Drew: Parece que muchas de las consultas son casi como objetos básicos, como un cliente o un producto. ¿Hay alguna forma de especificar consultas más complejas en las que la lógica empresarial se controle en el backend? Digamos que quiero obtener una lista de equipos para un usuario, pero solo donde ese usuario es administrador de un equipo y donde el plan del equipo no ha vencido, y todo ese tipo de restricciones reales que enfrentamos en el desarrollo diario de aplicaciones web. ¿Se puede lograr eso con GraphQL?

Eva: Absolutamente. Así que eso es lo realmente emocionante y poderoso de GraphQL, puedes mover mucha de esa lógica al servidor. Si tuviera una consulta compleja, algún tipo de usuario realmente específico que quisiera obtener, todo lo que tendría que hacer en el Esquema es decir, "Obtener usuario complicado", y luego en el servidor, habría una función donde podrías escribir toda la lógica en el idioma que quisieras. JavaScript es una especie de lenguaje de implementación de GraphQL más popular, pero no tiene que usarlo en absoluto. Así que Python, Go, C++, lo que quieras usar, puedes construir un servidor GraphQL con eso. Pero sí, puede definir una consulta tan compleja como desee.

Drew: Y supongo que eso te permite encapsular mucha lógica comercial en nuevos tipos de objetos. ¿Es eso justo? Ya sabes, configuras un usuario complicado y luego no necesitas pensar qué es un usuario complicado, pero puedes seguir usando ese usuario complicado y saber que la lógica comercial se implementa en eso. ¿Está bien?

Eva: Eso es exactamente correcto. Así que creo que esto es realmente bueno para la gente de front-end porque pueden comenzar a crear prototipos basados ​​​​en eso. Y luego el equipo de back-end podría ir a implementar esas funciones para que funcionen. Y luego está una especie de comprensión compartida de lo que realmente es ese tipo y quiénes son, y "¿Cuáles son los campos en ese tipo?" Y todo puede ser manejado por cualquier parte de la pila en la que GraphQL esté funcionando. Y es por eso que no es realmente una tecnología de front-end o back-end. Es realmente una especie de ambos, y ninguno.

Drew: Parece que es una forma de formalizar la API y la relación entre el front-end y el back-end, por lo que todos obtienen una interfaz predecible que está estandarizada.

Eva: Exacto.

Drew: Supongo que en organizaciones donde el front-end y el back-end son propiedad de diferentes equipos, lo cual no es nada raro, supongo que este enfoque también permite realizar cambios, digamos, en el front-end, podría requerir diferentes datos, sin necesidad de que alguien que trabaje en el backend haga los cambios correspondientes. Todavía tiene esta API casi infinitamente personalizable sin necesidad de realizar ningún trabajo para cambiarla si necesita nuevos datos.

Eva: Sí, exactamente correcto.

Drew: Entonces, ¿el servidor GraphQL es responsable de formatear la respuesta, o necesita hacerlo en la lógica del lado del servidor?

Eve: Entonces, el servidor GraphQL define dos cosas. Define el esquema en sí mismo que vive en el servidor y luego define las funciones de resolución. Esas son funciones que van a obtener los datos de donde sea que estén. Entonces, si tengo una API REST que estoy empaquetando con GraphQL, el resolutor obtendrá de esa API, transformará los datos como sea necesario y luego los devolverá al cliente en esa función. También puede usar cualquier tipo de función de base de datos que desee en ese servidor. Entonces, si tiene datos en un montón de lugares diferentes, este es un lugar cohesivo muy bueno para poner todos esos datos y diseñar toda la lógica en torno a, "¿De dónde vienen esos datos? ¿Cómo queremos transformarlo?”.

Drew: El cliente dice: "Quiero un usuario complejo", el servidor lo recibe en una consulta y podría decir: "Bien, voy a buscar el solucionador de usuarios complejos". ¿Está bien?

Eva: Mm-hmm (afirmativo).

Drew: Cuál es la función, y luego escribes tu lógica para que tu equipo de back-end, o quienquiera que escriba la lógica dentro de esa función, haga lo que sea necesario para devolver un usuario complejo.

Eva: Sí, exactamente.

Drew: Eso podría ser llamar a otras API, podría consultar una base de datos, podría buscar cosas en el caché o prácticamente cualquier cosa.

Eva: Casi cualquier cosa. Y luego, siempre que el retorno de la función coincida con los requisitos del Esquema, coincida con qué campos, qué tipos, regresaban allí, entonces todo funcionará bien y armoniosamente.

Drew: Supongo que le brinda un formato de respuesta consistente en toda su API de forma predeterminada. No tienes que diseñar cómo se ve eso. Solo obtienes un resultado consistente.

Eva: Sí, exactamente.

Drew: Creo que realmente podría ser una gran victoria, porque puede ser muy difícil mantener la coherencia en una gran variedad de puntos finales de API, especialmente en equipos más grandes. Diferentes personas están trabajando en diferentes cosas. A menos que tenga un gobierno bastante estricto, puede volverse muy complejo muy rápido, ¿no es así?

Eva: Sí, absolutamente. Y creo que Schema es un pequeño documento tan agradable para describir todo. Obtiene el beneficio automático de poder ver todos los campos en ese esquema cada vez que intenta enviarle consultas, porque puede enviar consultas de introspección y hay todo tipo de buenas herramientas para eso, como GraphQL y GraphQL Playground, pequeñas herramientas que puede utilizar para interactuar con los datos de la API.

Eve: Pero también, si alguna vez has jugado con Postman, como hacer ping a una API REST, muchas de esas, la documentación realmente no existe o es difícil de encontrar, o cosas así. GraphQL realmente te brinda esa buena capa cohesiva para describir todo lo que podría ser parte de esa API.

Drew: Prácticamente, ¿cómo funcionan las cosas en el lado del servidor? Quiero decir, supongo que necesita ejecutar un servicio GraphQL como parte de su infraestructura, pero ¿qué forma toma eso? ¿Es un servidor completo que se ejecuta en su propio puerto? ¿O es como una biblioteca que integra en su Express o Apache existente o lo que sea con una ruta que se resuelve en ese servicio? ¿Cómo lo implementas?

Eve: Sí, es un servidor real. Entonces, las implementaciones GraphQL más populares son los servidores Node.js. Cuando se lanzó GraphQL como especificación, el equipo lanzó esta implementación de referencia en JavaScript, una especie de servidor Node que sirvió como guía para todos estos otros que han aparecido. Pero sí, puede ejecutar estos servidores en sus propias instancias. Puedes ponerlos en Lambda. Así que está Apollo Server Express, está Apollo Server Lambda; todo tipo de diferentes tipos de implementaciones que puede usar para ejecutar esta cosa.

Drew: Mencionaste brevemente antes el concepto de esquema que tiene el servidor.

Eva: Sí.

Drew: Eso te da la capacidad de describir tus tipos de manera más estricta que solo, ya sabes, asignar un nombre a un resolutor. Hay más involucrados allí, ¿verdad?

Eva: Sí. Hay un lenguaje completo. Así que hice referencia a la especificación y no describí qué es. GraphQL en sí mismo es una especificación que describe el lenguaje de consulta y el lenguaje de definición de esquema. Así que tiene su propia sintaxis. Tiene sus propias reglas para definir estos tipos.

Eve: Cuando usa el lenguaje de definición de esquemas, básicamente usa todas las funciones de ese lenguaje para pensar, ¿cuáles son los tipos que forman parte de la API? También es donde defines las consultas, las mutaciones, cuáles son los verbos, como las acciones, crear el inicio de sesión de la cuenta, cosas así. E incluso las suscripciones de GraphQL, que son otra cosa genial, GraphQL en tiempo real que puede definir allí mismo en el Esquema.

Eva: Así que sí, el esquema es realmente muy importante. Y creo que nos brinda esta buena aplicación de tipos en toda nuestra aplicación Stack, porque tan pronto como comienzas a desviarte de esos campos y de esos tipos, comienzas a ver errores, lo cual es, en ese caso, bueno, porque Estamos siguiendo las reglas del Esquema.

Drew: ¿Hay algún cruce entre eso y TypeScript? ¿Hay algún tipo de sinergia entre los dos allí?

Eva: Absolutamente. Entonces, si eres una persona que habla mucho sobre GraphQL, a veces la gente te dirá que es malo, y se te acercarán públicamente, cuando podrías hacer eso, y hablarán sobre cómo GraphQL no es bueno. Pero muchas veces se saltan las cosas geniales que obtienes de los tipos. Entonces, en lo que respecta a la sinergia con TypeScript, absolutamente, puede generar automáticamente tipos para su aplicación front-end utilizando los tipos del esquema. Eso es una gran victoria porque no solo puede generarlo la primera vez, lo que le brinda una gran interoperabilidad con su aplicación frontal, sino que también, a medida que las cosas cambian, puede regenerar tipos y luego compilar para reflejar esos cambios. Así que sí, creo que esas cosas encajan muy bien juntas a medida que los tipos comienzan a ser una especie de regla de facto.

Eve: … para ser una especie de regla de facto en JavaScript, encajan muy bien juntos.

Drew: Parece ser una especie de tema en curso con la forma en que se ha diseñado TypeScript... eso no es TypeScript, lo siento. GraphQL ha sido diseñado para formalizar la interacción entre el front-end y el back-end. Y viene como una solución entre lo que solo crea consistencia y una formalización de lo que hasta ahora ha sido una experiencia bastante difícil con el descanso para mucha gente. Una cosa que siempre debemos tener en cuenta al escribir aplicaciones del lado del cliente es que el código está sujeto a inspección y posiblemente modificación. Y tener una API donde el cliente solo puede solicitar datos podría ser peligroso. Ahora, si puede especificar qué campos desea, tal vez eso podría ser peligroso. ¿En qué parte de la pila completa, se ocuparía de la autorización de los usuarios y se aseguraría de que se cumplan las reglas comerciales en torno a sus datos?

Eva: Te ocuparías de todo eso en el servidor. Entonces, eso podría suceder de muchas maneras diferentes. No tiene que usar una estrategia única, pero sus resolutores se encargarán de su autorización. Eso podría significar envolver una API REST existente, como un servicio como Auth0 o algo que haya creado por su cuenta. Eso podría significar interactuar con un OAuth, como el inicio de sesión de GitHub o Facebook o Google, ese tipo de cosas que implican pasar tokens de un lado a otro con los resolutores. Pero a menudo eso se integrará directamente en el esquema. Entonces, el esquema dirá, no sé, crearemos una mutación de inicio de sesión. Y luego envío esa mutación con mis credenciales y luego en el servidor, todas esas credenciales se verifican. Entonces el cliente no tiene que preocuparse tanto, tal vez un poco de pasar fichas y cosas así. Pero la mayor parte de eso está integrado en el servidor.

Drew: Básicamente, eso no cambia realmente en comparación con la forma en que estamos construyendo puntos finales de descanso en este momento. Resto como tecnología, bueno, en realidad tampoco se ocupa de la autorización y tenemos middleware y cosas en el servidor que se ocupan de eso. Y es lo mismo con GraphQL. Solo lidia con eso. ¿Existen convenciones en la comunidad de GraphQL para hacer eso? ¿Existen enfoques comunes o está por todas partes sobre cómo las personas eligen implementarlo?

Eva: Honestamente, está por todas partes. Creo que la mayoría de las veces verás gente construyendo en el Esquema y con eso quiero decir, representando esos tipos y usuarios autorizados frente a usuarios regulares construyendo esos tipos en el Esquema mismo. Pero también verá a muchas personas que usan soluciones de terceros. Mencioné Auth0. Mucha gente descargará su autorización en empresas que están más enfocadas en ello, particularmente empresas más pequeñas, nuevas empresas, cosas así. Pero también verá empresas más grandes que comienzan a crear soluciones para esto. Así que AWS, Amazon tiene AppSync, que es su versión de GraphQL, y tienen roles de autor integrados directamente en AppSync. Y eso es genial solo para poder, no sé, no tener que preocuparme por todas esas cosas o al menos proporcionar una interfaz para trabajar con eso. Entonces, muchas de estas herramientas del ecosistema tienen, creo que la autorización es un tema muy importante en GraphQL. Han visto la necesidad, la demanda de soluciones de autenticación y enfoques estándar para manejar la autenticación en el gráfico.

Drew: Supongo que apenas hay una implementación que no necesite algún tipo de autorización. Así que sí, va a ser un requisito bastante común. Todos estamos creando cada vez más aplicaciones en componentes, particularmente cuando usamos cosas React and View y lo que sea. Y el principio de acoplamiento débil nos deja con muchos componentes que no necesariamente saben qué más se ejecuta en la página a su alrededor. ¿Existe el peligro como resultado de eso, podría terminar con muchos componentes que consultan los mismos datos y realizan múltiples solicitudes? ¿O es solo un problema arquitectónico en su aplicación que necesita resolver para eso? ¿Hay alguna clase de soluciones trilladas para lidiar con eso?

Eve: Bueno, creo que GraphQL en su mayor parte, no el 100 % de las soluciones, pero casi todas las consultas de GraphQL se envían a través de HTTP. Entonces, si desea rastrear dónde están ocurriendo esas solicitudes múltiples, probablemente sea un problema bastante familiar para las personas que usan datos de descanso para sus aplicaciones. Entonces, hay algunas herramientas como Paulo Client Dev Tools y Urkel Dev Tools para desarrolladores front-end que dicen: “¿Qué está pasando? ¿Qué consultas hay en esta página?” Eso te da una idea muy clara de lo que está sucediendo. Hay una especie de varias escuelas de pensamiento con eso. ¿Creamos una consulta grande y enorme para todos los datos de la página? ¿O creamos consultas más pequeñas para cargar datos para diferentes partes de la aplicación? Ambos, como puede imaginar, tienen sus propios inconvenientes, solo porque si tiene una consulta grande, está esperando más campos.

Eve: Si tiene consultas más pequeñas, puede haber colisiones entre los datos que necesita. Pero creo, y para no salirme demasiado por la tangente, pero ya estoy ahí. Entonces, hay algo llamado Directiva diferida que viene a la especificación GraphQL y la Directiva diferida ayudará con la carga secundaria de contenido. Entonces, digamos que tiene algo de contenido en la parte superior de la página, el contenido súper importante que desea cargar primero. Si agrega eso a su consulta y luego cualquier campo posterior obtiene la directiva diferida sobre eso. Es solo un pequeño decorador que agregaría a un campo, que luego dirá: "Muy bien, cargue los datos importantes primero, luego espere y cargue los segundos datos en segundo lugar". Y de alguna manera te da esto, es la apariencia de una especie de transmisión de datos a tu front-end, de modo que hay un rendimiento percibido, hay interactividad. Las personas ven los datos de inmediato en lugar de esperar a que se carguen todos los campos de la página, lo que sí, podría ser un problema.

Drew: Sí. Supongo que eso te permite diseñar páginas donde todo lo que es... no nos gusta hablar demasiado sobre la ventana gráfica, pero es todo lo que se encuentra arriba de la página, puedes priorizar, tener esa carga y luego, en segundo lugar, cargar todo un poco más. abajo. Entonces, hemos hablado mucho sobre la consulta de datos. Uno de los trabajos principales de una API es enviar datos nuevos y modificados al servidor para su persistencia. Antes mencionaste brevemente las mutaciones. ¿Esa es la terminología que utiliza GraphQL para escribir datos en el servidor?

Eva: Exacto. Entonces, cualquier tipo de cambio que queramos hacer en los datos, cualquier cosa que queramos escribir en el servidor, esas son mutaciones, y todas son como consultas, son operaciones con nombre que viven en el servidor. Entonces, ¿puedes pensar en cuáles son todas las cosas que queremos que nuestros usuarios puedan hacer? Representar a aquellos con mutaciones. Y luego, de nuevo en el servidor, escribe todas las funciones que hacen que todo funcione.

Drew: ¿Y eso es tan simple como consultar datos? ¿Llamar a una mutación es igual de fácil?

Eva: Sí. Es parte del lenguaje de consulta. Se ve bastante idéntico. La única diferencia es, bueno, supongo que las consultas aceptan filtros. Entonces, las mutaciones tomaron lo que parecían filtros en la consulta misma. Pero esos son los responsables de cambiar los datos. Se puede enviar un correo electrónico y una contraseña con una mutación, y luego el servidor los recopila y luego los usa para autorizar al usuario.

Drew: Entonces, al igual que antes, está creando una resolución en el backend para lidiar con eso y hacer lo que sea necesario. Una ocurrencia común al escribir datos es que desea confirmar sus cambios y luego volver a consultar para obtener el tipo de estado actual. ¿Tiene GraphQL un buen flujo de trabajo para eso?

Eva: De alguna manera vive en la mutación misma. Entonces, muchas veces al crear su esquema, creará la operación de mutación. Me quedo con el inicio de sesión, toma el correo electrónico y la contraseña. Y la mutación misma devolvió algo. Entonces podría devolver algo tan simple como un valor booleano, esto salió bien, o esto salió mal, o podría devolver un tipo real. Entonces, a menudo verá la mutación como la mutación de inicio de sesión, tal vez devuelva un usuario. De modo que obtiene toda la información sobre el usuario una vez que inicia sesión. O puede crear un tipo de objeto personalizado que le brinde ese usuario más la hora en que inició sesión, y tal vez un poco más de metadatos sobre esa transacción en el objeto de devolución. . Entonces, nuevamente, depende de usted diseñar eso, pero ese patrón realmente está integrado en GraphQL.

Drew: Todo esto suena muy bien, pero cada elección técnica implica compensaciones. ¿Cuáles son las desventajas de usar GraphQL? ¿Hay algún escenario en el que sería una elección realmente mala?

Eve: Creo que el lugar donde un GraphQL podría tener problemas es creando un mapa uno a uno de-

Eva: … la lucha es crear un mapa uno a uno de datos tabulares. Así que digamos que tiene, no sé, piense en una tabla de base de datos con todo tipo de campos diferentes y, no sé, miles de campos en un tipo específico, cosas así, ese tipo de datos se puede representar muy bien con GraphQL, pero a veces, cuando ejecuta un proceso para generar un esquema en esos datos, se queda, en un esquema, con los mismos problemas que tenía en la base de datos, que tal vez son demasiados datos que van más allá de lo que el cliente en realidad requiere. Así que creo que esos lugares son potencialmente problemáticos. He hablado con personas que han generado esquemas automáticamente en función de sus datos y se ha convertido en un esquema de un millón de líneas o algo así, solo miles y miles de líneas de código de esquema. Y ahí es donde se vuelve un poco complicado, como ¿cuán útil es esto como un documento legible por humanos?

Eva: Sí. Entonces, cualquier tipo de situación en la que esté tratando con un cliente, encaja muy bien en cuanto a modelar cada tipo diferente de datos, se vuelve un poco complicado si sus fuentes de datos son demasiado grandes.

Drew: Así que parece que en cualquier lugar en el que vas a curar cuidadosamente las respuestas en los campos y hacerlo más a mano, puedes obtener resultados realmente poderosos. Pero si está generando cosas automáticamente porque acaba de obtener un esquema masivo, entonces tal vez se vuelva un poco difícil de manejar.

Eva: Sí. Y creo que la gente me escucha y no está de acuerdo conmigo porque también hay buenas herramientas para eso. Pero creo que el lugar donde GraphQL realmente brilla es ese paso de abstraer la lógica del servidor, dando a los desarrolladores front-end la libertad de definir sus componentes o los requisitos de datos de sus front-end, y realmente administrar el esquema como un equipo.

Drew: ¿Hay algo integrado en el lenguaje de consulta para lidiar con la paginación de los resultados, o se debe a una implementación personalizada según sea necesario?

Eva: Sí. Paginación, primero se integraría en el esquema, por lo que podría definir la paginación para eso. Hay muchas pautas que han surgido en la comunidad. Un buen ejemplo para ver si eres nuevo en GraphQL o no, lo veo todo el tiempo, es la API de GitHub GraphQL. Básicamente, han recreado su API para v4 de su API pública usando GraphQL. Así que ese es un buen lugar para ver cómo una gran empresa real usa esto a escala. Mucha gente tiene grandes API en ejecución, pero no las hacen públicas para todos. Entonces, la paginación está integrada en esa API muy bien y puede devolver, no sé, los primeros 50 repositorios que haya creado, o también puede usar la paginación basada en cursor para devolver registros basados ​​en ideas en sus datos. Por lo tanto, la paginación basada en el cursor y el tipo de paginación posicional como el primer y el último registro, por lo general, así es como la gente lo aborda, pero hay muchas técnicas.

Drew: ¿Hay algún error importante que debamos saber al usar GraphQL? Digamos que estoy a punto de implementar una nueva instalación de GraphQL para mi organización, vamos a construir todos nuestros nuevos puntos finales de API utilizando GraphQL en el futuro. ¿Qué debo saber? ¿Hay algo al acecho en los arbustos?

Eva: Acechando en los arbustos, siempre con tecnología, ¿verdad? Creo que una de las cosas que no está integrada en GraphQL, pero que se puede implementar sin demasiados problemas, es la seguridad de la API. Entonces, por ejemplo, mencionó que si tengo una gran consulta, hablamos de esto con autorización, pero también da miedo abrir una API donde alguien podría enviar una gran consulta anidada, amigos de amigos, amigos de amigos, amigos de amigos , abajo y abajo de la cadena. Y luego básicamente estás permitiendo que la gente te haga DDoS con estas enormes consultas. So there's things that you can set up on the server to limit query depth and query complexity. You can put queries on a safe list. So maybe your front ends, you know what they all are and it's not a public API. So you only want to let certain queries come over the wire to you. So I would say before rolling that out, that is definitely a possible gotcha with the GraphQL.

Drew: You do a lot of instruction and training around GraphQL, and you've co-written the O'Reilly 'animal' book with Alex Banks called Learning GraphQL. But you've got something new that you're launching early in 2021, is that right?

Eve: That's right. So I have been collaborating with egghead.io to create a full stack GraphQL video course. We're going to build an API and front end for a summer camp, so everything is summer camp themed. And yeah, we're just going to get into how to work with Apollo server, Apollo client. We will talk about scaling GraphQL APIs with Apollo Federation. We'll talk about authorization strategies and all sorts of different things. So it's just kind of collecting the things that I've learned from teaching over the past, I don't know, three or four years GraphQL and putting it into one spot.

Drew: So it's a video course that… Is it all just self-directed, you can just work your way through at your own pace?

Eve: Yeah, exactly. So it's a big hefty course so you can work through it at your own pace. Absolutamente.

Drew: Oh, that sounds really good. And it's graphqlworkshop.com, is that right?

Eve: Graphqlworkshop.com, exactly.

Drew: And I'm looking forward to seeing that released because I think that's something that I might need. So I've been learning all about GraphQL. What have you been learning about lately?

Eve: I've also been looking into Rust lately. So I've been building a lot of Rust Hello Worlds, and figuring out what that is. I don't know if I know what that is yet, but I have been having fun tinkering around with it.

Drew: If you dear listener, would like to hear more from Eve, you can find her on Twitter where she's @eveporcello, and you can find out about her work at moonhighway.com. Her GraphQL workshop, discover your path through the GraphQL wilderness, is coming out early in 2021 and can be found at graphqlworkshop.com. Thanks for joining us today, Eve. ¿Tienes alguna palabra de despedida?

Eve: Parting words, have fun with GraphQL, take the plunge, you'll enjoy it, and thanks so much for having me. I appreciate it.