Como con cualquier elección tecnológica, elegir GraphQL como estilo de API implica compromisos. Algunos nos dicen que GraphQL está aquí para reemplazar todo lo demás, otros nos dicen que usar GraphQL es un error. En esta charla, exploraremos por qué ambas cosas son falsas y cómo todo depende del contexto.
Video Summary and Transcription
La charla de hoy explora los matices de GraphQL y cómo su efectividad depende del contexto. La caché es un tema polarizador en GraphQL, pero existen herramientas disponibles para la caché. El compromiso por la flexibilidad del lado del cliente en GraphQL afecta la previsibilidad del rendimiento. GraphQL como backend para frontend ofrece flexibilidad pero limita el desacoplamiento real. Es importante considerar el contexto y los compromisos al decidir si usar GraphQL o REST. El orador enfatiza la necesidad de mejores conversaciones y comprender los matices de GraphQL.
Available in English
1. Introducción a GraphQL y Caché
Short description:
La charla de hoy se llama 'Depende'. Exploraremos las discusiones matizadas sobre GraphQL y cómo su efectividad depende del contexto. La caché es un tema polarizador en GraphQL. Algunos dicen que es imposible de cachear, mientras que otros dicen que no es una preocupación. Vamos a adentrarnos en ello. Los clientes de GraphQL tienen cachés normalizadas potentes y los resolvers del backend también se pueden cachear. Sin embargo, el desafío radica en la caché HTTP y la ausencia de cachés HTTP compartidas. La caché compartida permite reutilizar respuestas entre diferentes clientes y servidores.
¡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
2. Caché en APIs Autenticadas
Short description:
Esto permite que un cliente asuma el costo de calcular una respuesta y otros clientes simplemente la obtengan de forma gratuita. El problema es la especificación misma de HTTP, que dice que si tienes un encabezado de autorización, las cachés compartidas no deben almacenar en caché. 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é. 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 para ser utilizadas, por lo que es posible que no marque una gran diferencia para ti.
diferentes clientes y en diferentes servidores. Esto permite que un cliente asuma el costo de calcular una respuesta y otros clientes simplemente la obtengan de forma gratuita. Esto es genial. Siempre deberíamos esforzarnos por tener una caché así si podemos. El problema es la especificación misma de HTTP, que dice que si tienes un encabezado de autorización, las cachés compartidas no deben almacenar en caché. Puede parecer un poco extraño si solo lees la especificación, pero si lo piensas, tiene mucho sentido porque no quieres almacenar en caché cosas que son específicas de un usuario y servirlas de forma compartida a otros clientes. La idea de una caché compartida en el contexto de una API autenticada realmente no tiene mucho sentido.
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
3. Caching, Rendimiento y Optimización de Consultas
Short description:
La flexibilidad de GraphQL conlleva un compromiso en la caché. Sin embargo, este compromiso no es exclusivo de GraphQL y también se puede encontrar en otros tipos de API. El rendimiento es otra consideración, y aunque GraphQL no siempre es más rápido que REST en todos los casos de uso, ofrece ventajas en el manejo de los requisitos cambiantes de las aplicaciones. Además, la eficiencia de REST en la transferencia de datos hipermedia de gran tamaño puede no estar alineada con los objetivos de GraphQL. La idea de que una consulta siempre es más rápida no es universalmente cierta, ya que las consultas grandes pueden presentar desafíos de optimización en el lado del servidor.
El uso de caché es importante y debería ser utilizado siempre que sea posible, por lo que es posible que no marque una gran diferencia para ti. La otra parte de GraphQL que es un poco más difícil de cachear es el hecho de que es tan flexible, ¿verdad? Incluso si tuviéramos una caché compartida con GraphQL, si los clientes estuvieran haciendo consultas de diferentes maneras, cachear una respuesta no sería tan bueno si no muchos clientes usan lo mismo de todos modos. Entonces, ese es un costo que viene con la flexibilidad. Pero no es exclusivo de GraphQL, ¿verdad? Puedes escribir APIs REST flexibles. Puedes escribir APIs gRPC flexibles. La realidad aquí es más un compromiso entre escribir algo que sea adecuado para todos los clientes pero altamente cachable, o algo super flexible donde perdamos algo de caché. Entonces, la sutileza está realmente aquí. Y volviendo a la API autenticada que necesita menos caché compartida, tal vez un buen ejemplo de eso sea algún tipo de plataforma de redes sociales. Y si lo piensas, si piensas en una famosa plataforma de redes sociales que inventó una capa de API como GraphQL, comienza a tener mucho sentido. Pasemos al rendimiento. El rendimiento es otro tipo de caja de Pandora. Aquí hay otra cosa que escuchamos. Escuchamos a personas que se pasan a GraphQL por razones de rendimiento. Pero, ¿qué significa eso? ¿Usar GraphQL instantáneamente implica un impulso de rendimiento para nuestras APIs? No necesariamente. Entonces, dependiendo del contexto, ¿creemos que GraphQL es más rápido que REST en general? A veces leemos eso, sí, es más rápido por diferentes razones. Pero si echas un vistazo a este ejemplo realmente tonto, digamos que nuestra API solo puede hacer una cosa. Y es obtener el usuario actual, nombre y edad, ¿cuál crees que sería más rápido aquí, una consulta GET para un usuario que está muy optimizada en su propia definición de punto final o el sobrecosto de un motor de GraphQL, analizando, validando y ejecutando una consulta como esta? En este caso específico, apostaría por la API REST porque la API REST sabe de antemano cuál es un caso de uso y no tiene ese sobrecosto de ejecución. Pero, por supuesto, en el mundo real, es probable que tu aplicación no tenga solo un caso de uso. Y a medida que tu aplicación evoluciona, también evolucionan cada vez más casos de uso, y el enfoque de talla única de la API REST, por ejemplo, no es necesariamente lo mejor para cada cliente individual. Entonces, este es incluso un compromiso que REST mismo reconoce. No está en el negocio de optimizarse para cada cliente individual. Quiere ser eficiente para la transferencia de datos hipermedia de gran tamaño. Entonces, no es óptimo para lo que GraphQL quiere hacer, y eso está totalmente bien. Otra cosa que escuchamos es que una consulta nos beneficiará mucho, porque en el pasado, cuando las personas tenían APIs REST, tenían que hacer muchas consultas diferentes a los recursos. Seguir enlaces como hipermedia podía ser muy lento. Con HTTP2 y HTTP3, incluso ese costo se está volviendo cada vez más bajo. Pero aún podrías argumentar que una consulta podría ser más rápida en muchos contextos. Pero eso tampoco siempre es cierto. Cuando usas GraphQL, tal vez estés trabajando en una página grande, tu única consulta que era más rápida puede volverse muy, muy, muy grande. Y optimizar esa consulta en el lado del servidor se vuelve más difícil y más difícil.
4. Parallel Fetching and Trade-offs
Short description:
Algunas personas podrían pensar que estamos dando vueltas con GraphQL, pero eso no es cierto. Todavía podemos crear diferentes casos de uso desde el lado del cliente utilizando consultas declarativas. Con las nuevas directivas defer y stream, hemos hecho compromisos, pero podemos mitigar las desventajas.
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.
5. Rendimiento y Compensaciones en GraphQL
Short description:
El rendimiento en GraphQL es menos predecible debido a la compensación por la flexibilidad del lado del cliente. Depende del caso de uso específico, pero la apuesta es que los beneficios de la desvinculación del cliente y la oferta de esquema superan los posibles costos adicionales.
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.
6. GraphQL como Backend para Frontend
Short description:
GraphQL como backend para frontend ofrece flexibilidad en la representación, pero no proporciona autonomía completa entre los equipos. Los tipos y campos aún se comparten, lo que limita la desvinculación real. GraphQL se esfuerza por tener un solo servidor, mientras que los BFF permiten una separación completa y elección de tecnología. Un solo gráfico ofrece beneficios, pero requiere una consideración cuidadosa para evitar esquemas de talla única. Los campos específicos del cliente y las representaciones de usuario diferentes pueden ser una preocupación. El éxito de GraphQL es importante para nosotros en esta conferencia de GraphQL.
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?
7. Los matices de GraphQL
Short description:
Para que GraphQL tenga éxito, es importante tener mejores conversaciones y no recomendarlo donde otra cosa sería mejor. Debemos considerar el contexto, compararlo con otras opciones y entender los compromisos. Gracias por asistir a mi charla. Si estás interesado en aprender más, echa un vistazo a mi libro, Production-Ready GraphQL, y sígueme en Twitter.
Creo que todos queremos que GraphQL tenga éxito. Estamos en una conferencia de GraphQL. Todos somos entusiastas de GraphQL. Yo lo soy. Y una cosa que es muy importante para mí, para que GraphQL tenga éxito, es que los desarrolladores que usan GraphQL también tengan éxito. Y una forma de lograrlo es no recomendar GraphQL donde otra cosa sería mucho mejor para el caso de uso, y también no permitir que alguien que tal vez sea un entusiasta de REST diga que la caché nunca puede funcionar con GraphQL. Por lo tanto, es importante darse cuenta de todos estos matices para tener mejores conversaciones.
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.
8. REST vs GraphQL: Casos de Uso Adecuados
Short description:
En ciertos casos, REST puede ser una opción más adecuada que GraphQL. Por ejemplo, una API pública con datos estáticos, como una lista de países y su población, puede beneficiarse de las capacidades de caché compartida de HTTP. Si bien GraphQL también puede manejar este escenario, REST puede ser más adecuado debido a sus convenciones y gramática existentes.
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
9. Preocupaciones con una API pública de GraphQL
Short description:
Tener una API pública de GraphQL ofrece increíbles posibilidades para los clientes, pero también existen preocupaciones. Es importante encontrar un equilibrio entre los tipos genéricos y los campos específicos del caso de uso. Esta sutileza es desafiante, pero nos enfocamos en hacerlo bien.
gramática existente para obtener lo que necesitas. Así es. Bueno, tenemos una pregunta de Rana. ¿Has visto alguna preocupación al tener una API pública de GraphQL? Sé que GitHub fue uno de los primeros en proporcionar una. No verifiqué los hechos, pero confío en nuestras preguntas y respuestas. Sí, creo que GitHub fue uno de los primeros, al menos. Y sí, definitivamente no es algo fácil de proporcionar. Ofrece increíbles posibilidades para nuestros clientes y por eso lo hacemos. Pero definitivamente hay preocupaciones de las que debemos cuidarnos. La principal para mí es ese aspecto que cubrimos en la charla, donde debes tener cuidado de no proporcionar una API de GraphQL que sea similar a lo que teníamos con REST, con tipos que no son muy útiles para ningún cliente específico, pero lo suficientemente genéricos como para ser utilizables por todos. Por lo tanto, el equilibrio aquí es que necesitamos mantenernos un poco en el lado genérico porque no sabemos quiénes son todos nuestros clientes, pero también queremos escuchar muy bien los casos de uso y proporcionar campos específicos del caso de uso al mismo tiempo. Por lo tanto, esta sutileza es muy difícil de lograr correctamente. Y es algo en lo que intentamos enfocarnos.
10. Mecanismos de Caché y Planes Futuros
Short description:
Los mecanismos de caché utilizados en la API pública de GraphQL en GitHub no son nada mágicos o únicos. El enfoque principal es utilizar un cargador de datos para agrupar las llamadas a servicios externos y cachear las llamadas realizadas durante la ejecución de la consulta. Esto garantiza que las consultas no sobrecarguen las bases de datos. Si bien GraphQL es una herramienta poderosa, puede que no sea la mejor opción para escenarios que involucren el manejo de archivos, donde HTTP y la caché son más adecuados. A pesar de los desafíos de escribir un libro, el orador está interesado en explorar los matices de GraphQL a través de diálogos en una futura publicación. La hoja de ruta de GraphQL en GitHub se está mejorando continuamente y se valora mucho el feedback de los usuarios.
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.
