Cómo Cachear APIs de GraphQL en el Edge

♪♪ ¡Hola a todos! Estoy muy emocionado de estar aquí hoy y hablarles sobre la caché en el borde de las APIs de GraphQL. Mi nombre es Max Stoiber. Estoy en la hermosa Viena, Austria aquí. Desafortunadamente, no puedo estar allí en persona esta vez, pero estoy realmente emocionado de estar aquí. Y si me quieren seguir prácticamente en cualquier lugar de internet, estoy en MXSTBR, básicamente en todas partes.

Soy el co-fundador de GraphCDN, que es el CDN de GraphQL. Si estás en la comunidad de React, en la comunidad de React JS o en la comunidad de JavaScript, en general, es posible que hayas utilizado algunos de los proyectos de código abierto en los que ayudé a construir, como Styled Components o React Boilerplate o Microanalytics, entre muchos otros. Soy muy activo en esa escena. Y si estás allí, es posible que también hayas utilizado algunos de esos proyectos.

La historia de GraphCDN y cómo llegamos allí comenzó en 2018. En ese momento, era el CTO de otra startup llamada Spectrum. Y en Spectrum estábamos construyendo una versión moderna del clásico foro comunitario. Básicamente, estábamos tratando de combinar lo mejor de lo que nos dio PHP BB hace 20 años con lo mejor de lo que nos ofrecen Discord y Slack en la actualidad. Esa era básicamente la idea. Era un foro público, pero todos los comentarios en cualquier publicación eran chat en tiempo real. Así que intentamos combinar estos dos mundos que actualmente están muy separados, donde las comunidades en Slack y Discord escriben muchos mensajes, pero ninguno de ellos es encontrable y hacerlos públicos y un poco más organizados para que puedas encontrarlos después en Google o en otro lugar. Intentamos combinar esos dos mundos juntos.

Ahora, eso funcionó sorprendentemente bien, lo que llevó a un crecimiento considerable de usuarios. Como puedes imaginar, con todo este contenido generado por los usuarios, mucha gente nos encontró en Google y en otros lugares y comenzó a visitar Spectrum con bastante regularidad. Eso significaba que teníamos mucho crecimiento. Ahora, desafortunadamente, había elegido una base de datos que no tenía mucho soporte. Elegí RethinkDB, que hoy en día ni siquiera existe. La empresa detrás de ella cerró después de un tiempo. Y elegí esa base de datos originalmente porque se anunciaban a sí mismos como la base de datos en tiempo real. Y su característica clave, o lo que elogiaban externamente, era que podías poner esta clave de cambios al final de cualquier consulta de base de datos y te daría actualizaciones en tiempo real del flujo de cambios de esa consulta de base de datos. Y así podías escuchar los cambios en prácticamente cualquier cambio de datos, lo cual parecía encajar perfectamente con lo que estábamos tratando de hacer. Porque obviamente, casi todo en Spectrum era en tiempo real, ¿verdad? Las publicaciones aparecían en tiempo real, el chat era en tiempo real, por supuesto, teníamos mensajes directos que tenían que ser en tiempo real. Así que esto parecía encajar perfectamente con lo que estábamos tratando de hacer. Lección aprendida, a posteriori, confía en las bases de datos que todos usan.

Ahora, como puedes imaginar, cada persona que visita el sitio web inicia muchos oyentes de cambios diferentes, ¿verdad? Estamos escuchando cambios en la publicación específica que están viendo. Estamos escuchando cambios en la comunidad en la que se publica la publicación. Estamos escuchando nuevas notificaciones. Teníamos un montón de oyentes por usuario y esencialmente nuestros servidores de base de datos estaban en llamas, literalmente en llamas. Bueno, afortunadamente no literalmente, pero se bloqueaban con bastante frecuencia. Busqué en Google servidores en llamas y encontré esta increíble foto de archivo de servidores en llamas, que si tu centro de datos se ve así, tienes algunos problemas muy graves. Los nuestros no eran tan malos, pero aún así eran bastante malos. Así que teníamos esta base de datos que no escalaba y básicamente tuvimos que trabajar alrededor de esa limitación. Queríamos cambiar a una base de datos más compatible. Sin embargo, eso implicaba mucho trabajo. Reescribir las cientos de consultas de base de datos que habíamos escrito y optimizado hasta ese momento, migrar todos esos datos sin tiempo de inactividad, eso era todo un proyecto y queríamos llegar allí eventualmente, pero necesitábamos una solución para evitar que nos bloqueáramos literalmente todos los días, justo en este momento.

Mientras pensaba en esto, por supuesto, me di cuenta de que la caché, teníamos un caso de uso ideal para la caché porque nuestra API tenía muchas lecturas. Por supuesto, es datos públicos, mucha gente lo lee, pero no tanta gente escribe en él. Y así que en realidad teníamos un caso de uso ideal para la caché. Originalmente elegimos GraphQL para nuestra API porque teníamos muchos datos relacionales. Estábamos obteniendo una comunidad, todas las publicaciones dentro de esa comunidad, los autores de cada publicación, el número de comentarios, un montón de datos relacionales y GraphQL fue una solución fantástica para ese caso de uso. Funcionó extremadamente bien para nosotros y realmente disfrutamos nuestra experiencia de construir nuestra API con GraphQL. El único gran inconveniente con el que nos encontramos fue que no había soluciones preconstruidas para la caché de GraphQL en el borde, que era lo que queríamos hacer.

Ahora queríamos ejecutar código en muchos, muchos centros de datos en todo el mundo, y queríamos dirigir a nuestros usuarios al centro de datos más cercano y almacenar en caché sus datos muy cerca de ellos para obtener tiempos de respuesta muy rápidos, pero también para reducir la carga en nuestros servidores. Ahora, si alguna vez has usado GraphQL, entonces sabes que eso es básicamente lo que los clientes de GraphQL hacen en el navegador. Si has oído hablar de Apollo Client, Relay, Urql, todos estos clientes de GraphQL, lo que hacen es básicamente un mecanismo de obtención para consultas de GraphQL que las almacena en caché de manera muy inteligente en el navegador para una mejor experiencia de usuario. Así que en mi cabeza, básicamente, la pregunta que quería responder era, ¿no puedo simplemente ejecutar un cliente de GraphQL en el borde? Los clientes de GraphQL hacen esto en el navegador. ¿Por qué no puedo tomar este cliente de GraphQL que se está ejecutando en mi navegador local, ponerlo en un servidor en algún lugar y tener esa misma lógica de caché pero en el borde? Para responder a la pregunta, quiero profundizar un poco en cómo los clientes de GraphQL almacenan en caché. Si observamos este ejemplo de una consulta de GraphQL, que obtiene una publicación de un blog por un slug, y obtiene su ID, título y autor.

Y del autor, obtiene el ID, nombre y avatar. Y hay un truco mágico que hace que la caché de GraphQL sea realmente excelente. Y eso es el campo meta __typename. Puedes agregarlo a cualquier objeto de GraphQL, en tu consulta, puedes agregarlo a cualquier tipo de objeto, y obtendrás el nombre del tipo de respuesta. Así que, por ejemplo, con esta consulta, agregaríamos el nombre del tipo en estos dos lugares para la publicación y también para el autor.

Cuando el origen responde con los datos, la respuesta se verá algo así, siendo lo más importante que ahora tenemos los datos de la publicación y sabemos que el tipo que se devolvió allí fue una publicación, y lo mismo para el autor, obtuvimos los datos del autor y también sabemos que el autor es un usuario. Y cuando tomamos esta respuesta y la almacenamos en nuestra caché localmente en el navegador, ahora podemos asociar esa respuesta de consulta en caché con esos dos objetos. Podemos etiquetarla con la publicación con el ID 5 y el usuario con el ID 1.

De acuerdo, eso está bien. Así que acabamos de tomar esta respuesta de consulta, la hemos almacenado en la caché, la hemos identificado por la consulta que vimos, por la consulta de obtener publicación. Y cada vez que vemos la misma consulta, devolvemos los mismos datos. ¿Por qué son relevantes estas etiquetas? ¿Por qué me importa que esto contenga la publicación con el ID 5 y el usuario con el ID 1? Bueno, aquí es donde entra la magia. GraphQL también tiene algo llamado mutaciones, que son básicamente acciones. Cualquier cosa que cambie los datos debe ser una mutación. Por ejemplo, si tuviéramos una mutación que se llamara editar publicación, que edita una publicación, en este caso, estamos editando la publicación con el ID 5 y cambiando su título. Cualquier mutación también debe obtener lo que cambió. Así que en este caso, estamos obteniendo de vuelta la publicación. Y nuevamente, podemos hacer lo mismo que hicimos para la consulta y agregar el campo __typename a la respuesta.

Ahora, cuando esa respuesta regresa desde el origen a nuestro cliente, el cliente puede mirar esta respuesta y decir, oh, mira, acabamos de enviar una mutación al origen. Esa mutación ha regresado del origen y los datos que se devolvieron fueron la publicación con el ID 5. ¡Ajá! En realidad tengo una respuesta de consulta en caché que contiene esa publicación con el ID 5. Y ahora puedo invalidar automáticamente ese resultado de consulta en caché que contiene los datos obsoletos de esta publicación. ¡Eso es increíble, verdad? Y esto es lo que hacen los clientes de GraphQL bajo el capó. Hacen esta invalidación mágica basada en el campo __typename y el campo ID, y luego los combinan para invalidar cualquier dato obsoleto que haya sido cambiado en el origen.

Hay un pequeño caso especial aquí donde la magia termina, que es la invalidación de listas. Si te imaginas una consulta que obtiene una lista de publicaciones de blog, en este caso, solo su ID y título, cuando miramos la respuesta a esta consulta, es una matriz que solo contiene la única publicación que tenemos en este momento, la publicación con el ID cinco, cómo almacenar en caché los APIs de GraphQL en el borde. Ahora, una mutación que crea una nueva publicación ahora plantea un problema interesante, porque por supuesto, la respuesta a esta mutación de crear publicación se verá algo así. Devolverá un objeto de una publicación con el ID seis, pero por supuesto, nuestros resultados de consulta en caché para la lista de publicaciones no contienen la publicación con el ID seis. Y eso es realmente molesto, porque eso significa que los clientes de GraphQL no pueden invalidar automáticamente las listas cuando se crean nuevos elementos. Bastante frustrante.

Ahora, afortunadamente, encontraron una buena solución alternativa para esto, que es la invalidación manual. Básicamente, los clientes de GraphQL te brindan diferentes APIs para influir manualmente en la caché y cambiarla dependiendo de las cosas que pasen por ella. Por ejemplo, con Urql, que es el tercer cliente de GraphQL más grande, se vería algo así. Podrías decirle a Urql que cuando la mutación de crear publicación pase a través de los clientes de GraphQL, invalide cualquier resultado de consulta en caché que contenga la consulta de publicaciones, que contiene la lista de publicaciones. Y de esa manera, podemos invalidar automáticamente eso, sin problemas. Y cada vez que se crea una publicación, nuestro cliente de GraphQL volverá a obtener automáticamente los datos frescos del origen.

Los clientes de GraphQL van un paso más allá y hacen algo llamado caché normalizada. Si volvemos a nuestra consulta original de obtener una sola publicación de blog, su ID, título y autor, en lugar de tomar la respuesta completa de la publicación con ID cinco y el usuario con ID uno y ponerla completa en la caché, en realidad toman cada objeto dentro de la respuesta de la consulta individualmente y lo almacenan de forma individual. Así que dentro de la caché de Urql, se vería algo así, donde básicamente en la caché almacenamos, está bien, la publicación con ID cinco corresponde a estos datos y el usuario con ID uno corresponde a estos otros datos. ¿Por qué nos importa hacer esto? Porque ahora, si llega una consulta que, por ejemplo, obtiene el usuario con ID uno, la caché puede decir, oh, espera, estás obteniendo el usuario con ID uno. Aunque no hayamos visto esta consulta específica antes, en realidad tenemos esos datos específicos en nuestra caché y podemos simplemente servirte eso en el cliente sin que tengas que ir al origen para obtener esos datos nuevamente, porque ya los hemos obtenido. Estaba simplemente anidado en alguna otra consulta, pero lo hemos normalizado para ti y ahora podemos darte los datos del usuario con ID uno. Sin problemas, así de fácil. Lo cual es muy agradable y realmente reduce el tráfico de red y mejora mucho la experiencia del usuario porque las cosas se resolverán mucho más rápido ya que ya están en el cliente y cargadas. Muy bien. Básicamente solo tienes que obtener cada objeto una vez, lo cual es fantástico, especialmente si las personas navegan con frecuencia por tu aplicación.

Ahora, lo que realmente quiero que saques de esta sección es que GraphQL es realmente excelente para la caché. En realidad, es muy, muy bueno para la caché debido a su capacidad de introspección. Te dice qué datos estás devolviendo. Y esta capacidad de introspección combinada con un esquema estricto donde tienes que devolver algo que coincida con ese esquema significa que es realmente bueno para la caché. Y esa también es una de las razones por las que se ha desarrollado tanto software genial en torno a GraphQL. Ha tenido una adopción comunitaria tan amplia que si una persona construye una herramienta para ello, porque siempre sigue la misma especificación de GraphQL, todos los demás se benefician de esa herramienta. Y eso es increíblemente poderoso. Ahora, volviendo a mi pregunta original que planteé en 2018, ¿no puedo simplemente ejecutar un cliente de GraphQL en el borde? ¿No puedo simplemente tomar esta lógica que Apollo Client, Relay y Urql tienen internamente de todos modos, tomar ese mismo código y ponerlo en un montón de servidores en todo el mundo en el borde para que todos los que usen Spectrum, en todas partes, obtengan tiempos de respuesta súper rápidos y podamos reducir enormemente la carga que nuestro servidor tiene que manejar? Bueno, la clave de la respuesta a esta pregunta radica en la última parte, el borde, porque resulta que los clientes de GraphQL están diseñados con restricciones muy específicas que difieren ligeramente de las restricciones con las que tendríamos que trabajar en el borde.

Uno de los principales con los que tenemos que lidiar si quisiéramos implementar la lógica de caché en el borde es la autorización, porque, por supuesto, si un cliente de GraphQL se ejecuta en el navegador, sabe que si algo está en la caché, quien solicite esto nuevamente puede acceder a él porque es la misma persona, ¿verdad? Si estoy usando Spectrum y estoy consultando la publicación con el ID cinco y el cliente de GraphQL lo pone en la caché, entonces el cliente de GraphQL no tiene que preocuparse por la autorización. Ni siquiera tiene que saber nada sobre la autorización porque se me permite acceder a la publicación con el ID cinco. Entonces, si solicito la misma publicación nuevamente, el cliente simplemente puede dármela desde la caché y decir, sí, por supuesto, ¿verdad? Sin problema. En el borde, eso es un poco diferente, ¿verdad? Si tenemos un servidor que muchos usuarios están solicitando datos, algunos de ellos pueden tener permiso para acceder a la publicación con el ID cinco, pero otros tal vez no, ¿verdad? O incluso más específicamente, si pensamos en los datos del usuario, ¿verdad? Tal vez a alguien se le permite acceder a su propio correo electrónico, pero a nadie más. Entonces, no podemos simplemente tomar una consulta y poner ese resultado en la caché porque eso significaría que todos reciben los mismos datos. Entonces, si alguien crea datos sensibles, específicos de ese usuario, de repente se servirán a todos. Eso sería una pesadilla, ¿verdad? Sería una terrible pesadilla de seguridad y una experiencia realmente mala porque esencialmente estaríamos filtrando datos. Muy mala idea. Entonces, en el borde, lo que tenemos que hacer es, en lugar de simplemente hacer que la clave de caché sea un hash de la consulta. Entonces, básicamente, tomamos el texto de la consulta que tenemos en las variables y lo usamos como clave de caché. En lugar de hacer solo eso, también tenemos que tener en cuenta el token de autorización, ya sea que se envíe a través del encabezado de autorización o que sea una cookie, tenemos que agregar eso a la clave de caché para que si alguien más envía la misma consulta, no obtengan la misma respuesta. Es tan simple como eso. Solo pon el token de autorización en la caché, perdón, en la clave de caché y todo estará bien.

La otra parte que es un poco diferente es la purga de caché porque no solo tenemos que hacer una purga automática de caché y admitir la invalidación manual para la invalidación de listas, también tenemos que hacerlo a nivel global, ¿verdad? Si estás ejecutando en el borde en todos estos centros de datos a nivel mundial, entonces tienes que invalidar esos datos a nivel global, ¿verdad? Si la publicación con el ID5 cambia y el usuario envía una mutación para editar eso o el servicio dice, oye, mira, esto ha cambiado y quiere invalidarlo manualmente, entonces tienes que hacerlo a nivel global. No puedes hacerlo solo en un centro de datos. Eso sería una experiencia terrible porque los datos obsoletos permanecerían en todos los demás centros de datos, tienes que hacerlo a nivel global.

Y así, mientras pensábamos en estos problemas para GraphCity y mientras construíamos esta solución de caché de borde GraphQL, llegamos a la conclusión de que íbamos a utilizar el producto Compute-at-Edge de Fastly. Ahora, somos grandes fanáticos de Fastly aquí. Y la razón por la que elegimos Fastly es porque, como su nombre sugiere, son súper rápidos. Fastly tiene alrededor de 60 centros de datos en todo el mundo, distribuidos por todo el globo. Ahora aquí hay un dato loco. La lógica de invalidación de Fastly. Si tomas una respuesta de consulta y la pones en la caché de Fastly y la etiquetas con la publicación con su ID5, si luego envías una solicitud de API a Fastly para invalidar cualquier resultado de consulta en caché que contenga la publicación con su ID5, pueden invalidar datos obsoletos en 150 milisegundos a nivel global. 150 milisegundos a nivel global. Eso probablemente es más rápido de lo que puedes parpadear, ¿verdad? En el tiempo que me lleva hacer esto, Fastly ya ha invalidado los datos a nivel global. Eso es absolutamente asombroso para mí, ¿verdad? Y en realidad busqué hace un tiempo, pensé, espera, un momento, ¿qué tan rápido es incluso la velocidad de la luz, verdad? Seguramente, eso lleva un tiempo dar la vuelta al mundo una vez. Y así lo busqué, y en realidad la luz tarda 133 milisegundos, si recuerdo correctamente, en dar la vuelta al mundo. Entonces, ¿cómo puede Fastly invalidar en 150 milisegundos? Eso es súper rápido. Bueno, la respuesta es, por supuesto, que no tienen que dar la vuelta al mundo entero porque van en ambas direcciones al mismo tiempo. Entonces solo tienen que dar la vuelta a la mitad del mundo, lo que reduce el tiempo a la mitad. Y luego, por supuesto, también tienen, tienen un algoritmo de gossiping realmente sofisticado, que puedes buscar en Google. Han escrito algunos artículos geniales al respecto. Y me inclino ante sus ingenieros porque es absolutamente genial. Y es tan rápido que ahora permite a nuestros clientes almacenar en caché muchos más datos, ¿verdad? Si puedes invalidar datos obsoletos en 150 milisegundos a nivel global, imagina cuántos más datos puedes almacenar en caché porque nunca estarán obsoletos, ¿verdad? Cuando los datos cambien, envía una solicitud de API y 150 milisegundos después, todos a nivel mundial tendrán los datos actualizados. Imagina cuántos más datos puedes almacenar en caché si tienes una invalidación súper rápida. Y esa es la razón por la que usamos Fastly. Son súper rápidos y estamos muy contentos con ellos.

Entonces, eso es básicamente lo que es GraphCDN. Reconstruimos esta lógica de almacenamiento en caché para que se ejecute en el borde, teniendo en cuenta la autorización y teniendo esta purga de caché global. Y lo implementamos en los 60 centros de datos de Fastly en todo el mundo, para permitir a nuestros clientes almacenar en caché sus consultas GraphQL y sus respuestas GraphQL en el borde. Ojalá esto hubiera existido en 2018 cuando tuvimos problemas de escalabilidad con Spectrum. En ese momento, solo construí una solución de almacenamiento en caché en memoria terrible que redujo un poco la carga hasta que finalmente fuimos adquiridos por GitHub. Y simplemente, si hubiéramos tenido GraphCDN, habríamos podido escalar mucho más suavemente.

Hubiéramos ahorrado mucho dinero porque, por supuesto, ejecutar algo en el borde es mucho más económico que ejecutar la solicitud a través de toda nuestra infraestructura. Y habría sido una experiencia mucho mejor para toda nuestra base de usuarios global porque todos habrían tenido tiempos de respuesta súper rápidos desde su centro de datos local.

De acuerdo, espero que hayas aprendido sobre el almacenamiento en caché de GraphQL hoy. Lo principal que quiero que te lleves es que GraphQL es increíble para el almacenamiento en caché. Esa es realmente la idea principal en la que quiero enfocarme. GraphQL, absolutamente fantástico para el almacenamiento en caché. La capacidad de introspección, el esquema estricto, chefkiss, simplemente increíble.

Y si tienes una API de GraphQL, me encantaría conocerte. Me encantaría escuchar qué más podemos hacer por ti en el futuro incluso si no necesitas almacenamiento en caché. Gracias por recibirme. Si tienes alguna pregunta, no dudes en contactarme en cualquier momento. Estoy en MXSTPR, prácticamente en todas partes de internet y espero tener noticias tuyas.

¡Eso es increíble! Antes de comenzar la charla, hicimos una pregunta a la audiencia y la pregunta que queríamos hacer era, ¿almacenan en caché su API de GraphQL? Y los resultados están aquí. Veo que el 44% de las personas dicen que sí mientras que el 33% dice que no. Y el 22% dice que no tienen una API de GraphQL. ¿Cuál es tu opinión al respecto? ¿Te sorprende o esperabas este tipo de porcentaje? En realidad, es genial escuchar eso. Me sorprende que el 22% de las personas que están viendo no tengan una API de GraphQL, eso es increíble. Realmente deberían estar usando GraphQL. Lo recomiendo encarecidamente. Obviamente, soy un gran fan. Creo que es genial ver que el 44% ya está almacenando en caché su API de GraphQL. Y creo que el 30% restante debería pensar si tienen un caso de uso para ello y considerar si deberían almacenar en caché sus API de GraphQL. Eso es realmente increíble.

Ahora que hablas del caso de uso, me gustaría comenzar con una pregunta que realmente tenía mientras escuchaba la charla. ¿Cuáles podrían ser algunos de los casos de uso probables que mencionarías para Graph3D y cuándo debería comenzar a pensar en almacenar en caché las consultas de GraphQL?

Esa es una excelente pregunta. Nosotros en Spectrum, la historia que conté desde 2018 teníamos un caso de uso perfecto para el almacenamiento en caché. Teníamos muchos datos públicos, muy orientados a la lectura, probablemente un 95 a un 99% de lecturas, solo un 1% de escrituras. Por lo tanto, realmente un caso de uso ideal para el almacenamiento en caché. Y creo que eso es esencialmente a lo que se reduce. Tengo algunos amigos que trabajan en Sentry, por ejemplo, Sentry es el servicio de seguimiento de errores. Y cuando les dije que estábamos construyendo un servicio de almacenamiento en caché de GraphQL, ellos dijeron, ¿por qué querría almacenar en caché mi API? Y, por supuesto, eso tiene mucho sentido porque el caso de uso de Sentry es muy orientado a la escritura. Sentry recibe millones de errores probablemente cada hora. Y por lo tanto, sus datos cambian mucho más a menudo de lo que una caché podría actualizarse. Por lo tanto, el almacenamiento en caché para ellos no tiene mucho sentido en muchos niveles. Y realmente se centran mucho más en el rendimiento de la ingestión, y han invertido mucho tiempo en mejorarlo. Por lo tanto, creo que realmente se reduce a si tienes un caso de uso muy orientado a la lectura y qué tan compartidos son tus datos. Si tienes muchos datos autenticados y cada usuario solo ve sus propios datos y nada más. Y solo visitan tu aplicación una vez a la semana, entonces no obtendrás una tasa de aciertos en caché muy alta porque sí, los datos para ese usuario en particular pueden estar almacenados, pero no van a volver solo para obtener un acierto en caché. Por lo tanto, no obtienes realmente ninguno de los beneficios de rendimiento o carga de almacenar en caché tu API de GraphQL. Por lo tanto, creo que realmente se reduce a si tienes un caso de uso orientado a la lectura y, en segundo lugar, si tienes un caso de uso en el que algunos datos se comparten entre tú y tus usuarios. Ahora, dicho esto, nos hemos sorprendido de lo altas que han sido las tasas de aciertos en caché que las personas han podido obtener incluso en casos de uso autenticados, ¿verdad? Nuestros clientes que tienen casos de uso autenticados aún ven tasas de aciertos en caché del 40, 50, 60%, lo cual es mucho más alto de lo que esperábamos. Y eso sigue siendo mucha carga menos en tu servidor, ¿verdad? Eso sigue siendo un 50, 60% menos de tráfico en tu origen y un rendimiento mucho más rápido para tus usuarios. Pero, por supuesto, no es la tasa de aciertos en caché del 95, 99% que verías con datos muy, muy públicos que son muy orientados a la lectura, si eso tiene sentido.

Sí, eso es realmente impresionante en realidad.

Sí, gracias. Eso definitivamente tiene sentido. Entonces tenemos una pregunta de un principiante. Quieren saber, ¿qué es edge? ¿Puedes explicar edge como si tuviera cinco años?

Sí, voy a intentarlo. No estoy seguro de si un niño de cinco años lo entenderá, pero básicamente, ¿cómo explico esto a un niño de cinco años? Ahora tengo que pensar en esto. En lugar de que todos tengan que conducir hasta el agricultor para obtener su comida y luego conducir de regreso, construyes supermercados, y los supermercados obtienen algunas cosas del agricultor, y luego las almacenan en el supermercado. Y así solo tienes que ir a tu supermercado local y volver en lugar de ir hasta el agricultor. Entonces el agricultor tiene que lidiar con muchas menos personas. Solo vende sus cosas a un supermercado y ya está. Y luego no tienes que conducir hasta el agricultor y luego volver.

Pero puedes ir a tu supermercado local que está más cerca de ti. Eso es lo que es la informática en el borde. Mueve los cálculos más cerca de donde están tus usuarios en lugar de tener todo en un lugar central. Se me ocurrió eso de la nada. No creo que eso tenga mucho sentido, pero creo que así se lo explicaría a un niño de cinco años.

Sí, no, wow, es increíble. Incluso yo no tenía mucha información sobre el borde, pero logré entenderlo. Espero que la persona que hizo la pregunta haya logrado entender al menos un poco. Así que gracias por tomarte el tiempo para hacerlo entender de esa manera.

Tenemos otra pregunta de Danny Z. En primer lugar, quieren decir que fue una charla increíble como siempre. Están ansiosos por comenzar a usar Graph CDN. Y tienen una pregunta sobre si todavía necesitamos almacenamiento en caché local del cliente GraphQL al usar Graph CDN, especialmente la invalidación manual. Esa es una excelente pregunta que a veces me hacen y que debería haber mencionado en la charla. Eso ya es un gran comentario para mí. La respuesta es muy probablemente sí, porque nada es más rápido que cargar data desde la memoria de tu navegador. Cuando el usuario hace clic en la aplicación y vuelve a pantallas que ya ha visto no requiere realmente ir a una caché en el borde, incluso si está en una caché en el borde en su ciudad metropolitana local, realmente aún quieres usar un cliente GraphQL para la mejor experiencia de usuario. Es casi como un enfoque de almacenamiento en caché en capas, ¿verdad? Por un lado, tienes el almacenamiento en caché por usuario en la caché del cliente de su navegador, y luego tienes el almacenamiento en caché compartido entre todos en la misma ubicación en la caché del borde, y luego tienes tu origen. Y así tienes una estrategia de almacenamiento en caché en capas donde, por supuesto, el usuario individual solo obtendrá un acierto en caché en cualquier data que haya cargado antes, pero en el borde puedes obtener aciertos en caché para data que otros usuarios también hayan cargado. Y por lo tanto, tendrás diferentes compensaciones y diferentes requisitos de invalidación porque, por supuesto, el navegador no sabe cuándo cambia los datos del servidor. Entonces sí, quieres usar un cliente GraphQL muy probablemente por la gran experiencia de usuario que brindan y la gran experiencia de desarrollo.

Honestamente, creo que una de las cosas que hace que GraphQL sea genial, como seguramente sabes son los clientes de GraphQL. Solo usarlos para obtener data de una API se siente increíble, ¿verdad? Todos estos hooks que tenemos hoy en día en el mundo de React. La experiencia de desarrollo es simplemente súper agradable. Y sí, siempre usaría un cliente GraphQL. Usamos un cliente GraphQL para Graph CDN en el panel de control y siempre he usado un cliente GraphQL. Espero que eso responda la pregunta. Gracias. Así que sí, tienes la respuesta, úsalo.

Ahora tenemos otra pregunta de Alexander Wawike. ¿Cómo almacenas en caché con Apollo? Quieren saber cómo almacenas en caché con Apollo.

Entonces, Apollo puede referirse a dos cosas, eso depende de a qué se refieran, ¿verdad? O se refieren al cliente Apollo, en cuyo caso ya respondí esa pregunta, ¿verdad? Si aún quieres usar el almacenamiento en caché con el cliente Apollo, eso es independiente de tu caché en el borde, pero también está el servidor Apollo. Si tienes una API de GraphQL que creaste con el servidor Apollo, puedes poner GraphCDN frente a ella sin problemas y almacenaremos en caché tu API de GraphQL. Admitimos cualquier API de GraphQL, ¿verdad? Ya sea que la poseas o no, puedes ponerla frente a una API de GraphQL que hayas construido con Apollo, pero también puedes ponerla frente a graph CMS o la API de Shopify o cualquier otra API de GraphQL que tengas para obtener la API de GraphQL, ¿verdad? Admitimos cualquier API de GraphQL y simplemente puedes ponerla frente a cualquier API de GraphQL y la almacenaremos en caché para ti. Eso es increíble. De hecho, mezclé el nombre. Entonces, anteriormente, la pregunta fue de Kafe M-A-K-E-R-N y ahora la pregunta es de Alexander. Y recuerden, Max, estaban hablando de la caché hace un rato. Tienen una pregunta similar, como mencionaste agregar datos de autenticación a la clave de caché. ¿Cómo evitas que nunca ocurran aciertos en caché porque la clave de caché es única para cada solicitud? Entonces, ¿hay algún límite superior para la flexibilidad de autorización que un servicio que utiliza GraphCDN puede tener antes de que deje de tener sentido? Sí, como mencioné, creo que si tienes un caso de uso muy, muy único donde cada usuario ve sus propios datos y nada más, entonces probablemente el almacenamiento en caché no tenga sentido porque tu tasa de caché será muy, muy baja. Sin embargo, si tienes algún dato que se comparte que se puede almacenar en caché entre usuarios, entonces sí, tiene mucho sentido. GraphCDN tiene controles muy detallados. Puedes decir, mira, si contiene los datos de un usuario específico, entonces almacena en caché toda la consulta para ese usuario específico. Pero si contiene, no sé, una publicación de blog, entonces almacénala en caché públicamente para todos. Tenemos la capacidad de diferenciar a nivel de consulta para que puedas configurar GraphCDN para almacenar en caché las cosas de manera diferente según si los datos son públicos o autenticados y solo deben devolverse a ese único usuario. Entonces tienes formas de ajustar tu tasa de caché y aumentarla, incluso si tienes algunos casos de uso autenticados. Pero nuevamente, si tienes un caso de uso muy autenticado, entonces no ayudará. No tendrás una gran tasa de caché sin importar qué. Eso es increíble. Así que esa fue la última pregunta que estamos tomando hoy. Muchas gracias, Max, una vez más, por tomarte el tiempo para brindarnos una descripción general tan buena del almacenamiento en caché y también por todas estas respuestas a las preguntas. Así que para la audiencia, todavía pueden hablar con Max en la sala de conferencias de Max. Así que ve a la sala de conferencias y todavía puedes hablar con Max y también puedes hacerle preguntas en sus redes sociales. Muchas gracias, Max, una vez más. Fue realmente increíble hablar contigo. Adiós. Gracias por tenerme.