Depende: Examinando los mitos y suposiciones de GraphQL

¡Hola de nuevo a todos! Gracias por venir a ver mi charla. Hoy mi charla se llama 'Depende'. Puede sonar un poco aburrido, y tal vez lo sea, pero veremos. Vamos a examinar cómo hay ciertas discusiones sobre GraphQL que hoy en día escuchamos como totalmente verdaderas o totalmente falsas. Pero hay muchas cosas sobre GraphQL que simplemente dependen mucho del contexto en el que te encuentres y tienen mucho matiz. Así que vamos a adentrarnos en todo eso. Mi nombre es Mark. Trabajo en GitHub y soy de Montreal, Canadá. Entonces, 'Depende'. ¿Qué quiero decir con eso? Como dije antes, con GraphQL hay algunos temas que veremos hoy que algunas personas dicen que no se pueden hacer con GraphQL, o que GraphQL es la mejor solución para ellos. Pero en realidad, algo que he notado al trabajar con muchas personas diferentes, en diferentes lugares y con GraphQL, es que el contexto en el que tomamos estas decisiones es mucho más importante que GraphQL versus REST, o GraphQL versus gRPC, o este tipo de cosas.

Y lo primero de lo que quiero hablar es de la caché. Ya he hablado de esto antes. Entonces, si has visto alguna de mis charlas anteriores sobre caché, puede que haya un poco de repetición aquí, pero creo que es uno de los temas más interesantes en torno a GraphQL porque es un tema tan polarizado. Por un lado, escuchas a algunas personas decir que cachear GraphQL es literalmente imposible. Por otro lado, algunas personas dicen que no es una preocupación en absoluto. Así que vamos a adentrarnos en ello. Cuando hablamos de caché, y cuando escuchamos que GraphQL es difícil de cachear, a veces es un poco difícil de entender por qué. Porque en el lado del cliente, cualquier cliente de GraphQL que veas tiene cachés normalizadas potentes en el lado del cliente con muchas características. Y en el lado del backend, bueno, estamos usando lenguajes de programación regulares. Podemos cachear lo que queramos, los resolvers son solo funciones. Y tenemos herramientas como DataLoader que nos permiten cachear la carga de datos, lo cual es genial. Así que es difícil decir realmente qué es lo difícil al respecto cuando tenemos tantas buenas herramientas para hacerlo. La realidad es que cuando las personas dicen que la caché es difícil, generalmente hablan de una caché diferente a la que acabamos de ver. Hablan de la caché HTTP. Y en particular, lo que dicen que falta son las cachés HTTP compartidas. Si nunca has oído hablar de esto, en realidad es un mecanismo bastante complejo, pero el problema en sí es bastante básico de explicar. Cuando los clientes generalmente acceden a tu servidor GraphQL, obtienen una respuesta. Con una caché compartida, puedes cachear estas respuestas y reutilizarlas. Debido a que es compartida, puedes reutilizar estas respuestas entre

Si tenemos todas estas excelentes herramientas para hacer caché donde podemos y tienes una API autenticada, ¿realmente importa? Bueno, tal vez importe un poco, pero no es el fin del mundo como vimos en la conversación anterior donde alguien dice que literalmente no deberías usar GraphQL porque pierdes la caché. Si tu API es una API autenticada y maneja muchos datos en vivo que simplemente no puedes permitir que estén obsoletos, bueno, no estamos perdiendo tanto. No estamos perdiendo esa poderosa caché compartida porque de todos modos nos habría sido útil. Entonces, creo que lo primero de lo que quiero hablar aquí es cómo cada contexto específico informa mucho si GraphQL es una buena opción o no tan buena opción. Pero también hay algo de verdad en ello en el sentido de que la caché de HTTP en sí misma se basa en convenciones. Tenemos años de experiencia con la caché de HTTP. Los navegadores lo entienden nativamente. Muchos clientes lo entienden. Con GraphQL, como viste, necesitamos construir esos clientes inteligentes con cachés normalizadas. Pero estas herramientas están construidas y están listas

Y si parte de esa recuperación de consulta se pudiera obtener en paralelo, tal vez ahora desearías tener diferentes recursos que se puedan obtener en paralelo a través de HTTP2. Entonces, ¿qué hacemos entonces? Bueno, ya hablaste antes hoy sobre las nuevas directivas defer y stream. Estas están exactamente ahí para ese problema. Cuando tenemos consultas declarativas grandes, no significa que queramos que todo se calcule antes de recibirlo. Tal vez queremos obtener cosas diferentes en paralelo o obtener algo primero. Entonces, en este punto, algunas personas podrían pensar ¿no estamos volviendo al punto de partida aquí? ¿Por qué no estamos definiendo recursos? Pero eso no es del todo cierto porque todavía tenemos la consulta declarativa, eso es increíble. Todavía tenemos la capacidad de crear diferentes casos de uso desde el lado del cliente. Entonces, aquí es donde con el defer y el stream y manteniendo GraphQL, hemos hecho compromisos, pero si hacemos compromisos, no significa que lo que sacrificamos sea absolutamente cero. Todavía podemos mitigar las desventajas y eso es exactamente lo que hacemos con cosas como defer.

Una cosa que es cierta, desafortunadamente para GraphQL, es que el rendimiento es mucho menos predecible que si tuvieras casos de uso bien definidos por el servidor. Pero nuevamente, esa es la compensación que hacemos por la flexibilidad en el lado del cliente. Entonces, en cuanto al rendimiento, como puedes ver, depende mucho del contexto. Depende de tu caso de uso específico, pero con GraphQL, hacemos una apuesta de que tendremos diferentes casos de uso que son difíciles de manejar con algo como puntos finales ad hoc en el lado del servidor, y queremos esa desvinculación del cliente y la oferta de un esquema, incluso si puede tener algún costo adicional, hemos decidido que la compensación vale la pena.

Lo último de lo que quiero hablar es la idea de GraphQL como un backend para frontend. Si no estás familiarizado con el patrón de backend para frontend, es un patrón en el que los equipos definen su propia API para su propia experiencia. Aquí puedes ver que el equipo A tiene una aplicación iOS, y también tienen un BFF, un servidor de API adaptado exactamente a sus necesidades. Lo mismo ocurre con la aplicación de Android. A primera vista, esto parece algo en lo que GraphQL podría ser excelente. Ofrece flexibilidad para que la aplicación iOS consuma un conjunto diferente de datos que la aplicación de Android, desvinculando al servidor de tener que definir tal vez un punto final para iOS y otro para Android. La realidad es que, los BFF, el patrón de backend para frontend, no se trata solo de la representación, no solo de la respuesta o los recursos que estamos creando, sino que también se trata de la autonomía completa de los equipos. Es importante darse cuenta de que mientras GraphQL puede ofrecernos ese beneficio en términos de representación, no ofrece una autonomía completa entre los equipos. Los tipos aún se comparten. Los campos aún se comparten. Y si observamos esta consulta, por ejemplo, disculpen la F mayúscula en friends aquí, si realmente quisiéramos que las cosas fueran diferentes, tal vez tendríamos que hacer algo como esto donde tal vez tengas un nombre, pero tienes un nombre para Android y tienes una edad y tienes una edad para este otro cliente. Eso sería una verdadera desvinculación de estos campos, pero no podemos asegurarlo necesariamente. Eso puede ser algo molesto de GraphQL. Algo puede ser increíble porque compartimos ese gráfico, que puede ofrecer consistencia. Pero es importante darse cuenta de que no es un reemplazo exacto para BFF, que también es un patrón cultural y un patrón de autonomía completa. Y en GraphQL estamos en una especie de zona intermedia donde los clientes pueden seleccionar una representación, pero aún la seleccionan desde una base común.

Esa separación completa también tiene otros significados en el sentido de que con los BFF, puedes escribir uno en Go, escribir uno en Ruby, escribir uno en Java. Con GraphQL, a menudo nos esforzamos por tener un solo servidor GraphQL. Por lo tanto, podría compartir los mismos límites de velocidad, el mismo conjunto de middlewares. Mientras que con los BFF, tienes una separación completa y puedes elegir cualquier tecnología que desees. Así que creo que es importante darse cuenta de que, no significa que los BFF sean mejores que GraphQL y lo contrario, sino que implican cosas muy diferentes. Y la idea de tener un solo gráfico, que es muy popular y tiene mucho sentido, tiene muchos beneficios tener un solo gráfico con el que todos los clientes pueden integrarse y tener esa única fuente de verdad para nuestro dominio tiene un solo esquema. Pero también conlleva la responsabilidad de no volver a la idea de talla única que temíamos con REST, y definir un esquema que sea el mismo para todos los clientes. Por lo tanto, no podemos dudar aquí. Y realmente, agregar campos específicos del cliente debería ser una preocupación con GraphQL, para tratar de evitar reutilizar las mismas cosas. Y otro peligro con la idea de un solo gráfico es que mientras que los BFF podrían tener una representación completamente diferente de un usuario, por ejemplo, aquí, aún estamos compartiendo el mismo tipo de usuario, y tal vez un usuario en el mundo de Android es diferente, o en Xbox, un usuario es completamente diferente. Así que debemos tener eso en cuenta. Como puedes ver, muchas cosas dependen de GraphQL. ¿Y qué quiero decir con todo esto? ¿Y por qué creo que es importante pensar en esto?

Y sí, realmente no quiero animar a alguien que tiene un caso de uso perfecto para el patrón de backend y frontend y REST a usar simplemente GraphQL en su lugar. Así que creo que queremos recomendar, queremos poder saber cuándo GraphQL es el punto óptimo o no, y tomar decisiones basadas en eso. Así que aquí hay algunas preguntas que me gusta hacer en cada decisión. Entonces, ¿en qué contexto es esto mejor o no? Como puedes ver, la misma API pero autenticada en público versus tal vez una API privada y no autenticada en público, y tal vez una API privada y autenticada cambia completamente la situación de la caché. En comparación con qué también es una gran pregunta. Entonces tal vez esto sea mejor, pero en comparación con qué? Porque cuando elegimos algo, siempre lo elegimos en comparación con algo más. Por lo tanto, estamos dejando algo más en la mesa, y eso algo más puede afectar nuestra decisión. Decir que GraphQL es lo mejor sin comparación no ayuda a nadie y no tiene sentido. Y finalmente, ¿cuáles son los compromisos? ¿Qué estamos dejando en la mesa al tener un lenguaje de consulta tan flexible? ¿Existen formas de mitigar lo que estamos dejando para que no sea tan malo como abandonar completamente el otro lado? Muchas gracias. Esa fue mi charla. Si estás interesado en estos compromisos y quieres saber cuál es la mejor manera de lidiar con ellos, tengo este libro llamado Production-Ready GraphQL. Tengo un 30% de descuento para los Galaxias de GraphQL como cupón si quieres usarlo. Tengo el programa llamado GraphQL FM que puedes ver. Nos reunimos con muchos expertos en GraphQL casi todas las semanas y sígueme en Twitter. Muchas gracias a todos.

Entonces, desafortunadamente, tenía esta maravillosa pregunta preparada diciendo, sabes, depende de una pregunta basada en juicio y cómo pueden las personas aprender a tomar estas decisiones. Pero al final lo dejaste todo de lado, oh, tengo un libro para ayudarte con eso, así que estoy muy, muy decepcionado. En su lugar, voy a hacer esta pregunta. ¿Cuál es un buen ejemplo donde REST sea la elección adecuada y GraphQL no lo sea? Así que te daré el ejemplo que siempre doy, y no significa que GraphQL sería completamente terrible en ese contexto, pero creo que es tal vez un punto más dulce para REST. Es una API pública con data que no necesariamente cambia entre diferentes usuarios autenticados. Entonces mi ejemplo favorito es una lista de países, por ejemplo. Si tienes una lista de todos los países y su población y todo, es data que es muy estable y que no cambia a menudo, es data que es igual para todos, y ahí es donde una caché compartida utilizando las convenciones de HTTP en su máximo potencial suele ser el punto óptimo aquí. Por supuesto, también puedes hacer eso con GraphQL pero es más el punto óptimo. Porque puedes aprovechar esta maravillosa

Suena como un problema clásico de tratar de encontrar el nivel adecuado de abstracción para describir mejor las estructuras de datos disponibles. Absolutamente. Los mismos problemas en todas partes, ¿verdad?

Tenemos una pregunta de Bastian. Esto va a pedir una primicia, así que te dejo a ti responder o no. ¿Cuántas personas están utilizando realmente el gráfico, la API pública de GraphQL en GitHub? ¿Qué tipo de mecanismos de caché utilizamos? Sí, no puedo responder a la pregunta de los números, pero puedo responder a la pregunta de la caché. Así que en realidad, ese fue un buen tema del que hablamos en el panel anterior. Pero no hacemos nada muy, muy mágico para la caché que no se pueda ver en ningún otro lugar. Nuestra forma principal de caché es utilizar un enfoque de cargador de datos. Así que, en primer lugar, agrupamos las llamadas a nuestros servicios externos, pero también cachéamos las llamadas que ya hemos realizado durante la ejecución de una consulta. Así que tenemos cuidado de no quedarnos atrapados en ciclos extraños donde consultamos demasiados datos o donde consultas enormes sobrecargan nuestras bases de datos. Sí, es una buena respuesta. Y muestra que no tienes que hacer nada demasiado complicado para ejecutar una API de GraphQL, incluso a una escala bastante grande, imagino. Sí, definitivamente tenemos una gran escala. Y lo bueno es que antes de la API de GraphQL, teníamos una gran API REST. También teníamos una gran interfaz web. Así que creo que afortunadamente, confiamos mucho en lo que nuestro equipo de bases de datos ha estado haciendo durante años, en lo que nuestro equipo de infraestructura ha estado haciendo durante años. Así que en el lado de GraphQL, lo más importante es asegurarnos de no olvidarnos de usar el cargador de datos. Ese es el mayor peligro que intentamos evitar.

Tenemos una pregunta de Juan. ¿Podrías mencionar algunos ejemplos o escenarios comunes y no tan excepcionales donde definitivamente GraphQL no sería la mejor opción? Bueno, creo que ya hice esta pregunta, así que tal vez ya la haya robado a todos, pero también la he escrito. Sí, creo que ese es el ejemplo básico que tengo en mente. Otro ejemplo es cualquier cosa que tenga que ver... Si estás lidiando con archivos, por ejemplo, HTTP es genial para lidiar con la obtención de archivos y usar la caché allí. Obtener un archivo a través de un campo de GraphQL, por ejemplo, funciona, pero no es tan adecuado como obtener un punto final y obtener un archivo de vuelta.

Increíble. Genial. ¿Vas a escribir más libros ahora? ¿Lograste comprometerte con uno o la experiencia te ha desanimado de escribir más literatura sobre GraphQL? Es el tipo de cosa que parece que después de haber escrito uno, dices que nunca volverás a hacerlo, pero al final, creo que realmente quiero escribir otro. Un tema que me interesa mucho es el tema de mi charla. Así que una cosa en la que he estado investigando es este libro que tiene estos diálogos que tuve en la charla. Diálogos entre diferentes personajes y explorando los matices de todos estos temas, así que estén atentos a eso.

¿Y puedes contarnos qué se viene en la hoja de ruta de GraphQL en GitHub, o es completamente secreto? No puedo decir nada seguro, pero siempre lo estamos mejorando, así que estén atentos. Y realmente nos gustaría recibir sus comentarios también. Si hay algo que sienten que falta en una API de GraphQL, tal vez características que están presentes en nuestra interfaz de usuario y no en GraphQL, definitivamente comuníquense con nosotros, nos estamos enfocando en mejorarlo.

Perfecto. Creo que he logrado agotar todas las preguntas que tengo, y hemos satisfecho todas las preguntas en la sesión de preguntas y respuestas, así que creo que... Lo que vamos a hacer es dejarte ir después de pasar horas hablando desde un panel encantador hasta una charla y ahora todos nosotros aquí, y voy a pasar a un pequeño descanso y nos veremos pronto.