¡Utiliza tu esquema para el almacenamiento en caché!

Hola a todos. Mi nombre es Marco Locher y soy parte del equipo de GraphCDN. Si estás interesado en GraphCDN o en el almacenamiento en caché de GraphQL en general, espero que no te hayas perdido la charla de Max sobre cómo almacenar en caché las API de GraphQL más temprano hoy. En esta charla relámpago, me gustaría darte algunos consejos sobre cómo tu esquema puede ayudar al almacenamiento en caché de las API de GraphQL, tanto a través de cachés de documentos como GraphCDN, como a través de cachés normalizados implementados en clientes como Apollo Client o Urql. El primer punto del que me gustaría hablar puede parecer muy obvio, pero tener ideas sobre los tipos que deseas almacenar en caché y tener un nombre consistente para esos campos es bastante importante. Hemos visto algunos proyectos de nuestros propios usuarios donde cambiar eso tuvo un gran impacto. Si puedes usar ID o underscore ID, la mayoría de los clientes y herramientas relacionadas de GraphQL utilizarán esos campos de forma predeterminada. Sin embargo, si no puedes hacerlo porque ya estás usando otros nombres para esos campos en tus API heredadas o no es fácil, puedes configurar tus clientes para usar los campos apropiados. Es muy importante asegurarse de que esa configuración sea precisa. En GraphCDN, por ejemplo, configurarías esos campos como campos clave, y estos definen cómo puedes encontrar esos objetos en la caché nuevamente, y lo que es más importante, cómo puedes purgarlos si realizas modificaciones en tu backend. De manera similar, recomendamos que te adhieras a IDs globalmente únicos en tu aplicación, por ejemplo, utilizando UUID o algo similar, pero si eso no es algo que puedas acomodar, también hay soluciones alternativas que la mayoría de los clientes implementan.

El segundo punto es mantener tus tipos consistentes. Al trabajar con nuestros usuarios, hemos visto esquemas donde los tipos se duplican para agregar un solo campo. Sin embargo, eran idénticos en todos los demás aspectos y representaban los mismos datos. Esto hará que tu caché sea menos eficiente, ya que ahora necesitará almacenar los datos dos veces, dependiendo de si ese campo adicional está presente o no. De manera similar, si deseas enriquecer los datos con metadatos que solo pueden ser requeridos en un contexto muy específico, como los resultados de búsqueda, por ejemplo, donde deseas mostrar la cadena de búsqueda de manera destacada, recomendamos implementar un concepto como la especificación de conexión de cursor para esos metadatos, en lugar de extender tu tipo con campos que solo se requieren en un contexto muy específico. Aunque la especificación de conexión de cursor está principalmente destinada a manejar la paginación, también se presta muy bien para ser extendida a otros casos de uso similares, como el que acabo de mencionar.

Muy importante también es asegurarse de que tu caché sea consciente de tu esquema. Cada caché ofrecerá alguna funcionalidad, ya sea consciente del esquema o no. Sin embargo, si haces que tu caché sea consciente del esquema de tus datos, desbloqueará funcionalidades adicionales que de otra manera no serían posibles. Puede tomar decisiones más inteligentes basadas en los tipos devueltos por tus consultas, algo que es especialmente importante en el contexto de los fragmentos o cuando se utilizan interfaces. Hacer que tu caché sea consciente de tu esquema también le permitirá devolver resultados parciales basados en los datos ya almacenados en caché si los campos faltantes se designan como opcionales. Y mientras tu aplicación ya está mostrando cierta información al usuario, la caché recupera los campos faltantes en segundo plano. Sin ese conocimiento, esa habría sido una consulta que habría sido devuelta directamente por tu API y la caché no habría estado involucrada en absoluto.

Y por último, si estás utilizando una caché de documentos como RefCDN, en algunos casos, es posible que sea mejor dividir tus consultas en lugar de enviar solo una. Sé que GraphQL es conocido por su flexibilidad y por el hecho de que puedes personalizar cada consulta para obtener exactamente los datos que necesitas. Pero en algunos casos, dividir las consultas y tener más de una puede ser beneficioso. Por ejemplo, echemos un vistazo a una consulta que obtiene una lista de los artículos más recientes de un blog, así como una lista de recomendaciones basadas en el usuario que ha iniciado sesión actualmente. Una caché basada en documentos como RefCDN, por ejemplo, analiza toda la respuesta que obtienes. Y si está vinculada a un usuario específico, solo podrá utilizar esos datos en caché para ese usuario específico en el futuro. Sin embargo, si divides esa consulta en una parte pública y una parte más privada, la parte pública se puede reutilizar para cada usuario, sin importar si han iniciado sesión o no, sin importar dónde se encuentren. Y especialmente cuando trabajas tanto con una caché basada en documentos como con una caché normalizada como parte de tu cliente de GraphQL, el cliente no se verá afectado por eso, ya que ya tendrá la mayoría o incluso todos los datos requeridos en su caché local y no requerirá ninguna ida y vuelta al servidor en absoluto.

Muchas gracias por escuchar. Espero que hayan sido algunos puntos valiosos para todos ustedes. Si tienen alguna pregunta, estaré encantado de responder durante la sesión de preguntas y respuestas o también pueden contactarme en Twitter. Gracias.