¿Pero puede tu cliente GraphQL hacer esto? - Una inmersión profunda en urql

¡Hola, amigos! Muchas gracias por recibirme. Hoy voy a hablar sobre Urql. En particular, voy a profundizar en algunos de sus valores fundamentales y características destacadas. Pero primero, una breve introducción sobre mí. Mi nombre es Kaddy. Actualmente soy gerente de ingeniería en Mutable, donde paso la mayor parte de mi tiempo construyendo aplicaciones móviles, tanto en React Native como en GraphQL. Siempre he sido fan de GraphQL incluso antes de comenzar a usar React Native, pero después de haber utilizado tanto REST como GraphQL en aplicaciones móviles, puedo ver claramente cómo muchos de los beneficios de GraphQL pueden ser especialmente útiles para dispositivos móviles. Y realmente espero que algún día, GraphQL sea el estándar para las aplicaciones nativas.

Entonces, ¿por qué estoy aquí hablando de Urql? Bueno, Urql es un cliente de GraphQL para React, React Native, y otros, y es un proyecto de código abierto desarrollado por Formidable, que es la empresa para la que trabajo. Entonces, ¿qué es Urql? En Formidable, invertimos mucho en código abierto. Todos estamos parados sobre los hombros de gigantes aquí, y quiero decir, esta misma conferencia ni siquiera existiría si Facebook no hubiera decidido abrir el código de GraphQL en primer lugar. En Formidable, tenemos varias iniciativas para fomentar que las personas contribuyan al código abierto, tanto dentro de formida sauce como también en proyectos personales y de comunidad. Urql es uno de los muchos proyectos de código abierto que hemos desarrollado a lo largo de los años, pero actualmente creo que es el más emocionante. Originalmente, fue creado por Ken, luego fue reescrito por Phil y ahora cuenta con contribuciones de la comunidad y también de muchos de mis colegas de Formidable. Incluso yo mismo contribuí hace poco tiempo agregando un intercambio de autenticación para manejar la autenticación y el intercambio de tokens, pero más sobre eso más adelante. Con eso en mente, ¿deberías usar Urql? Bueno, hay varios otros clientes de GraphQL disponibles. Apollo Client y Relay en particular. En última instancia, la elección de qué cliente de GraphQL usar o no usar realmente debería depender de las características que necesites en tu proyecto. Para el resto de la charla, voy a repasar algunas de las características de Urql que creo que son especialmente geniales y hablar un poco sobre la filosofía general y el proceso de pensamiento que se ha utilizado para diseñarlas. Muy bien, una de las cosas que realmente se destaca en Urql en comparación con otros es el compromiso con el soporte de primera parte para enlaces de frameworks. Por lo tanto, fuera de React, Urql tiene soporte de primera parte incorporado para Next.js, Preact, Svelte y Vue. Aunque no hay planes de agregar enlaces a Angular, así que si eso es lo que te gusta, es posible que debas buscar en otro lugar. Apollo Client y Relay no brindan ningún tipo de soporte de primera parte para enlaces de frameworks fuera de React, y dependen completamente de bibliotecas de terceros. Esto está completamente bien. Esas bibliotecas fueron diseñadas para React, después de todo, y es la comunidad la que quería usar ellas para otros frameworks. Sin embargo, esto puede tener efectos negativos. Por ejemplo, cuando la biblioteca implementa nuevas características o cambios y actualizaciones que rompen, todo esto lleva tiempo para propagarse a las bibliotecas de terceros. Si tienes soporte de primera parte, estos cambios se incorporan a los enlaces desde el primer día. Si estás interesado en una comparación más detallada de estas bibliotecas, hay una sección completa en la documentación del artículo donde puedes encontrar una comparación de características bastante honesta entre Urql, Apollo Client y Relay. Sin embargo, durante el resto de esta charla, me voy a enfocar solo en Urql.

Si hay algo que sabemos cuando se trata de tecnología es que las cosas cambian rápido y todo el tiempo. Nuevas características del lenguaje aparecen, bibliotecas, convenciones, las cosas que son geniales cambian e incluso los requisitos comerciales surgen todo el tiempo. Al crear Urql, uno de los objetivos era asegurarse de que fuera lo más flexible posible, para poder adaptarse al cambiante panorama tecnológico. Por lo tanto, para hacer que Urql sea lo más adaptable posible, se construyó para ser lo más extensible posible. La extensibilidad es realmente el corazón de Urql, lo que nos lleva a los exchanges. Urql se basa en exchanges. Así que si piensas en lo que hace un cliente de GraphQL en su núcleo, toma una solicitud, una consulta o una mutación, y devuelve la respuesta adecuada, ya sea un resultado de caché, una respuesta de la API o un error. Como resultado, la mayoría de los clientes de GraphQL, incluido Urql, están construidos para ser basados en streams. Un exchange es simplemente un complemento que te permite inspeccionar y modificar tanto los streams de entrada como los de salida. Permíteme mostrarte esto con un ejemplo, porque eso lo hará mucho más claro. Cuando instalas Urql y ejecutas una consulta, por defecto Urql utiliza tres exchanges. Estos vienen incluidos en UrqlCore. Tenemos el exchange dedupe, el exchange cache y el exchange fetch. Todos estos son completamente reemplazables, por cierto, por lo que puedes intercambiar cualquiera de ellos por una implementación personalizada o alternativa. Primero, el exchange dedupe, elimina las solicitudes duplicadas cuando la solicitud exacta ya está en curso. Imagina un sitio web con un encabezado y una barra lateral. Ambos quieren mostrar el nombre del usuario. Ambos utilizarán una consulta con exactamente la misma consulta. Lo que hace el exchange dedupe es asegurarse de que solo se pase una instancia de esa consulta al siguiente exchange, y por lo tanto, eliminar la necesidad de una solicitud duplicada a la API. Luego, el exchange cache devuelve los datos de la caché si los hay. Y finalmente, el exchange fetch, que siempre estará en el último exchange del array, realiza la solicitud de red real y devuelve el resultado al flujo de salida. Luego, el resultado se pasa desde el exchange de solicitud de red al exchange de caché, donde se almacena para la próxima vez, y finalmente, se devuelve al resultado de la consulta. Ahora, dado que literalmente puedes agregar una cantidad ilimitada de complementos, la única forma de garantizar que todos funcionen bien entre sí es asegurarse de que cada complemento sea poco opinativo. Veamos un ejemplo real de esto en los Exchanges. Primero, tenemos el exchange fetch del que ya hemos hablado. Este es el exchange fetch predeterminado incluido en Urql Core. Obtiene los datos de la API y los agrega al flujo de salida. Ahora, como un paquete adicional separado, puedes instalar un paquete adicional para consultas persistentes automáticas en un exchange fetch persistente. Este exchange utiliza la misma lógica de fetch que el exchange fetch real. Pero con consultas persistentes automáticas, básicamente funciona de la siguiente manera:

En cuanto a DevTools. Ahora, no profundizaré mucho en DevTools, pero basta decir que Go tiene DevTools y, sorpresa, sorpresa, puedes instalarlos como un intercambio. Está disponible como una extensión de Chrome o Firefox o como una aplicación de Electron. Con DevTools, puedes inspeccionar las consultas, resultados, líneas de tiempo y también ejecutar solicitudes directamente desde DevTools, lo cual puede ser realmente útil porque utilizará todos los intercambios que hayas configurado localmente. Bien, es hora de hablar sobre la caché. Por defecto, Urql utiliza la caché de documentos. Evitará enviar la misma solicitud a la API de GraphQL repetidamente almacenando en caché el resultado de cada consulta. Esto funciona básicamente de la misma manera que una caché en el navegador. Por lo tanto, Urql crea una clave para cada solicitud que se establece en función de la consulta y sus variables. Una vez que llega un resultado, se almacena en caché indefinidamente por su clave. Esto significa que cada solicitud única puede tener exactamente un resultado almacenado en caché. Sin embargo, cuando almacenamos en caché las consultas, también necesitamos invalidar los resultados almacenados en caché que necesitamos. Por lo tanto, con la caché de documentos, asumimos que un resultado puede ser invalidado por una mutación que se ejecuta en data que se ha consultado anteriormente, la invalidación de la caché se realiza solo a través de la propiedad del nombre del tipo. Por lo tanto, cuando enviamos una mutación que contiene tipos que también contiene los resultados de otra consulta, ese resultado de la consulta se elimina de la caché.

Y esto nos lleva a la opción alternativa de caché para Urql, la caché normalizada. La caché de documentos es sencilla y efectiva, pero tiene algunas limitaciones. Por lo tanto, antes de entrar en la caché normalizada, veamos por qué fue necesaria y cuáles fueron las limitaciones de la caché de documentos. En primer lugar, a medida que tu aplicación crece, comienza a duplicar muchos data. Considera, por ejemplo, una lista paginada con parámetros de filtro. Debido a que la caché se basa en la consulta y los parámetros, terminarás almacenando los mismos elementos varias veces. Con la caché de documentos, debido a que solo usamos el nombre del tipo para data e invalidación y no algún tipo de ID, no hay forma de reconciliar automáticamente los data. Y esto nos lleva al número tres, que es que si tu aplicación tiene mutaciones, no podrás tener soporte sin conexión con la caché de documentos. La solución de caché normalizada para urql se llama caché de gráficos y está diseñada para resolver estos problemas difíciles. Recuerda toda la extensibilidad mencionada anteriormente, los intercambios que son no opinativos y reemplazables. Bueno, la caché de gráficos es un reemplazo directo de la caché de documentos predeterminada. No voy a hablar mucho en profundidad sobre la caché de gráficos, pero mencionaré las cuatro características principales, algunas características interesantes cuando se trata de la caché de gráficos. En primer lugar, obviamente tenemos actualizaciones optimistas, pero lo único único de cómo la caché de gráficos realiza actualizaciones optimistas es que nunca toca realmente los datos reales. Siempre crea una capa encima de tus datos existentes. Cuando la consulta tiene éxito, ejecuta tu actualizador personalizado en los datos reales. Por lo tanto, mientras tenemos la fuente de verdad del servidor, tus datos reales no se modifican. Sé que otras soluciones de caché tienden a crear un registro simulado con un simulacro

Y finalmente, ¿qué hay del tamaño del paquete? Bueno, a menudo lo primero que se menciona cuando se habla de Urql es lo pequeño que es en comparación con otras alternativas. Y bueno, sí, el tamaño del paquete es pequeño y hay números para respaldarlo. Pero en lugar de centrarse en los números, puede ser importante centrarse en por qué se hizo el esfuerzo de reducir el tamaño del paquete. En última instancia, cuanto más pequeño sea el tamaño del paquete, más cortos serán los tiempos de análisis. Graphcache también tiene un bajo impacto en la presión de memoria y es rápido en dispositivos más lentos. Queremos asegurarnos de que los usuarios en países y áreas de todo el mundo con una conexión a Internet más lenta obtengan la mejor experiencia posible en la web. Esto conduce a una web rápida e inclusiva. Eso es todo de mi parte. Realmente espero que hayas encontrado esta información valiosa sobre Urql. Si quieres saber más, te voy a dejar con dos recursos principales. En primer lugar, obviamente, tenemos la documentación oficial. Es muy completa. Podrás encontrar información adicional sobre todos los temas que cubrí aquí hoy. Pero lo más importante, tenemos la comunidad de Urql, que se encuentra en la pestaña de discusión en GitHub. Honestamente, diría que este es uno de los grandes puntos de venta de Urql. Los mantenedores principales se aseguran de estar al tanto y todas las discusiones son respondidas, y puedes preguntar prácticamente cualquier cosa sobre Urql, desde problemas de implementación hasta solicitudes de funciones, o incluso pedir una explicación sobre el origen de la biblioteca en sí misma. Muchas gracias. Hola. Hola, Caddy. Qué bueno verte de nuevo. Oh, qué bueno verte de nuevo. Me gusta el maquillaje.

Te has esforzado al máximo. Sí. Hoy, vamos a utilizar el esquema de colores invertido. Ayer, era como un fondo negro y estrellas blancas. Hoy, es como, bueno, no lo sé. No soy coreano. Tengo una vibra completamente diferente. Así que, optamos por el esquema de colores invertido. El delineador de ojos. Sí, gracias. Tienes que hacer algo con este trabajo de MC, ¿verdad?

Sí, entonces, Urkel, tu charla. Incluso tenemos varias preguntas de los espectadores. ¿Estás listo para responder algunas? De acuerdo, vamos a hacerlo. Muy bien. Pregunta uno de Alexander. Con soporte de primera parte para marcos de trabajo tan diversos, ¿cómo te aseguras de que tu soporte tenga la mejor integración posible? ¿Se utilizan todos los marcos de trabajo para los que se proporciona integración por parte de Formidable? No todos ellos son utilizados por Formidable. Por ejemplo, la integración con Vue es bastante reciente y no tenemos ningún proyecto de Vue, que yo sepa. Sé que todas las vinculaciones de marcos de trabajo han obtenido la aprobación del mantenedor. Entonces, lo que intentamos hacer es, sé que cuando se crean las vinculaciones de marcos de trabajo, se someten a los mantenedores de ese marco de trabajo para que digan, sí, esto suena bien, o no, te has olvidado de algo.

Eso es interesante. Entonces, tocas a la puerta de los mantenedores del proyecto y les dices, tengo algo, por favor apruébalo. Bueno, más o menos. Quiero decir, la gente está realmente contenta de tener cosas que utilizan su marco de trabajo y que ellos mismos no tienen que mantener. Así que, en realidad, es una oferta bastante popular. Sí, el sueño del código abierto, ¿verdad? Donde la gente se une y trabaja en lugar de la realidad del código abierto, donde a menudo sigues siendo tú quien hace todo el trabajo. Sí, sí, exactamente. Muy bien, pregunta número dos de Djapar Dejad. Solo por curiosidad, ¿tiene el cliente Apollo un concepto similar al intercambio DDoop de Urkel? Ahora, eso es astuto, porque se sale completamente de la especificación de la charla y pregunta sobre tu cliente Apollo, pero veamos. Oh, creo que sí, seré honesto y diré que no lo sé. Creo que para cualquier pregunta que no te guste que no sepa, te sugiero que vayas al repositorio de Urkel en GitHub, a la pestaña de discusión y preguntes allí.

Y Phil y Jovi, que son los mantenedores principales, te responderán en, ya sabes, un par de horas como máximo. Así que esa, no lo sé, me temo. No te preocupes. Hey, siempre es bueno decir que no sabes. Cuando no sabes, la gente se enfada mucho cuando inventas respuestas. Extraño. Sí, con eso. Es como, oh no, puedes usarlo en producción hoy, huye.

De acuerdo, pregunta número tres de Juan. Cuando dices que elimina entradas duplicadas, ¿te refieres a que eliminaría campos duplicados en la misma consulta? Por ejemplo, ¿qué sucedería si la consulta 1 solicita nombre y edad, y la consulta 2 solicita nombre y nacionalidad de una persona? Ten en cuenta que ambas solicitudes usaron la misma consulta de tipo persona. Luego podemos devolver nombre, edad o nacionalidad. Esa es otra excelente pregunta, Phil o Jovi. Lo que supongo es que se realiza por la consulta real, por lo que todo el proceso de consulta tendría que ser el mismo. Pero no estoy 100% seguro. Bastante justo.

Así que lo que he hecho es revisar las preguntas que están surgiendo. Diré que un tema recurrente es, ¿qué pasa con Apollo? Por lo tanto, para los miembros de la audiencia, como alguien que ha utilizado ambas plataformas, la documentación de Apollo para las preguntas de Apollo es probablemente muy importante. Pero repasemos esto y veamos qué podemos hacer. Pregunta número cuatro de Radha, muy general. ¿Cómo se compara Urql con Apollo? Y supongo que se refieren al cliente Apollo frontend en lugar de su oferta de servidor. Sí, en términos de implementación o filosofía, supongo que es la pregunta. La pregunta no especifica, así que puedes elegir la que prefieras.

Sí, son similares en el sentido de que ambos son clientes de GraphQL. En el espacio de frontend, la intención original era utilizarlo con React. Sin embargo, son bastante diferentes en cuanto a las ideas que los rodean y la gestión de caché. Así que, Urql no fue construido para ser como Apollo, pero mejor. Fue volver a empezar desde cero en la creación de un cliente de GraphQL y preguntarnos qué necesitamos realmente. Desde los principios básicos, así que empezamos desde cero. Y con el tiempo, por ejemplo, la API de hooks. Por lo tanto, notarás que la API para interactuar con los clientes de Apollo y Urql es bastante similar. Aún tienes el hook de uso de consulta porque eso es genial en estos días. Aún estás analizando un GraphQL como una cadena porque, ya sabes, así es como se consulta a los clientes de GraphQL.

Entonces, hay similitudes simplemente porque ambas bibliotecas han llegado a una solución similar, pero son bastante diferentes en cuanto a las ideas detrás de ellas. Entonces, una cosa realmente increíble en Urql, y creo que, en lo que a mí respecta, esa es la razón número uno para investigar Urql es que la comunidad es extremadamente receptiva. Entonces, si tienes un problema o una pregunta, como un problema de implementación o simplemente una pregunta como algunas de estas a las que he sido reacio a responder todo lo que tienes que hacer es ir a las pestañas de discusión en Urql y a menos que tu comentario sea como un troll prácticamente garantizado que obtendrás respuestas. Entonces, si miras las discusiones, ya sabes que ninguna de ellas queda sin respuesta, lo cual es realmente agradable porque básicamente sabes que si decides usar Urql basado en las características que tiene, entonces sí, sabrás que recibirás soporte. No te encontrarás en una situación en la que digas, oh, no hace lo que quiero. ¿Es siquiera posible? Siempre habrá alguien a quien preguntar. En cambio, con los clientes de Apollo simplemente porque hay tantos otros productos que Apollo gestiona como el cliente es solo una pequeña parte, para ellos, de su oferta de código abierto y, ya sabes, no siempre tiene la máxima prioridad de soporte. Sí, definitivamente puedo entender eso. Hago mucho trabajo en Federation que es una de las ramas más pequeñas de sus ofertas de código abierto y, ya sabes, definitivamente son personas muy serviciales pero a veces cuando estás inmerso en algún plan de consulta apresurado creo que esto probablemente está muy abajo en la enorme pila de productos para mantener así que aquí estoy tratando de resolverlo por mí mismo. Sí, exactamente y también la comunidad. Conozco a Phil y Joey, y estoy seguro de que muchos de ustedes también los conocen son las dos personas principales tanto en la construcción de Urql como en Graphcache pero también en la gestión de la comunidad y su máxima prioridad es hacer que la comunidad sea amigable y servicial y eso, ya sabes, todos solo quieren ayudarse mutuamente a construir cosas increíbles.

Ok, ahora una pregunta para mí. Mencionaste que Urql es muy, muy pequeño. ¿Cómo logra esto? Porque obviamente, quiero decir, cada paquete, cada biblioteca desearía ser pequeña. ¿Qué hace, cuáles son, qué estás, cuál es el método secreto que estás aplicando para asegurarte de que Urql siga siendo diminuto? Um, creo que eso es algo para preguntarle a Phil. Sí, es magia oscura. Es, es como, así que Phil tiene este pequeño libro negro como sabes, la gente tiene libros negros de números de teléfono y cosas así. Él tiene libros negros de consejos sobre cómo hacer que las bibliotecas sean más pequeñas. Yo también tengo un pequeño libro negro. Me acabo de dar cuenta, pero solo dice, podemos, veamos si la cámara enfoca. No, definitivamente falló. Está bien, dice lista de enemigos. Tal vez si estamos justo al lado de mi cara. Ahí está. Solo quiere estar cerca de tu cara por alguna razón. Sí, exactamente, es como si la detección de rostros fuera muy importante pero en su lugar tiene una nota sobre off zero adentro.

Ok, vayamos a algún lugar. Oh, iba a decir una respuesta más seria a esa pregunta en realidad, en primer lugar, se asegura de que cada uno de los componentes de Urkle sean bibliotecas separadas. Entonces está Urkle core que es como el núcleo de la biblioteca que hace la cosa de Urkle, que gestiona el flujo. Y la vigilancia extrema en lo que se incluye en esa biblioteca. Entonces no tendrías basura que no usarías. Y luego todo lo demás está en Exchanges. ¿Perdón? No tienes LeftPad ahí. No, definitivamente no LeftPad. Sí, entonces todo lo demás está en Exchanges. Entonces Urkle está construido para ser modular. Entonces cualquier cosa que quieras, solo obtienes un exchange para eso. Entonces el núcleo es lo mínimo absoluto que necesitas, por eso es tan pequeño. Y luego lo conectas en su lugar, solo importas las partes que necesitas. Y porque todo está en su propia pequeña biblioteca y también minimizando las dependencias, por lo que no instalarías LeftPad, no instalarías LowDash, por lo que son las dependencias más pequeñas posibles. Sí, eso es prácticamente todo.

Sí, voy a elegir otra pregunta de la lista de preguntas, que es una elección parcial y rápidamente te darás cuenta por qué. Desde Alexander, ¿hay planes para admitir Rescript como lenguaje de uso? No he oído hablar de esto. ¿Rescript? Rescript es como han renombrado a ReasonML. Oh. Oops. Uh, yo... No, está bien. Está bien. Lo siento. Mi casa está pasando por un túnel. Y estamos de vuelta. No te preocupes. Sí, aquí no hay nada que ver, gente. Um, oh, entonces... Oh, al parecer Reason es compatible. Y Rescript llegará pronto. Genial. Ahí lo tienes. Um, genial.

Voy a combinar dos preguntas aquí. Espero que no les importe, Nikan y Bastiaan. ¿Hay alguna característica obvia importante que Apollo tiene y que Urkel no tiene, y si estuvieras intentando hacer un reemplazo directo, ¿podrías prever algún cambio que rompa la compatibilidad? Um, entonces no puedes— la API es muy similar, pero no es idéntica. No puedes simplemente, ya sabes, reemplazar UseQuery con UseQuery, de Urkel. Porque creo que si recuerdo correctamente, Urkel devuelve un array desde UseQuery, mientras que Apollo devuelve un objeto. Así que tienes que cambiar la destructuración. Hay una pequeña forma de hacerlo, hay un pequeño cambio en la API, sí, entre ellos. Fuera de eso, déjame pensar. Si no estás utilizando caché, si solo estás haciendo algunas consultas, algunas mutaciones, no tenemos una implementación de caché personalizada ni nada parecido, creo que funcionaría sin problemas. Si tienes una caché personalizada, entonces obviamente la implementación de la caché es ligeramente diferente. La forma en que interactúas con ella es ligeramente diferente. Es un intercambio que agregas, y luego si tienes una caché, y si haces, por ejemplo, actualizaciones sin conexión u optimistas, también necesitas escribir las consultas de actualización para eso. Así que esas podrían ser ligeramente diferentes. Básicamente, si tienes una implementación simple, que son solo algunas consultas y mutaciones, creo que funcionaría prácticamente sin problemas fuera de cambiar ligeramente la sintaxis.

Genial. Y otra pregunta para mí, ¿cómo eligieron qué bibliotecas apoyar? Teníamos cosas como Preact, por ejemplo, que es un marco web basado en componentes menos utilizado. ¿Cómo se hizo esa lista? ¿Es solo lo que Formidable quería usar en ese momento? ¿O hay más planificación involucrada?

Bueno, creo que, por lo tanto, el soporte de Preact es, bueno, Preact es un reemplazo directo de React, lo que significa que el soporte de Preact es muy fácil de lograr. Entonces, ¿por qué no tenerlo? Además... Y es como, oh sí, también apoyamos Preact, porque técnicamente todos lo hacen. Sí, exactamente. Pero además, Jovi es un mantenedor principal de Preact. Así que también hay experiencia interna para responder a la otra pregunta, ¿cómo nos aseguramos de que nuestros hallazgos del marco sean de calidad? Si alguna vez hay un experto en los hallazgos del marco Preact, sería Jovi. Así que eso fue bastante fácil.

El otro punto de vista, creo que en general, hay simplemente un marco en el que estamos interesados, como fuera de Preact. Y de eso se trata todo eso de los robots. Angular, creo que no hay una gran cantidad de, como no muchos mantenedores de Orcle, pero no ha habido mucho interés en Angular. Sí, el diagrama de Venn donde las personas que quieren usar Oracle y las personas que usan Angular probablemente no se superponen mucho.

Oh, en realidad tenía una respuesta a una pregunta anterior que olvidé mencionar, que se trataba de, creo que no respondí la segunda parte de la pregunta, que se trataba de qué tiene Orcle que Apollo no tiene. Y una de las cosas principales era Graphcache. Entonces, Graphcache está diseñado para poder funcionar sin conexión, lo cual es muy emocionante porque básicamente, con Apollo, su caché es como una especie de gestión de estado. Mientras que con Orcle, la caché de Orcle es como un espejo de la caché del servidor. Por lo tanto, se supone que es tu caché del servidor local y todas las actualizaciones se aplican en el orden correcto. Y sí, básicamente la forma en que está construido desde cero es para poder admitir sin conexión, lo cual me entusiasma mucho para React Native porque creo que definitivamente sería un cambio de juego, lo que significa que si tienes una aplicación con actualizaciones optimistas y usas Graphcache, prácticamente puedes hacer que funcione sin conexión, lo cual es increíble. Sí, no, eso se ve realmente genial. Parece una forma muy inteligente de lidiar con un problema común. He visto tantas implementaciones personalizadas de lo que siempre termina siendo consultas más o menos persistentes. Sí, sí. Quiero decir, he creado algunas implementaciones usando Apollo tratando de lograr el enfoque sin conexión primero, y creo que con Graphcache, es la primera vez que siento que funciona y tengo cierta confianza en la solución. Sí, y tengo planes de crear algunos tutoriales al respecto, así que creo que es algo muy emocionante para React Native. Mm-hmm. De acuerdo, maravilloso. Bueno, creo que hemos respondido todas las preguntas que teníamos, y creo que mi cámara también se está volviendo más espeluznante con el tiempo, así que tal vez deberíamos terminar por ahora y jugar con eso. ¿Hay algo más que te gustaría decir, promocionar? Esta es tu oportunidad de dirigirte a la audiencia. Me encantaría que más personas prueben urql y nos den su opinión.

Como saben, siempre menciono la sección de la community en el sitio de GitHub, pero ese es el lugar al que acudir. Prueba urql y piensa, oh, no me gusta porque no hace esta cosa. Solo publica allí y luego podemos responder. Tal vez podamos decir, oh, sí, está planificado. O, no lo estamos haciendo debido a esto. Así que realmente esperamos que la gente lo pruebe y nos dé su opinión.

Bueno, ahí lo tienen. Ahí lo tienen. Dale una oportunidad a urql hoy mismo. Muchas gracias, Cady. Deja tus emojis de aplausos en Discord para nuestra maravillosa presentadora.