El caché de Apollo es tu amigo, si lo conoces

Así que soy Raman Lally. Estoy aquí desde Shopify y estoy dando una charla sobre cómo hacer amigos con la caché de Apollo. Ese fue mi único meme. Solo tenía espacio para uno, así que eso es más de mí. La razón por la que surgió esta charla es porque hemos estado utilizando GraphQL desde siempre y recién comenzamos a usar Apollo Client 3 y la gente se encontró con estos errores extraños y voy a hablar sobre uno. Pero quería hablar sobre cómo podemos evitar esos errores y conocer cómo funciona la caché es la mejor manera.

Entonces, alguien había creado esta consulta que extraía los metadatos de un producto y tenían esta consulta. No se ve exactamente así, pero había algo mal en esta consulta y esa segunda parte de datos simplemente no estaba llegando. ¿Verdad? La estaban consultando, no hay nada allí, y volveremos a esto en un minuto y veremos cómo podemos solucionarlo.

Entonces, ¿qué está sucediendo en la caché? ¿Qué hay exactamente allí? ¿Y dónde está? ¿Verdad? ¿Es un objeto de datos que estamos guardando en algún lugar? Estas son cosas que no sabía. Y ahora ustedes podrían saberlo. Está en memoria, como su nombre lo indica. Y ahí es exactamente donde se almacena. Cada vez que reconstruyas tu aplicación, se reconstruirá. Cada vez que actualices la página, volverá. No se guarda en ningún lugar, a menos que lo hayas guardado tú mismo. ¿Y qué hay dentro de ella? No es realmente tus datos. Es como una representación de tus datos. Toma los datos que obtuviste de tu consulta y almacenamos una versión de ellos. Antes de hablar de eso, quiero hablar de cómo obtenemos esos datos. Y eso son las políticas de búsqueda. Estas definen cuándo obtener tus datos de la caché y cuándo obtenerlos de la red. Hay seis de ellas y las voy a explicar rápidamente. Principalmente porque esto es una de las principales cosas que pueden causar un error en tu aplicación. Digamos que esperas obtener datos de la red de inmediato, o necesitas una nueva versión fresca. No esperas obtenerlos de la caché. Probablemente querrías intercambiarlos. Aquí está nuestra primera. Primero la caché, es nuestra primera.

Y es el predeterminado, y es muy simple. ¿Está toda tu data en la caché dorada? Si no lo está, vamos a ir a la red. Y la palabra clave aquí es toda. Entonces, si tienes una consulta idéntica, pero estás solicitando un campo adicional, lo hará de todos modos, porque todos esos data no están en la caché. Y luego, muy similar a esto, está solo la caché. Y lo mismo es cierto aquí, donde si toda esa data no está allí, te dará un error y no volverá. Y tenemos algunos otros como caching y networking. Entonces, este es interesante, porque va a buscarlo en tu caché y luego rellenar la caché desde la red, ¿verdad? Entonces, si tienes muchos datos que cambian con frecuencia y quieres que sean increíblemente consistentes, esta sería la forma de hacerlo. Y luego irá a la red, rellenará tu caché, pero siempre tendrás primero la caché. Y esto es muy similar, excepto que solo irá a la red y luego actualizará tu caché. Entonces, si necesitas obtener primero solo los datos actualizados y vas a esperar, algo como cargar y esperar, y luego lo guardaremos en la caché si vas a tener una consulta posterior, obténlo de allí. Y finalmente, solo la red. Muy simple, nada más ahí.

Entonces tenemos nuestros data, y sabemos cuándo lo obtenemos, y sabemos cuándo lo obtenemos de la caché, pero ¿qué hay en la caché? ¿Cómo se almacenaron esos data? ¿Verdad? Dije que no es exactamente tu data, es solo una representación de ella. Y la normalización es cómo se almacenó. Entonces se normaliza en pasos, y hay tres, básicamente, en los que se puede descomponer. Nuestro primer paso es, cualquier objeto data que llegue, lo vamos a dividir. Y lo vamos a dividir en todas las entidades de objeto que podría ser. Donde, ya sabes, en un momento, creo que era cada objeto data que puede existir en tu aplicación se dividiría y se normalizaría, y eso sería realmente genial. Pero no es exactamente el caso.

Imagina que teníamos esta consulta realmente genial. Verás que esto es de una aplicación de demostración que escribí que en realidad no podré mostrarte, pero lo enlazaré al final. Y es realmente fea. Entonces, básicamente aquí, podemos ver que los tres objetos que se descomponen tienen una cosa en común, y es que todos son identificables de forma única. Y eso nos lleva al siguiente punto, donde el segundo paso es después de descomponer todos estos objetos, queremos darles identificadores únicos, ¿verdad? Y la forma predeterminada de hacerlo es simplemente usando el nombre del tipo y el ID. Entonces, si tu objeto tiene un campo de ID, se normalizaría, o intentarían normalizarlo. Pero eso es solo generalmente, porque es posible que no tengas un identificador que sea exactamente ID. En esa situación, usarías la API de campos clave. Entonces puedes definir tus propios identificadores, como, digamos, si tuvieras UID como identificador para un objeto, podrías usarlo directamente. También podrías usar múltiples campos anidados para crearlo. Pero este es el mismo concepto que usar ID y nombre del tipo, ¿verdad? Puedes generar el tuyo propio, y de esta manera, esos objetos también se normalizarían. De lo contrario, se normalizarían bajo su objeto principal. Entonces, en la raíz, solo tendrías la consulta. Entonces, si no tuvieras un identificador en ningún objeto, sería este gran objeto de cualquier consulta que llegara. Los tenemos todos descompuestos, los tenemos en estos objetos individuales que son identificables, y los vamos a guardar en esta estructura de data aplanada. Y queremos esa estructura de data aplanada porque es fácil de acceder y podemos hacerla lo más pequeña posible. Y esa es básicamente la idea, tomamos esa otra consulta, y esto es exactamente cómo se ve la caché normalizada. Entonces, si extrajeras la caché y la examinaras, lo cual voy a mostrarte en un minuto, esto es exactamente cómo se ve. Y puedes ver que eso, como... Todos estos objetos que tenían identificadores, en realidad no están dentro o anidados dentro de los otros objetos. Solo tenemos una referencia a ellos. Y en cualquier momento, si esta consulta necesitara obtener este objeto, lo obtendría de esta referencia.

Pero la magia ocurre cuando tienes varias consultas que utilizan estos mismos tipos de objetos. Como, usamos tipos en todas partes. Simplemente estarán haciendo referencia al mismo objeto en la caché. Y ahí radica realmente el poder de esa normalización.

Estas son lavadoras. Así que esto fue mi improvisación sobre algo relacionado con la automatización, algo automático. No se me ocurrió nada mejor que esto. Pensé que tal vez una transmisión de automóvil también funcionaría. Pero en esencia, la idea es que tenemos nuestros data y vamos a obtener nuevos data después. ¿Verdad?

Y estoy seguro de que en algún momento has visto que si vuelves a consultar, los data se actualizan automáticamente. Y eso es realmente genial. Y nos encanta eso. Y las cosas automáticas son realmente geniales. Pero a veces las cosas automáticas no funcionan tan bien. Así que voy a meter esta camiseta en la lavadora y tiene una mancha. Y generalmente, todas mis manchas se lavan. Pero esta no se fue. Y creo que esto ya le había pasado a esta camiseta antes. Y era de arándano. Y era realmente fea. Así que pensé, bueno, sí. La lavadora es una porquería. Probablemente debería haberlo hecho a mano. Pero la lavadora no es una porquería, porque probablemente debería haber hecho algo antes de ponerla allí para que la función automática funcione mejor. Así que de eso vamos a hablar. A veces suceden actualizaciones no tan automáticas.

Entonces, cada vez que los data llegan a tu aplicación, se normalizan y se almacenan en caché, sucederá una de dos cosas si ya hay data allí. Se fusionarán o se agregarán. Solo hay dos opciones. Entonces, ¿cuándo se fusiona automáticamente? ¿Cuáles son esos escenarios en los que sucede y funciona, y estamos realmente contentos con eso? El primero es si solo estás actualizando una entidad única y devuelves esa entidad con su identificador y sus campos actualizados.

Es realmente simple de hacer. Nuevamente, como vimos, todos esos objetos están en este hash. Podemos agarrarlos fácilmente por su identificador y fusionar estos nuevos campos. Y esto es lo que sucederá con mayor frecuencia.

Pero el segundo caso es si tienes una lista o una colección de entidades y devuelves todas ellas con todos sus identificadores y todos los campos que deben actualizarse. Entonces, esto no funciona si devuelves, digamos, algunos de ellos o solo uno de ellos. Debes devolver toda la colección para actualizar cada uno de ellos. Así que hablemos de cuando no funciona, porque estos son los casos en los que nos encontramos y es una situación realmente fea.

Entonces, primero, supongamos que tu respuesta data que está llegando no está relacionada con la actualización que deseas que ocurra. Así que sé que hubo algunas situaciones en las que teníamos un objeto que íbamos a marcar como favorito, como un producto que se estaba marcando como favorito. Y lo marcaste como favorito, la mutación se envía, vuelve. Devuelves el ID y el estado de favorito, y eso se actualiza y se actualizará ese producto dondequiera que se esté utilizando en esa interfaz de usuario. Lo que no se actualizará es cuántos productos están marcados como favoritos. Digamos que tenías una interfaz de usuario que mostraba el número de objetos marcados como favoritos. Puede estar relacionado, pero no es el mismo data. Entonces, en este escenario, tendrías que escribir tu propia función de actualización y actualizar ese data tú mismo, aunque te parezca relacionado.

Luego, el resto de estos se trata de listas, porque eso es realmente lo más difícil de gestionar, donde, nuevamente, si no devuelves toda la lista de objetos actualizados, no obtendrás esa actualización automática. Lo mismo ocurre si cambia el orden. Entonces, si enviaras, digamos, objetos en el orden 1, 2, 3, 4, y lo cambias a 1, 2, 4, 3, cuando regrese, los objetos siguen siendo los mismos. Lo único que cambia es el orden. No se reflejará en tu interfaz de usuario. Eso es algo que tendrías que escribir automáticamente. Y principalmente porque la caché no hace suposiciones sobre cómo quieres almacenar tus data o cómo debería verse tu data dentro de la caché. Esos objetos son idénticos. Y lo único a lo que hace referencia son las referencias a esos objetos. Y finalmente, agregar o eliminar cosas, lo cual también es realmente molesto, porque si fuera a desmarcar algo como favorito, puedo actualizar el estado de favorito de ese objeto, pero no puedo eliminarlo de una lista de objetos favoritos. Eso es algo para lo que tendrías que escribir una función de actualización, porque, nuevamente, no sabe que no puedes devolver algo de una mutación y decir, OK, sí, ahora elimina esto por mí. Solo puedes devolver algo. Entonces, nuevamente, las funciones de actualización existen para hacer eso, pero en estos escenarios, como, puede ser un error si no esperas que se actualice automáticamente. Y definitivamente nos hemos encontrado con eso.

Volveremos a esto, porque ahora hemos hablado de un par de cosas que entrarían en juego si quisiéramos resolver este problema. Pero básicamente la idea aquí era que los metadatos del producto son del mismo tipo que este tipo de metadatos aquí abajo. Y luego esta persona estaba consultando esto, y decía, oh, como, slug es indefinido. No sé por qué slug es indefinido. Y esto se debe principalmente a que el identificador para los metadatos del producto y el identificador para los metadatos eran los mismos, ¿verdad? Entonces esos objetos se normalizaron dentro de la caché. Y esperarías que sus hijos también lo estuvieran. El problema es que 'values' tiene un ID y este valor no tiene un ID. Y lo que le sucedió a este valor es que se intentó normalizar, pero no se pudo. Y el objeto del otro valor fue el que se guardó dentro de este objeto totalmente normalizado. Entonces, la forma de resolver esto es simplemente agregarle un ID. Y ahora puedo encontrarlo, pueden actualizarlo y ahora pueden ser, ya sabes, normalizados correctamente.

Ahora pasamos a la última parte, y la parte que más me emocionaba, que era la recolección de basura y cómo funciona la evicción. Estoy seguro de que todos han encontrado la recolección de basura en algún momento. Me di cuenta después de que en realidad es reciclaje, y no basura. Estaba pensando en poner algo encima, pero no lo hice.

En general, la recolección de basura, intentamos recuperar memoria de nuestra aplicación, y en JavaScript, eso generalmente ocurre en segundo plano, ¿verdad? No tenemos que interactuar manualmente con ella. En Apollo, sí tenemos que interactuar manualmente con ella. Y así es como lo haríamos. Intenté hacerlo lo más pequeño posible pero aún legible, ¿verdad? Pero principalmente porque es tan pequeño, ¿verdad? Llamarías a esta recolección de basura para limpiar cualquier objeto no referenciado en tu caché. Y mostraremos cómo se verá eso en un segundo.

Pero lo otro es que esto devolverá los IDs de todo lo que se haya recolectado. Aquí está esa aplicación ficticia de la que hablaba. Usando las mismas consultas que antes. Así que hay un servidor GraphQL. Lo estamos consultando para todos esos píxeles, incluyendo todos los espacios en blanco. Y cada uno de ellos es identificable individualmente. Por lo tanto, ocupa... Puedes ver que simplemente imprimí ese tamaño de caché. Ese no es el tamaño real de la caché. Es solo la cantidad de claves que había en la caché. Pero es solo para representar cuán grande podría ser la caché en ese momento. Y tiene tantos elementos. Y la idea era que hay como un... Dado que todos estos tienen IDs, todos son direccionables, todos se están normalizando. Digamos que vamos a cambiar el color de Pikachu a naranja. Puede que notes que la caché ahora es el doble de grande. O más. ¿Verdad? Entonces, el problema aquí es que hicimos esta mutación... Este es un ejemplo muy ficticio. Pero básicamente todos esos identificadores cambiaron. O la gran mayoría de ellos.

Y volvieron y no pudieron fusionarse. ¿Qué pasó? Tuvieron que ser agregados. ¿Verdad? Todos esos otros objetos todavía están ahí. Simplemente no son accesibles a través del objeto raíz real. No los necesitamos. Nuestra interfaz de usuario no los necesita. Pero siguen ahí y ocupan espacio. Esa es realmente la razón principal por la que queremos deshacernos de estas cosas.

Entonces digamos que lo ejecutamos. Y esto es, nuevamente, una versión más rudimentaria de todos esos otros data. ¿Cómo recopilamos todos estos elementos que no se están referenciando? La idea es que el recolector de basura eche un vistazo a la caché normalizada y de forma recursiva recorra cada nodo que existe dentro de la caché hasta encontrar todos tus nodos hoja al final. Y cualquier cosa que no haya sido visitada será eliminada.

Entonces esta es nuestra nueva consulta. La que tiene todo el color naranja con todos esos nuevos identificadores. Y esta es nuestra consulta original que tenía el color naranja. Y puedes ver que ya no está siendo referenciada por root, porque ya no estamos usando ese data. No es nuestra consulta principal. Pasaríamos por todos estos nodos, boom, todos están bien. Y los que no fueron visitados serán eliminados por el recolector de basura.

Entonces, digamos que había un objeto específico que queríamos conservar o queríamos hacer que incluso si no es accesible, no se elimine, usaríamos una API de retención para esto. Pero realmente lo que sucede dentro de la caché cuando retienes algo es que lo agregamos a este ID raíz adicional. Entonces, dentro de la caché normalizada hay un campo separado, supongo, para hacer un seguimiento de todos estos identificadores. Y lo curioso que noté cuando estaba trabajando con esto fue que si alguna vez escribes un fragmento, como si alguna vez usas el write fragment o write query, esos objetos que escribes directamente también se retienen automáticamente. Entonces, si estabas escribiendo todos los objetos, como un montón de objetos aleatorios en tu caché, y estabas ejecutando el recolector de basura, no se están recolectando, es porque todos se estaban reteniendo por defecto, y es porque los alteraste directamente. Entonces, si quisieras deshacerte de ellos, puedes liberarlos después del hecho.

Entonces, más o menos se verá así. Digamos que queríamos conservar el cachete. Creo que eso es lo que lo llamo aquí, ¿verdad? Sí. Y lo que sucederá es que el recolector de basura recorrerá, visitará todos esos nodos que conoce, luego visitará todos estos nodos a los que has hecho referencia dentro de tu retención, y boom, no se deshará de esos chicos malos. Entonces, la última parte es que lo que el recolector de basura no va a eliminar es cualquier objeto que sea accesible, ¿verdad? Es posible que desees deshacerte de ellos manualmente.

Y hablamos de esto antes, donde agregar y eliminar cosas es algo que debes hacer manualmente en lugar de que ocurra automáticamente cuando vuelves a consultar. Entonces, nuevamente, ahí es donde entra en juego la API de evicción. Por lo tanto, puedes eliminar directamente un objeto completo de la caché si así lo deseas. El único problema es, supongamos que te deshiciste de esa raíz que estaba referenciando todos esos otros nodos que vimos antes, por lo que tenía una referencia a cada uno de esos objetos. Teóricamente, ya nada tiene una referencia a esos objetos si te deshiciste de ese objeto de nivel superior. Entonces, si alguna vez vas a usar esto, tendrías que ejecutar el recolector de basura después del hecho para deshacerte de todos esos objetos que ya no se pueden referenciar.

Y luego puedes ir un paso más allá y simplemente eliminar campos específicos si así lo deseas. Lo cual te brinda mucho más poder para actualizar las consultas después de que se produzca un cambio. Y ahí lo tienes realmente. Hemos recorrido el ciclo de un objeto desde su obtención hasta su normalización dentro de la caché hasta cómo lo actualizaríamos o cómo se actualizarían automáticamente esas cosas y finalmente a la recolección y eliminación de los mismos. No pude escribir la última línea porque no encaja de nuevo en la obtención. Así que me sentí realmente incómodo al respecto. Iba a mostrar la demostración pero no tengo tiempo para eso. He enlazado todas las demos realmente feas que escribí y solo tienen ejemplos de todo de lo que estaba hablando aquí. Así que si alguien quiere echarles un vistazo, puedo proporcionar los enlaces.

Y luego un poco de publicidad descarada. Gracias. Gracias, Raman.

Hagamos algunas preguntas. Llamo a mis recogidas de Uber recolección de basura. ¿Qué política de obtención recomiendas usar para una aplicación de página única estándar? La predeterminada. Caché primero, honestamente. Diría que cubriría la gran mayoría de los escenarios que deseas cubrir. No creo que puedas tener problemas al usar esa en comparación con las demás. Pero querrías usar una combinación. Puedes hacerlo por consulta. Si tienes 10 consultas, algunas de ellas solo querrán obtener datos de la caché o generar un error.

Hablando de por consulta, ¿es la estrategia de caché algo que debes decidir antes de comenzar o puede evolucionar con el tiempo? Para nosotros, definitivamente evolucionó con el tiempo. No quieres comprometerte completamente antes de comenzar tu aplicación. Las cosas pueden cambiar muy rápidamente, ¿verdad? Y lo harán. Y lo harán.

Así que prepárate. ¿Has tenido alguna historia de terror con la caché? Yo tengo una. Y esa es la razón principal por la que escribí esto en primer lugar. Drama. Teníamos esta página de inicio con todos estos carruseles en ella. Y ya era una mala idea, porque había tres carruseles en esta página de inicio y no teníamos ninguna entrada en eso. Pero todos compartían datos de productos similares. Y lo que sucedía es que podías marcar como favoritos productos dentro del carrusel. Y no nos dimos cuenta de este problema hasta más tarde, pero debido a la forma en que nuestras mutaciones estaban escritas, solo devolvían si algo realmente se marcaba como favorito o no. No su ID y el estado de favorito. Así que marcabas como favorito un objeto en el primer carrusel y en los carruseles dos y tres, no estaban marcados como favoritos. Y alguien lo mencionó, y pensamos, esto es una gran falla en nuestra estrategia de mutaciones design. Así que la gente simplemente se sumergió, y descubrimos, oh, podríamos actualizar automáticamente todo.

Alguien sugirió que podríamos simplemente volver a consultar todas estas consultas para asegurarnos de que todo se actualice cada vez. Pero ya sabes, esa es una forma horrible de hacerlo. Así que no queríamos ir por ese camino.

¿Dirías que los favoritos fueron lo que te trajo aquí? ¿Y mira dónde estás ahora? Sí, mírame ahora.

Tenemos otra pregunta, que es, ¿cuándo deberíamos ejecutar la recolección de basura manualmente en lugar de hacerlo automáticamente? Supongo que depende de tu aplicación. Como habrá muchas aplicaciones en las que realmente no necesitas ejecutarla manualmente. Como no terminarás con un montón de objetos huérfanos antes de que alguien cambie la página o se mueva a otro lugar. Pero si sabías que ibas a hacerlo, y sabías que ibas a descartar objetos así podrías ejecutarlo, ya sabes, después de cualquier consulta. No es muy intensivo en tiempo, ¿verdad? Genial.

Como recordatorio, Raman estará en los puestos de los oradores justo afuera después de esto si quieres hablar con él o hacer más preguntas, otro gran aplauso. Gracias por estar aquí con nosotros.