Potencia tus aplicaciones GraphQL con CDNs

Cómo hacer crecer tus aplicaciones de GraphQL con CDNs. Consultas más rápidas de GraphQL con almacenamiento en caché y CDNs. Esto es de lo que vamos a hablar hoy. Habilitar y almacenar en caché, dos palabras que realmente no van bien juntas. Ha habido muchas conversaciones en la comunidad, ¿cómo vamos a habilitar el almacenamiento en caché y las consultas de GraphQL juntas? Bueno, antes de entrar en eso, permíteme darte una breve introducción sobre mí. Mi nombre es Naz. Actualmente soy gerente de ingeniería en LinkedIn. Antes de LinkedIn, trabajé como gerente de ingeniería y colaborador individual en Netflix. Actualmente dirijo JavaScript Weekly con un grupo de personas increíbles en Twitter spaces y también organizo sesiones de preguntas y respuestas sobre carrera en eventos de LinkedIn. También soy entrenador y mentor de carrera en Mentor Cruise, asesorando y entrenando a muchos ingenieros en todo el mundo. Si quieres saber más sobre mí, visita mi sitio web, naz.dev.

Entonces, hablemos de almacenamiento en caché. Antes de aprender sobre GraphQL y el almacenamiento en caché, hablemos sobre el almacenamiento en caché de HTTP. ¿Qué es el almacenamiento en caché de HTTP y cómo se hace? El almacenamiento en caché de HTTP tiene dos conceptos principales. Uno es la frescura y dos es la validación.

La frescura significa, como navegador, ¿cuánto tiempo puedo mantener este recurso en mi caché? La frescura es una forma para que el servidor proporcione un recurso al cliente y luego instruya al cliente sobre cuánto tiempo puede mantener un recurso. En la práctica, esto se hace a través del encabezado de control de caché de HTTP. Cache control max age igual a 60 significa que el navegador puede mantener el recurso durante 60 segundos y luego comenzar a solicitar nuevamente el recurso al servidor.

Pero llegamos a la validación. La validación significa que cuando se cumplan esos 60 segundos, si el cliente decide volver a solicitar el recurso nuevamente al servidor, le preguntará al servidor: `Oye servidor, ¿realmente necesito volver a buscar esto nuevamente? Entonces, hay una forma para que el servidor sepa si el cliente realmente necesita el recurso nuevamente o si tiene el recurso más reciente, actualizado y válido. Entonces, si nada ha cambiado en ese recurso, realmente no es necesario que el servidor vuelva a enviar el recurso al cliente. Y esto se hace a través de los encabezados de última modificación y ETAC en el lado del servidor. La última modificación es una fecha y una hora, y ETAC es un token que indica el estado del recurso. Por ejemplo, si no coincide, el ETAC.

Estos son encabezados muy importantes, pero ¿puede GraphQL realmente usar alguno de estos mecanismos? ¿Por qué decimos que no van juntos? Son súper y podemos simplemente adjuntarlos a los encabezados de HTTP. Bueno, lo veremos. Antes de profundizar en eso, hablemos un poco sobre las CDNs. Si no estás familiarizado con lo que es una CDN, una CDN es una red de entrega de contenido que almacena en caché contenido como imágenes, videos, páginas web, cualquier cosa que esté en servidores proxy que están ubicados más cerca de los usuarios finales que los servidores originales.

Un servidor proxy es un servidor que recibe solicitudes de clientes y las envía a los servidores. Debido a que los servidores están más cerca de los clientes que realizan la solicitud, una CDN puede entregar el contenido de manera más rápida y sin problemas a los clientes. Explicaremos esto más fácilmente. Podemos pensar en una CDN como una cadena de tiendas de comestibles. En lugar de tener solo una tienda de comestibles, un Walmart, que es la sucursal principal de Walmart a la que todas las casas de la zona o todas las personas van a esa sucursal de Walmart porque es la única sucursal para comprar. Podemos tener sucursales pequeñas de Walmart en cada vecindario. Entonces, en lugar de que las personas tengan que ir a la sucursal principal para recoger sus cosas. En realidad, pueden buscar cosas en la sucursal más pequeña primero. Y si eso que quieren comprar existe en esa sucursal más pequeña. Genial. Pueden recogerlo de allí.

Es mucho más rápido y más rápido. Si no, pueden ir a la sucursal principal o la sucursal principal y luego también pedir a la sucursal que tenga esas cosas en las sucursales más pequeñas o más caras para que puedan obtenerlo de allí. Así es como funciona el almacenamiento en caché de las CDNs. Básicamente, replica el contenido estático en servidores proxy en el borde de la red. Entonces, cuando un usuario solicita contenido de un sitio web utilizando una CDN, la CDN obtiene el contenido del servidor de origen o el servidor principal y luego guarda una copia del contenido para futuras solicitudes. El contenido en caché permanece en la caché de la CDN siempre que los usuarios sigan solicitándolo.

Bueno, ¿qué pasa con las consultas de GraphQL? ¿Hacia dónde vamos con esto? Bueno, las CDNs saben cómo almacenar en caché los recursos cuando realmente tienen esos encabezados de solicitud de los que hablamos adjuntos a ellos. Pero, ¿podemos usar esos encabezados de solicitud con las consultas de GraphQL? Sí, podemos. Podemos establecer encabezados de control de caché en una consulta de GraphQL, ¿verdad? Bueno, excepto que generalmente usamos recursos que son documentos de consulta. Bueno, sigue siendo un recurso. Entonces podemos establecer encabezados. En el ejemplo que ves aquí, un documento es nuestro recurso aquí y sin duda podríamos adjuntar el control de caché, la última modificación y algunos encabezados de e-texto a él. Pero aunque eso es posible en teoría ya que GraphQL usa POST, pero en la práctica básicamente no podemos adjuntar esos encabezados a POST y debemos usar GET. Entonces es por eso que recurrimos a las consultas persistentes como solución número uno para evitar adjuntar esos encabezados de los que hablamos a las consultas de GraphQL.

Un principio central en REST del que hablamos es que usas una URL para identificar una pieza de data, una pieza de recurso, y luego usamos el verbo GET en nuestra solicitud HTTP para indicar que estás leyendo algunos data, no escribiendo. Eso le dice a nuestras CDNs que está bien almacenar ese resultado ya que no espera modificar algo en el backend. En contraste con eso, históricamente, la mayoría de las herramientas gráficas enviaban solicitudes HTTP utilizando POST. En lugar de una URL, usaban un cuerpo de solicitud complicado que contiene una consulta y variables. Como complicación adicional, en algunos navegadores, hay un límite relativamente pequeño de tamaño de URL. Eso significa que puedes ajustar toda la consulta que estás haciendo y también los valores en las solicitudes GET. Entonces, ¿qué podemos hacer? Bueno, las consultas persistentes vienen a nuestro rescate. Al combinar ApolloLink, nuestra interfaz de red modular para el cliente, y la función de consultas persistentes automáticas de Apollo Engine, podemos abordar ambas preocupaciones a la vez. Después de configurar el motor, puedes agregar fácilmente ApolloLink persistent queries a tu código de cliente. Aquí tienes un ejemplo de código que utiliza un enlace de consulta persistente. Esto hará dos cosas por nosotros. Primero, enviar consultas a través de HTTP GET en lugar de POST, ¿verdad, porque las CDNs necesitan esa solicitud GET para entender que los recursos no están cambiando, mientras seguimos usando POST para las mutaciones. Y segundo, usar un ID de consulta persistente abreviado en la URL GET para que la clave de caché para las CDNs sea más corta y no alcancemos los límites de tamaño de URL. Esto acerca a GraphQL mucho más a las solicitudes regulares de HTTP GET para las que las CDNs están diseñadas para manejar.

Bueno, ¿qué más podemos hacer además de las consultas persistentes? Hablemos sobre el control de caché de encuesta. ¿Qué es eso? Con nuestra API REST, simplemente podemos devolver un encabezado de control de caché desde un punto final específico.

Tal como hemos hablado, hasta que escribamos un nuevo punto final, este seguirá siendo el mismo, ¿verdad? Pero con GraphQL, mejoraremos constantemente las consultas en el frontend. Estamos agregando campos y moviendo campos. Tenemos diferentes versiones de la interfaz de usuario que se necesitan. Entonces, ¿cómo aseguramos que la indicación de control de caché se mantenga actualizada con la estructura de la consulta, incluso a medida que los data incluidos en el resultado cambien con el tiempo? Eso es lo que se pretende resolver con el control de caché de encuesta.

Esta es una especificación de cómo el servidor de GraphQL debe devolver indicaciones de caché a nivel de campo. Aquí podemos ver que viene con una implementación de referencia para JavaScript que nos muestra cómo podríamos especificar indicaciones de caché con diferentes niveles de especificidad. Aquí tenemos las indicaciones de caché, una edad máxima de 5 segundos para todo el esquema establecido con el control de caché. O podríamos tenerlo establecido en un tipo o campo gráfico, como hicimos aquí. Incluso podemos establecerlo en una única ejecución de un resolvedor. No es necesario que sea en todo el esquema. Esto es muy importante porque permite que nuestra API especifique la expiración de diferentes partes de data. No queremos que todo expire al mismo nivel. Mientras mantenemos la libertad del código en el frontend para especificar las consultas que necesite. Bueno, control de caché.

Al final del día, el motor combina todas estas indicaciones en un único encabezado de control de caché conveniente. Ese es nuestro ganador que las CDNs pueden entender. Solo una nota aquí. Si no estás utilizando una CDN, puedes usar el control de caché para alimentar la función de almacenamiento en caché de Apollo Engine 2, por lo que no es necesario utilizar específicamente una CDN. Entonces, para resumir todo lo que hemos hablado hoy, si tienes algunos datos gráficos de los que crees que te beneficiarías con un almacenamiento en caché de CDN en el borde, en realidad es muy sencillo hacer que todo funcione bien. Este es un gran ejemplo de cómo interactúan varias herramientas en las que hemos estado trabajando durante un tiempo. Primero, las consultas persistentes automáticas con Apollo. El enlace permite que las consultas utilicen GET mientras que las mutaciones siguen utilizando POST. En segundo lugar, el control de caché de Apollo te permite especificar información de control de caché de manera detallada orientada al esquema. Y en tercer lugar, Apollo Engine genera los IDs de consulta más pequeños, para que podamos utilizar esos IDs de consulta en nuestras solicitudes GET sin alcanzar el límite de tamaño de clave de caché. Y establecer el encabezado de control de caché para la CDN. Espero que hayas disfrutado mucho de esta charla. Si tienes alguna pregunta nuevamente, o si quieres conectarte conmigo, no dudes en encontrar todos mis contactos en mass.dev. Y espero poder hablar con todos ustedes en el canal de Discord de la conferencia. Gracias.