Depende: Examinando los mitos y suposiciones de GraphQL

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

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.

This talk has been presented at GraphQL Galaxy 2020, check out the latest edition of this Tech Conference.

FAQ

GraphQL es una tecnología para construir APIs que permite solicitudes más flexibles y eficientes. Es importante considerar el contexto de su implementación porque, dependiendo del entorno y los requisitos específicos, GraphQL puede ser más o menos adecuado que otras tecnologías como REST o gRPC, especialmente cuando se trata de gestión de caché y personalización de respuestas.

El caché de GraphQL es considerado complicado principalmente debido a su flexibilidad y la naturaleza dinámica de las consultas, lo que puede dificultar la implementación de cachés HTTP compartidas. Las normas HTTP establecen restricciones adicionales sobre el caché de respuestas que incluyen datos autenticados, lo cual es común en las APIs de GraphQL.

En GraphQL, se pueden utilizar herramientas como DataLoader para optimizar la carga de datos y manejar la caché internamente. Además, aunque el caché HTTP compartido es limitado, se pueden implementar cachés normalizadas en el cliente para mejorar el rendimiento y la eficiencia.

REST puede ser más adecuado que GraphQL para APIs públicas que manejan datos que no varían entre usuarios y que son altamente cachables utilizando las convenciones HTTP, como una lista de países. En estos casos, REST puede aprovechar mejor las capacidades de caché HTTP compartido.

Una API pública de GraphQL puede ser desafiante porque debe ser suficientemente genérica para atender a todos los clientes pero específica para casos de uso particulares. Equilibrar la flexibilidad y la especificidad sin comprometer la seguridad y el rendimiento puede ser complicado.

No necesariamente. La idoneidad de GraphQL depende del caso específico y del contexto. Mientras ofrece flexibilidad y permite adaptar las respuestas a las necesidades del cliente, también puede introducir complejidades y desafíos, especialmente en términos de rendimiento predictivo y gestión de caché.

Marc-André Giroux
Marc-André Giroux
25 min
02 Jul, 2021

Comments

Sign in or register to post your comment.
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.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

De GraphQL Zero a GraphQL Hero con RedwoodJS
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
De GraphQL Zero a GraphQL Hero con RedwoodJS
Top Content
Tom Pressenwurter introduces Redwood.js, a full stack app framework for building GraphQL APIs easily and maintainably. He demonstrates a Redwood.js application with a React-based front end and a Node.js API. Redwood.js offers a simplified folder structure and schema for organizing the application. It provides easy data manipulation and CRUD operations through GraphQL functions. Redwood.js allows for easy implementation of new queries and directives, including authentication and limiting access to data. It is a stable and production-ready framework that integrates well with other front-end technologies.
Estado Local y Caché del Servidor: Encontrando un Equilibrio
Vue.js London Live 2021Vue.js London Live 2021
24 min
Estado Local y Caché del Servidor: Encontrando un Equilibrio
Top Content
This Talk discusses handling local state in software development, particularly when dealing with asynchronous behavior and API requests. It explores the challenges of managing global state and the need for actions when handling server data. The Talk also highlights the issue of fetching data not in Vuex and the challenges of keeping data up-to-date in Vuex. It mentions alternative tools like Apollo Client and React Query for handling local state. The Talk concludes with a discussion on GitLab going public and the celebration that followed.
Baterías Incluidas Reimaginadas - El Resurgimiento de GraphQL Yoga
GraphQL Galaxy 2021GraphQL Galaxy 2021
33 min
Baterías Incluidas Reimaginadas - El Resurgimiento de GraphQL Yoga
Envelope is a powerful GraphQL plugin system that simplifies server development and allows for powerful plugin integration. It provides conformity for large corporations with multiple GraphQL servers and can be used with various frameworks. Envelope acts as the Babel of GraphQL, allowing the use of non-spec features. The Guild offers GraphQL Hive, a service similar to Apollo Studio, and encourages collaboration with other frameworks and languages.
Aplicaciones sólidas de React y GraphQL para personas con prisa
GraphQL Galaxy 2022GraphQL Galaxy 2022
29 min
Aplicaciones sólidas de React y GraphQL para personas con prisa
The Talk discusses the challenges and advancements in using GraphQL and React together. It introduces RedwoodJS, a framework that simplifies frontend-backend integration and provides features like code generation, scaffolding, and authentication. The Talk demonstrates how to set up a Redwood project, generate layouts and models, and perform CRUD operations. Redwood automates many GraphQL parts and provides an easy way for developers to get started with GraphQL. It also highlights the benefits of Redwood and suggests checking out RedwoodJS.com for more information.
Adoptando GraphQL en una Empresa
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
Adoptando GraphQL en una Empresa
Today's Talk is about adopting GraphQL in an enterprise. It discusses the challenges of using REST APIs and the benefits of GraphQL. The Talk explores different approaches to adopting GraphQL, including coexistence with REST APIs. It emphasizes the power of GraphQL and provides tips for successful adoption. Overall, the Talk highlights the advantages of GraphQL in terms of efficiency, collaboration, and control over APIs.
Deja paso a los resolvers: un nuevo enfoque para la ejecución de GraphQL
GraphQL Galaxy 2022GraphQL Galaxy 2022
16 min
Deja paso a los resolvers: un nuevo enfoque para la ejecución de GraphQL
GraphQL has made a huge impact in the way we build client applications, websites, and mobile apps. Despite the dominance of resolvers, the GraphQL specification does not mandate their use. Introducing Graphast, a new project that compiles GraphQL operations into execution and output plans, providing advanced optimizations. In GraphFast, instead of resolvers, we have plan resolvers that deal with future data. Graphfast plan resolvers are short and efficient, supporting all features of modern GraphQL.

Workshops on related topic

Construye una aplicación WordPress sin cabeza con Next.js y WPGraphQL
React Summit 2022React Summit 2022
173 min
Construye una aplicación WordPress sin cabeza con Next.js y WPGraphQL
Top Content
Workshop
Kellen Mace
Kellen Mace
En esta masterclass, aprenderás cómo construir una aplicación Next.js que utiliza Apollo Client para obtener datos de un backend de WordPress sin cabeza y usarlo para renderizar las páginas de tu aplicación. Aprenderás cuándo debes considerar una arquitectura de WordPress sin cabeza, cómo convertir un backend de WordPress en un servidor GraphQL, cómo componer consultas usando el IDE GraphiQL, cómo colocar fragmentos GraphQL con tus componentes, y más.
Construir con SvelteKit y GraphQL
GraphQL Galaxy 2021GraphQL Galaxy 2021
140 min
Construir con SvelteKit y GraphQL
Top Content
Workshop
Scott Spence
Scott Spence
¿Alguna vez has pensado en construir algo que no requiera mucho código de plantilla con un tamaño de paquete pequeño? En esta masterclass, Scott Spence irá desde el hola mundo hasta cubrir el enrutamiento y el uso de endpoints en SvelteKit. Configurarás una API de GraphQL en el backend y luego usarás consultas de GraphQL con SvelteKit para mostrar los datos de la API de GraphQL. Construirás un proyecto rápido y seguro que utiliza las características de SvelteKit, y luego lo desplegarás como un sitio completamente estático. Este curso es para los curiosos de Svelte que no han tenido una experiencia extensa con SvelteKit y quieren una comprensión más profunda de cómo usarlo en aplicaciones prácticas.

Tabla de contenidos:
- Inicio e introducción a Svelte
- Inicializar el proyecto frontend
- Recorrido por el proyecto esqueleto de SvelteKit
- Configurar el proyecto backend
- Consultar datos con GraphQL
- Recuperación de datos en el frontend con GraphQL
- Estilización
- Directivas de Svelte
- Enrutamiento en SvelteKit
- Endpoints en SvelteKit
- Despliegue en Netlify
- Navegación
- Mutaciones en GraphCMS
- Envío de mutaciones GraphQL a través de SvelteKit
- Preguntas y respuestas
Modelado de Bases de Datos Relacionales para GraphQL
GraphQL Galaxy 2020GraphQL Galaxy 2020
106 min
Modelado de Bases de Datos Relacionales para GraphQL
Top Content
Workshop
Adron Hall
Adron Hall
En esta masterclass profundizaremos en el modelado de datos. Comenzaremos con una discusión sobre varios tipos de bases de datos y cómo se mapean a GraphQL. Una vez que se haya establecido esa base, el enfoque se desplazará a tipos específicos de bases de datos y cómo construir modelos de datos que funcionen mejor para GraphQL en varios escenarios.
Índice de contenidosParte 1 - Hora 1      a. Modelado de Datos de Bases de Datos Relacionales      b. Comparando Bases de Datos Relacionales y NoSQL      c. GraphQL con la Base de Datos en menteParte 2 - Hora 2      a. Diseño de Modelos de Datos Relacionales      b. Relación, Construcción de Tablas Multijoin      c. Complejidades de Consulta de Modelado de Datos Relacionales y GraphQL
Prerrequisitos      a. Herramienta de modelado de datos. El formador utilizará dbdiagram      b. Postgres, aunque no es necesario instalar esto localmente, ya que estaré utilizando una imagen de Dicker de Postgres, de Docker Hub para todos los ejemplos      c. Hasura
Construir y Desplegar un Backend Con Fastify & Platformatic
JSNation 2023JSNation 2023
104 min
Construir y Desplegar un Backend Con Fastify & Platformatic
Top Content
WorkshopFree
Matteo Collina
Matteo Collina
Platformatic te permite desarrollar rápidamente GraphQL y REST APIs con un esfuerzo mínimo. La mejor parte es que también te permite desatar todo el potencial de Node.js y Fastify siempre que lo necesites. Puedes personalizar completamente una aplicación de Platformatic escribiendo tus propias características y plugins adicionales. En la masterclass, cubriremos tanto nuestros módulos de Open Source como nuestra oferta en la Nube:- Platformatic OSS (open-source software) — Herramientas y bibliotecas para construir rápidamente aplicaciones robustas con Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (actualmente en beta) — Nuestra plataforma de alojamiento que incluye características como aplicaciones de vista previa, métricas integradas e integración con tu flujo de Git (https://platformatic.dev/). 
En esta masterclass aprenderás cómo desarrollar APIs con Fastify y desplegarlas en la Platformatic Cloud.
Construyendo APIs GraphQL sobre Ethereum con The Graph
GraphQL Galaxy 2021GraphQL Galaxy 2021
48 min
Construyendo APIs GraphQL sobre Ethereum con The Graph
Workshop
Nader Dabit
Nader Dabit
The Graph es un protocolo de indexación para consultar redes como Ethereum, IPFS y otras blockchains. Cualquiera puede construir y publicar APIs abiertas, llamadas subgrafos, para hacer que los datos sean fácilmente accesibles.

En este masterclass aprenderás cómo construir un subgrafo que indexa datos de blockchain de NFT del contrato inteligente Foundation. Desplegaremos la API y aprenderemos cómo realizar consultas para recuperar datos utilizando diferentes tipos de patrones de acceso a datos, implementando filtros y ordenamiento.

Al final del masterclass, deberías entender cómo construir y desplegar APIs de alto rendimiento en The Graph para indexar datos de cualquier contrato inteligente desplegado en Ethereum.
Problemas difíciles de GraphQL en Shopify
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Problemas difíciles de GraphQL en Shopify
Workshop
Rebecca Friedman
Jonathan Baker
Alex Ackerman
Théo Ben Hassen
 Greg MacWilliam
5 authors
En Shopify a gran escala, resolvemos algunos problemas bastante difíciles. En este masterclass, cinco oradores diferentes describirán algunos de los desafíos que hemos enfrentado y cómo los hemos superado.

Tabla de contenidos:
1 - El infame problema "N+1": Jonathan Baker - Vamos a hablar sobre qué es, por qué es un problema y cómo Shopify lo maneja a gran escala en varios APIs de GraphQL.
2 - Contextualizando APIs de GraphQL: Alex Ackerman - Cómo y por qué decidimos usar directivas. Compartiré qué son las directivas, qué directivas están disponibles de forma predeterminada y cómo crear directivas personalizadas.
3 - Consultas de GraphQL más rápidas para clientes móviles: Theo Ben Hassen - A medida que tu aplicación móvil crece, también lo harán tus consultas de GraphQL. En esta charla, repasaré diversas estrategias para hacer que tus consultas sean más rápidas y efectivas.
4 - Construyendo el producto del futuro hoy: Greg MacWilliam - Cómo Shopify adopta las características futuras en el código actual.
5 - Gestión efectiva de APIs grandes: Rebecca Friedman - Tenemos miles de desarrolladores en Shopify. Veamos cómo estamos asegurando la calidad y consistencia de nuestras APIs de GraphQL con tantos colaboradores.