React Query - Las partes malas

React Jets Introducción a React Query Una breve introducción a React Query React Query, la parte mala. Realmente espero que esto sea rápido, como una charla relámpago, de verdad, porque creo que en su mayoría React Query es simplemente genial. Creo que es amado por la comunidad por la experiencia de desarrollador y la experiencia de usuario que proporciona. Sé que es una afirmación audaz, así que intenté traer algunas pruebas para respaldarla.

Si miramos los números de descargas semanales en NPM, creo que React Query ha crecido mucho este año de casi 4 millones a 6 millones de descargas semanales. Creo que esos son números enormes, y si lo comparamos con los números de React, que también, React está creciendo fuerte, situándose en alrededor de 27 millones de descargas semanales, de repente la curva ya no parece tan impresionante, pero creo que aún podemos concluir de eso, que React Query se utiliza en aproximadamente el 20% de nuestras aplicaciones de React o en casi una de cada cinco aplicaciones. Algunas de esas aplicaciones, ellas mismas tienen millones de usuarios, como Sentry, Blue Sky o JetGPT, así que creo que React Query realmente obtiene mucha exposición.

Ahora, por supuesto, los números de descargas y el uso y la exposición no lo son todo, solo porque algo se use no significa realmente que sea querido. Así que tal vez una mejor manera sería mirar las encuestas. Está la encuesta State of Frontend 2024, que hizo la pregunta, ¿qué herramientas has usado para obtener datos en el último año? Ahora, no voy a ser quisquilloso aquí que React Query no es una biblioteca de obtención de datos, como Axios o Fetch, que están listadas aquí, pero detrás de esas, en realidad viene con un sentimiento muy positivo, porque solo al 2.8% de las personas que lo usaron no les gustó. Y State of React tiene una pregunta similar sobre utilidades para cargar y gestionar datos, y si agrupamos eso por sentimiento positivo, entonces TensorStripe Query en realidad sale en la cima con un poco más del 44%. Así que estoy realmente feliz de que a los desarrolladores parezca gustarles la biblioteca, porque la he estado manteniendo durante los últimos cuatro años.

Mi nombre es Dominic. Soy un ingeniero de software que vive en Viena, donde me uniré al equipo de plataforma frontend en Sentry el próximo mes. Y puedes encontrarme como TK Dodo en línea casi en todas partes, y también tengo un blog donde escribo sobre React y TypeScript, y por supuesto, React Query.

Ahora, he escrito y hablado mucho sobre por qué React Query es genial, y todavía creo que realmente lo es, pero, ya sabes, todo es una compensación. Y si usamos cualquier tecnología, generalmente es una buena compensación si lo que obtenemos a cambio vale más para nosotros o es mejor para nosotros que lo que estamos intercambiando. Ahora, creo que React Query es realmente una buena compensación para la mayoría de las situaciones, pero, por supuesto, hay casos donde podría no ser la mejor opción o la opción perfecta. Así que hoy, quiero hablar sobre estos casos, pero también tal vez desmentir algunos mitos que he escuchado sobre ello que hacen que parezca que es malo cuando en realidad tal vez no lo es. Así que tal vez la charla debería ser más como React Query, las compensaciones.

Bien. Comencemos con el primer punto, el elefante en la habitación, que es el tamaño del paquete. Que React Query tiene un tamaño de paquete enorme es algo que a menudo escucho como su mayor inconveniente. Y para llegar al fondo de eso, primero tenemos que establecer lo que no es el tamaño del paquete, porque no es lo que ves en npm, ¿verdad? Este es el tamaño que se envía a los desarrolladores cuando instalan la biblioteca.

Y también enviamos algunos mods de código para las actualizaciones que tenemos. Este definitivamente no es el tamaño que se envía al consumidor.

Bien. Tampoco es lo que ves en Bundlephobia. Creo que Bundlephobia es un buen sitio para obtener una visión general rápida, pero no entiende ESM correctamente, lo cual creo... No, no creo que nadie haga eso. Pero, por ejemplo, enviamos una versión especial heredada para todos los empaquetadores, como Webpack 4, que no está tan optimizada, y Bundlephobia lo detecta. Así que lo que ves aquí también es todavía demasiado grande. Y si usas un empaquetador más moderno, obtendrás una salida más pequeña.

Así que realmente me gusta Bundle.js para obtener una buena visión general, porque simplemente construye lo que exportamos sobre la marcha con ESBuild, y luego muestra el impacto del tamaño. Así que si exportamos todo de RareQuery, llegamos a 12.4 kilobytes minzip. Ahora, eso no es nada, pero tampoco creo que sea mucho. Y si nos importa el tamaño, probablemente deberíamos usar compresión Brotli en lugar de gzip. Así que si hacemos eso, llegamos a unos agradables 12 kilobytes redondos. Y eso es realmente cuando usamos cada característica que la biblioteca tiene para ofrecer. Pero este no es el punto de partida típico. Así que generalmente podemos llegar bastante lejos con solo exportar un cliente de consulta, el proveedor, y probablemente usar consulta y usar mutación. Y si hacemos eso, si lo reducimos, esto nos lleva a menos de 10 kilobytes. Eso es 9.63.

Así que no me malinterpreten. Creo que el tamaño del paquete es algo importante a considerar antes de agregar una dependencia. Pero el debate sobre lo que es ligero y lo que no lo es no es realmente el más importante cuando se trata de una pieza tan central, como tu administrador de estado envejecido, especialmente porque hay una métrica que fácilmente se pasa por alto, y es el tamaño del paquete que ahorras por el código que no tienes que escribir. Creo que una biblioteca como RackQuery realmente se paga sola, porque cuanto más la usas, más te ahorra código que no tienes que escribir tú mismo.

Así que al verificar el tamaño del paquete de una biblioteca, es importante no pensar en el tamaño que agrega inmediatamente, sino también en lo que puede ahorrarte a largo plazo. Y en esa escala, creo que RackQuery es una clara ganancia, porque la mayoría de las soluciones personalizadas probablemente serían más grandes, o podrían fallar en algunos casos extremos, porque, sí, el almacenamiento en caché y la validación del caché son realmente difíciles.

Bien, el siguiente mito que quiero analizar es el hecho de que con RackQuery ni siquiera puedes obtener datos al hacer clic en un botón. Y escucho eso mucho, y el argumento es que es difícil para RackQuery hacer obtención de datos imperativa. Y es cierto porque RackQuery es declarativo por defecto. Lo que hacemos es escribir el hook use query, y le pasamos una clave de consulta y una función de consulta, y se ejecuta automáticamente para nosotros. Ahora este código intentaría leer la consulta del caché, y si no existen, irá y los obtendrá por nosotros. Hasta ahora, eso se ve bien, pero ahora intentemos agregar algo de filtrado a nuestra lista de tareas.

Cuando agregamos un formulario de filtro, ejecutamos un callback de aplicación, y cuando se llama, queremos volver a obtener eso con esos nuevos filtros. Así que si exploramos lo que devuelve use query por nuestra cuenta, podríamos encontrar la función refetch, y podríamos querer simplemente pasar una función refetch a ella. Creo que esto parece razonable, pero excepto que refetch no toma ningún argumento, así que esto simplemente no funciona. Y entiendo la frustración por esto, pero simplemente no es como RackQuery fue diseñado para funcionar. Porque mira, si tenemos una clave codificada como tasks, y volvemos a obtener eso con diferentes argumentos, no solo sobrescribiríamos los datos que habíamos almacenado en caché para esos otros filtros, también correríamos en condiciones de carrera con ese efecto.

Así que RackQuery ha resuelto ambos problemas con el enfoque declarativo al poner todas nuestras dependencias, y eso es todo lo que usamos dentro de la función de consulta, en la clave de consulta. Y eso significa que tenemos que almacenar nuestro filtro aplicado en algún lugar, y en este ejemplo simplemente los he puesto en el estado de React. Ahora cuando esos filtros aplicados cambian, la clave cambia y RackQuery verá una nueva clave de consulta y luego obtendrá Y este enfoque nos llevará del pensamiento imperativo, como si hago clic en ese botón, quiero hacer alguna obtención, hacia la forma declarativa de quiero datos que coincidan con este estado, y cómo cambia es realmente irrelevante. Y también es relevante dónde almacenamos esos filtros aplicados.

He usado useState antes, pero en realidad es un cambio bastante directo hacer una navegación con diferentes parámetros de búsqueda si usamos algo como 10StackRouter. Esto es, por supuesto, seguro en cuanto a tipos, dependiendo del esquema de parámetros de búsqueda que hayamos definido en nuestra ruta. Y ahora obtenemos un montón de cosas gratis, como por ejemplo URLs compartibles o navegación con el botón de retroceso del navegador, lo cual creo que es realmente genial. Otra cosa genial es que si cambiamos los filtros de nuevo a algo que ya hemos buscado, como dije antes, obtenemos un resultado instantáneo. Y eso es porque RackQuery almacena todo por separado por la clave. En ese sentido es un caché de documentos simple donde las respuestas completas se almacenarán para cualquier clave dada. Así que sí, en este ejemplo esto también significa que si una tarea está tanto en estado abierto como en prioridad alta, estará en ambos cachés. Porque no hay almacenamiento en caché normalizado en RackQuery. En un caché normalizado, cada pieza de datos se almacena solo una vez, y otras partes solo la referencian para evitar esa duplicación de datos.

Hay soluciones dedicadas para GraphQL, por ejemplo, como Apollo Client o Urql, y ofrecen almacenamiento en caché normalizado porque son conscientes del esquema y las relaciones entre entidades. Pero RackQuery en este sentido no sabe nada, no sabe qué hay en el caché, solo conoce la promesa que se devuelve. Ahora tenemos una larga lista de comparaciones de características en nuestra documentación y el almacenamiento en caché normalizado es prácticamente lo único que no soportamos. Es un problema bastante difícil de resolver y también puede añadir mucha complejidad a tu lógica de caché. Así que la compensación que hemos tomado es no soportarlo. También creo que para la mayoría de las aplicaciones simplemente volver a obtener datos después de una invalidación probablemente funcione bien y también es más fácil de razonar. Así que sí, si estás usando GraphQL y necesitas almacenamiento en caché normalizado, RackQuery podría no ser la mejor opción para ti. Sin embargo, hay una solución comunitaria que quiero destacar que se llama Normie. Intenta traer normalización automática y actualizaciones de datos a las bibliotecas de obtención de datos y tiene integraciones para RackQuery, SWR y RTKQuery. Así que podrías querer echarle un vistazo si eso te parece interesante.

Así que no hacemos almacenamiento en caché normalizado porque queremos mantener las cosas simples pero aún así una cosa que escucho mucho es que RackQuery es complicado y tiene una curva de aprendizaje pronunciada. Ahora creo que si algo es fácil de entender eso siempre es subjetivo. Podría haber algo fácil de entender para ti que es un misterio total para mí. Pero creo que es innegable que RackQuery, como cualquier concepto que vale la pena aplicar, tiene una curva de aprendizaje y también tiene una superficie de API que no es la más pequeña. Fui mucho a los detalles del diseño de la API de RackQuery en mi última charla en la React Advanced Conference a principios de este año. Así que si quieres una mirada en profundidad a eso, por favor échale un vistazo. Pero solo para tocar el tema creo que Tana tiene un gran tweet que resume los objetivos de diseño de RackQuery donde dice que la API de consulta es en realidad de tamaño medio cuando la desglosas toda pero la parte más importante es que puedes entender y aprender cómo usarla comenzando con una sola consulta que proporciona el 80% de toda la propuesta de valor en el primer intento. A partir de ahí, el resto de su API se puede aprender gradualmente si es necesario. Así que aunque la API de consulta podría parecer abrumadora al principio, no necesitamos aprender todo de una vez. Podemos comenzar solo con useQuery con las opciones mínimas requeridas que son la clave de consulta y la función de consulta. Y ya obtenemos un montón de cosas solo usando este código simple. Obtenemos almacenamiento en caché y duplicación de solicitudes, hay stale while revalidate, actualizaciones en segundo plano, gestión de estado global, reintentos, como la lista sigue y sigue. Y luego más tarde podríamos añadir una mutación para hacer algunas actualizaciones y luego vincular eso de nuevo a la consulta con invalidación de consulta. Ahora eso ya es un poco más de código pero con esos dos podemos llegar muy lejos en nuestra aplicación. Y una vez que la complejidad de nuestra aplicación crezca, podríamos querer mirar algunas cosas más profundas que RackQuery tiene para ofrecer. Tal vez queramos añadir una actualización optimista aquí y allá en uno de nuestros lugares o tal vez necesitemos una consulta infinita a veces. Ahora esos son un poco más complicados y luego todo el camino en esta escala poderosa y flexible tenemos nuestro sistema de complementos y nuestras suscripciones de caché de muy bajo nivel que estamos usando por ejemplo para construir nuestras DevTools. Ahora esos son realmente poderosos y flexibles pero una vez que alcanzas una cierta complejidad de aplicación, podrías estar realmente feliz de que esos existan también. Pero creo que la API de consulta está absolutamente diseñada para evolucionar contigo. Así que sí, no creas que es necesario aprender todo desde el principio, si eso se siente abrumador.

Sí, hay mucho que aprender pero definitivamente podemos llegar allí de manera incremental. Bien. Así que una vez que hemos aprendido la API y pensamos que es realmente genial, queremos empezar a gestionar todo el estado con ella, ¿verdad? Pero como ReqQuery es malo, realmente no quiere que hagamos eso. Está realmente diseñado para trabajar solo con estado asincrónico porque es un gestor de estado asincrónico que conoce las necesidades del estado del servicio que tenemos y es un buen gestor de estado del servicio que conoce las necesidades del estado del servicio que estamos almacenando en caché. Sabe que los datos que estamos viendo son solo una instantánea de la fuente de verdad del momento en que los obtuvimos y que la fuente de verdad real vive en el servidor. Así que lo que intenta hacer es intentar revalidar y mantener nuestros datos actualizados porque también es una herramienta de sincronización de datos. Y podría incluso hacer algunas suposiciones sobre nuestra conexión de red cuando obtiene ese estado y podría incluso intentar obtener ese estado de nuevo. Estas son todas cosas que amamos de ReqQuery pero no es algo que necesitemos cuando queremos gestionar algún estado sincrónico como por ejemplo un toggle de barra lateral. Si yo escribiera ese código en ReqQuery probablemente se vería así pero no hagas esto. Está lejos de ser ideal. Necesitamos hacer un montón de cosas aquí. Necesitamos idear una clave única como el estado de la barra lateral que no colisione con nada más que tengamos en nuestra aplicación. Ni siquiera tenemos una función de consulta aquí porque no hay nada asincrónico que hacer. Solo pasamos datos con datos iniciales sincrónicamente y luego los actualizamos con set query data. Y por último, necesitamos desactivar un montón de opciones de configuración para realmente detener a ReqQuery de intentar lo que quiere hacer por defecto, que es gestionar y sincronizar ese estado asincrónico. Así que creo que hacer algo como esto no es fácil de hacer bien. También es un poco verboso y tampoco es muy eficiente. Así que la división en estados de cliente y servicio que tenemos es realmente a propósito porque tienen diferentes necesidades. Así que realmente usaría la herramienta adecuada para el trabajo adecuado. Y hay muchas otras soluciones para gestionar el estado del cliente. Por ejemplo, una que me gusta es Zustand porque es mínima, eficiente y no tiene opiniones. Todo lo que tenemos que hacer aquí es definir una tienda con nuestro estado y luego las acciones para actualizarlo. Y luego he creado un hook personalizado solo para mantener la misma interfaz que tenía en la implementación anterior. Y algo similar que también me gusta bastante es XStateStore que se ve bastante similar pero funciona un poco mejor en TypeScript porque los tipos se infieren y también es impulsado por eventos. Pero la cuestión aquí es que no hay sorpresas con ninguno de los dos. Ambos son perfectamente capaces de gestionar ese estado del cliente para nosotros. Así que creo que definitivamente hay mejores opciones que solo usar ReqQuery para todo. Así que el último punto que tengo es un punto extra. Creo que es un poco gracioso que a veces escucho la pregunta como por qué siquiera necesitamos una biblioteca de terceros para hacer algo tan básico como la obtención de datos en React? ¿Por qué esto no está simplemente integrado en React? Y realmente no puedo responder eso porque no trabajo en React pero ciertamente entiendo la frustración de que no tengamos algo una primitiva de agente integrada en React como hay, por ejemplo, un create resource en SolidJS. Pero creo que la razón de eso podría ser que el equipo de React realmente intenta obtener una API correcta antes de realmente lanzarla.

Y como ejemplo, a menudo me he preguntado, o creo que muchos de nosotros a menudo nos hemos preguntado, por qué no tenemos selectores de contexto en React. Eso es algo que mucha gente ha estado solicitando para obtener esas suscripciones de grano fino a un contexto de React. Creo que es la razón por la que todas esas otras bibliotecas de gestión de estado incluso existen es que esto no existe. Tendríamos un contexto de configuración con un montón de configuraciones probablemente y luego un tema encima de eso y use-theme solo se suscribiría a ese tema. Y luego encima de eso, tendríamos use-color, que solo volvería a renderizar el componente que lo usa cuando ese color específico cambie. Ahora, esto no existe y creo que probablemente no es porque sería demasiado difícil de implementar sino porque el equipo de React tiene una visión diferente. Es que creamos un nuevo operador use dentro de use-memo y luego React se detendrá de renderizar si devolvemos el mismo valor. Ahora, creo que esto ya compone mucho mejor que los selectores y eventualmente, podría llevar a un lugar donde podamos simplemente escribir el mismo código sin use-memo en absoluto gracias al compilador de React. Ahora, creo que esa es una gran visión pero lleva tiempo llegar allí, así que esto no es sintaxis real, no existe. Y por supuesto, con la obtención de datos, fue una historia similar porque todos solo querían tener use-query pero el equipo de React simplemente piensa en grande. Creo que suspense es una arquitectura hermosa donde tus componentes se desacoplan de manejar estados de carga y error y también funciona realmente, realmente bien con TypeScript porque en este caso, los datos nunca pueden ser indefinidos. Y por supuesto, la visión de React va más allá de la obtención de datos del lado del cliente ahora que tenemos componentes de servidor asincrónicos. Realmente desearía tener una cita del equipo de React pero no pude encontrar una buena así que solo voy a decirlo yo mismo que suspense y los componentes de servidor son la primitiva asincrónica que hemos estado esperando. Y sí, si estás trabajando con un framework que soporta componentes de servidor entonces por favor úsalos y hasta entonces, siéntete libre de usar query. Gracias. Así que gracias por la charla y hay mucho amor de hecho en la comunidad como mencionaste. Solo quiero leer uno. Hay un comentario aquí. Usamos 10-sec query. Estoy súper feliz con ello. Y si no lo haces, solo lee la documentación y pruébalo. Así que gracias por tu trabajo. Pero luego está este más jugoso porque esencialmente esta persona, no quiero poner palabras en su boca pero esto es como RTFM, lee el manual tipo de comentario. O mi blog. O tu blog. Pero hay otra pregunta aquí y ahí está. ¿Por qué son tan abrumadores los documentos de 10-sec? Creo que para los juniors y novatos pueden ser muy abrumadores. Ahora, por supuesto, es un equilibrio difícil de lograr pero ¿tienes alguna idea sobre cómo lo estás haciendo y dónde está eso ahora mismo? Sí, ese es un buen punto. Probablemente debería haber incluido eso tal vez en la charla. Creo que los documentos probablemente necesitan una renovación.

La estructura de la documentación ha estado allí desde siempre donde básicamente tenemos como guías que creo que es una buena idea comenzar con guías y luego básicamente la definición de la API y lo que tienes y luego los ejemplos que tenemos. Pero creo que las guías podrían estar un poco más estructuradas y deberían llevarte de cero al final en un solo flujo. No quiero hacer publicidad pero tengo un curso donde hago exactamente eso. Así que sí, también puedes obtener eso si quieres. Creo que es bueno publicitar cosas que realmente ayudan a las personas. Si estás teniendo dificultades con la documentación, entonces tal vez sea una buena cosa para revisar.

Bueno, bien vamos a seguir el orden democrático y ver las preguntas más votadas. Entonces, ¿es TensorStack Query una buena opción para aplicaciones de enrutador de aplicaciones Next.js? Entonces creo que esto está implicando todas las acciones del servidor y lo que sea. Tengo una publicación en el blog sobre ese tema. Se llama You Might Not Need React Query. Y aún así, como dije si estás usando un marco maduro que tiene componentes del servidor y acciones integradas y esto es suficiente para tu caso de uso entonces no traería TensorQuery desde el principio solo porque así es como siempre lo hemos hecho. Solo evalúa la situación.

Todavía hay muchas situaciones donde no tienes una aplicación Greenfield y quieres moverte al enrutador de aplicaciones y ya lo tienes en su lugar, ¿verdad? Entonces es una buena manera de simplemente mantenerlo y migrar de manera incremental. Pero también probablemente hay algunos casos de uso altamente interactivos donde un refetch o una revalidación solo en una navegación de ruta no es suficiente. Así que querrías que las actualizaciones sucedan más frecuentemente con todas las actualizaciones automáticas que tenemos. O tal vez tienes una consulta infinita con desplazamiento infinito, lo cual creo que todavía es bastante difícil de lograr solo con componentes del servidor. Así que solo depende del caso de uso. Definitivamente intentamos traer una buena integración con componentes del servidor y también con Next.js en sí, donde puedes iniciar la obtención de datos en el servidor y luego transmitir la promesa al cliente donde el caché luego realmente lo recogerá. Intentamos hacer esto también más automáticamente. Esta es una fase un poco experimental en la que estamos ahora. Pero sí, creo que puedes usarlo. No creo que tengas que usarlo.

Sí, es realmente interesante. Así que en realidad te entrevisté en el escenario avanzado de React hace solo un par de meses y tú mencionaste esa API y me di cuenta de que nosotros no la estábamos usando en el trabajo, así que la puse después. Así que aprendes algo cuando vienes a estas cosas. Una cosa que noté es que tú como que intercambias en el título de la charla y ahora tú hablas, usas React query y 10 stack query los nombres, y creo que podría haber algo de confusión al respecto. Entonces, ¿qué está pasando con eso? Solía ser React query hasta la versión 3. Hay un paquete DMPM React query que todavía recibe muchas descargas. Así que para obtener la descarga para realmente combinar esos dos, hice eso con Chatchpg por cierto, para simplemente combinar los números de estadísticas. Y luego decidimos que en realidad teníamos un núcleo agnóstico, como el núcleo es solo en JavaScript y React es un adaptador separado encima de eso. Y la gente comenzó a hacer un adaptador de vista y un adaptador svelte por su cuenta, pero solo dependiendo de React query y luego obtendrías un marco diferente encima de eso. Así que decidimos hacer todo el cambio de marca con la versión 4 y estamos publicando cada paquete por separado. Hay un paquete de núcleo de 10 stack query que es solo TypeScript puro. Hay 10 stack solid query, hay 10 stack view query y luego también hay 10 stack React query, el paquete. Así que el nombre completo sería 10 stack React query pero no creo que nadie realmente diga eso. Así que solo sigo llamándolo React query.

Y si estamos hablando del concepto en sí, entonces probablemente sea 10 stack query. Si construyes aplicaciones, ¿eres como un maximalista de 10 stack? ¿Usas el 10 stack router, por ejemplo? ¿O es la biblioteca de consultas más tu interés principal? Así que el router es un proyecto realmente genial. En la última aplicación que hemos construido desde cero, también elegimos el router. También estoy manteniendo el router ahora, así que una divulgación completa. Sí, así que creo que algunos de los conceptos en el router son realmente únicos, como cómo los parámetros de búsqueda se tratan como un gestor de estado, cómo tienes la seguridad de tipos que fluye por todas partes, cómo tienes integración de suspense en todas las rutas. Podría ser una buena charla también. Sí, supongo que te veré en el panel de mantenedores de desarrolladores y luego te veré en el panel de no quemarse después. Oh sí, pensé que era el mismo panel, como tiene que ser el mismo. No, son dos diferentes... uno es para personas que ya han reconocido que tienen un problema y las personas que todavía están caminando en el problema. Bien, así que vamos de nuevo, en un orden democrático.

¿Existen patrones recomendados para combinar React Query con almacenamiento en caché HTTP para APIs REST usando, por ejemplo, encabezados de control de caché? Definitivamente puedes hacer eso y es un tipo diferente de capa de almacenamiento en caché. Tenemos como esta configuración de tiempo de obsolescencia que básicamente define cuándo los datos se vuelven obsoletos y se siente como que los encabezados de control de caché hacen algo similar pero una de las cosas buenas es que si estás usando encabezados de control de caché simplemente mantendría el tiempo de obsolescencia en cero porque incluso si una obtención se activa con demasiada frecuencia desde React Query aún sería capturada por el caché del navegador y sería entregada desde ese caché directamente. Así que en este punto puedes mantener los valores predeterminados y realmente no importa y en realidad es bueno usar el caché del navegador para eso también porque esas solicitudes de obtención también funcionarían mientras estás sin conexión. Así que una vez que tienes eso almacenado en el caché del navegador incluso si no lo tienes en nuestro caché en memoria esas solicitudes aún funcionarían. Así que sí, una combinación de esos es definitivamente algo que puedes hacer.