¿Pero Puede Tu Cliente GraphQL Hacer Esto? — Un Análisis Profundo de urql

¡Hola, amigos! Muchas gracias por invitarme. Así que hoy voy a hablar sobre Urql. En particular, voy a profundizar en algunos de los valores fundamentales y características destacadas.

Así que 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. He sido parcial a GraphQL incluso antes de comenzar a usar React Native, pero habiendo usado tanto REST como GraphQL en aplicaciones móviles, definitivamente puedo ver cómo muchos de los beneficios de GraphQL pueden ser particularmente útiles para móviles. Y realmente espero que algún día, GraphQL sea el estándar para aplicaciones nativas.

Entonces, ¿por qué estoy aquí hablando sobre Urql? Bueno, Urql es un cliente de GraphQL para React, React Native, y otros, y es un proyecto de código abierto construido por Formidable, y esa es una 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 GraphQL en primer lugar. En Formidable, tenemos varias iniciativas para alentar a las personas a contribuir al código abierto tanto dentro de formida sauce, como también a proyectos personales y comunitarios. Urql es uno de los muchos proyectos de código abierto a lo largo de los años, pero actualmente creo que es el más emocionante. Originalmente, fue creado por Ken, luego reescrito por Phil y ahora con contribuciones de la comunidad, así como de muchos de mis colegas formidables. Incluso yo mismo no hace mucho contribuí añadiendo un intercambio de autenticación para manejar la autenticación y el intercambio de tokens, pero más sobre eso más tarde. Con eso en mente, ¿deberías usar Urql? Bueno, hay varios otros clientes de GraphQL por ahí. Apollo Client y Relay en particular. En última instancia, la elección de qué cliente de GraphQL usar o no debería realmente depender de las características que necesitas 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 solo hablar un poco sobre la filosofía general y el proceso de pensamiento que ha ido en diseñarlas.

Muy bien, una de las cosas que realmente destaca en Urql comparado con otros es el compromiso con el soporte de primera clase para enlaces de frameworks. Así que, fuera de React, Urql tiene soporte incorporado de primera clase para Next.js, Preact, Svelte y Vue. Aunque no hay planes para añadir enlaces a Angular, así que si eso es lo tuyo, podrías tener que buscar en otro lado. Apollo Client y Relay no proporcionan ningún tipo de soporte de primera clase para ningún enlace de framework 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 usarlas para otros frameworks. Sin embargo, esto puede tener efectos perjudiciales en cadena. Por ejemplo, cuando la biblioteca implementa nuevas características, o cambios importantes y actualizaciones, todo esto lleva tiempo para propagarse a las bibliotecas de terceros. Si tienes soporte de primera clase, estos cambios están incorporados en 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 los documentos del artículo donde puedes encontrar una comparación de características bastante honesta entre Urql, Apollo Client y Relay. Sin embargo, para el resto de esta charla, me voy a centrar 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 de lenguaje llegan, 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 que pudiera adaptarse al cambiante panorama tecnológico. Así que para hacer que Urql sea lo más adaptable posible, está construido para ser lo más extensible posible.

La extensibilidad realmente está en el corazón de Urql, lo que nos lleva a los intercambios. Urql está construido sobre intercambios. 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 da la respuesta apropiada, ya sea un acierto 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 flujos. Así que un intercambio es solo un complemento que te permite inspeccionar y modificar tanto los flujos entrantes como salientes.

Déjame 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 intercambios. Estos vienen empaquetados en UrqlCore. Así que tenemos los intercambios dedupe, cache y fetch. Todos estos son completamente reemplazables, por cierto, así que puedes intercambiar cualquiera de estos por una implementación personalizada o alternativa.

Así que primero, el intercambio dedupe, elimina solicitudes duplicadas cuando la solicitud exacta ya está en curso. Así que imagina un sitio web con un encabezado y una barra lateral. Y ambos quieren mostrar el nombre del usuario. Ambos usarán una consulta con exactamente la misma consulta. Lo que hace el intercambio fetch, el intercambio dedupe, es asegurarse de que solo una instancia de esa consulta se pase al siguiente intercambio, y por lo tanto, eliminando la necesidad de una solicitud API duplicada.

Luego, el intercambio cache devuelve los datos del caché si hay alguno. Y finalmente, el intercambio fetch, que siempre estará en el último intercambio en la matriz, realiza la solicitud de red real y coloca el resultado de nuevo en el flujo de salida. Luego, el resultado se pasa desde el intercambio de solicitud de red al intercambio cache, donde se almacena para la próxima vez, y finalmente, se pasa de nuevo al resultado de la consulta.

Ahora, dado que literalmente puedes agregar una cantidad ilimitada de complementos, la única forma de garantizar que todos se lleven bien entre sí es asegurarse de que cada complemento permanezca sin opiniones. Veamos un ejemplo real de esto en Intercambios. Primero, tenemos el intercambio fetch del que ya hablamos. Este es el intercambio fetch predeterminado incluido en Urql Core. Obtiene los datos de la API y los agrega al flujo de salida. Ahora, un paquete complementario separado, puedes instalar un paquete complementario separado para consultas persistentes automáticas en un intercambio fetch persistente. Así que, este intercambio utiliza la misma lógica de fetch que el intercambio fetch real. Pero con consultas persistentes automáticas, básicamente la forma en que funciona es que permite el almacenamiento en caché del lado del servidor de los datos de GraphQL.

Así que, el servidor puede almacenar en caché la solicitud basada en un fragmento de toda la solicitud del lado del cliente. Y luego, en el cliente, podemos pedir al servidor una solicitud particular solo basada en el fragmento. Y si el servidor ya tenía una solicitud exactamente con ese fragmento, puede devolver la respuesta desde el caché, el caché del lado del servidor. De lo contrario, dirá, oh, no sé nada sobre esto. Por favor, dame más información en cuyo caso realmente podemos hacer la consulta.

Ahora, el persisted fetch exchange debe colocarse antes del fetch exchange real porque, en primer lugar, las mutaciones no se almacenan en caché y, por lo tanto, no pueden pasarse. Necesitan ser pasadas al fetch exchange para manejar. En segundo lugar, si el servidor no admite consultas persistentes automatizadas, en cuyo caso la solicitud, nuevamente, tendrá que ser pasada al fetch exchange. Un ejemplo diferente, si quisieras habilitar cargas de archivos, podrías, a través de datos de formulario multipart y solicitudes post, puedes usar el multipart fetch exchange. Este intercambio utiliza la misma lógica de fetch que el fetch exchange, pero es un reemplazo directo para el fetch exchange predeterminado. Funcionará exactamente como el fetch exchange, a menos que las variables que reciba para una mutación contengan algún archivo. Y por último, como habrás adivinado, también puedes combinar los dos intercambios en un persisted multipart fetch exchange que admitirá tanto consultas persistentes automatizadas como cargas de archivos.

En general, Urql apunta a un enfoque completo, lo que significa que es como una tienda única para todo lo que necesitas de tu cliente GraphQL. Afortunadamente, debido a la elección arquitectónica fundamental de confiar en intercambios con opiniones, cada nueva característica o mejora puede ser conectada y utilizada con el intercambio apropiado. Ahora, ya hemos echado un vistazo a los fetch exchanges, pero echemos un vistazo a un par más. Un intercambio útil es el retry exchange, que te permite reintentar automáticamente las solicitudes. Puedes configurar un retraso, que puede ser un valor fijo de segundos o un valor aleatorio, y el número máximo de reintentos. Y uno cercano a mi corazón es el auth exchange.

Así que, la autenticación en GraphQL ha sido mi molestia desde siempre. He tenido que implementarla varias veces y siempre ha sido doloroso. Hay, de hecho, una dificultad adicional con React Native en comparación con la web porque el almacenamiento de tokens es asincrónico, lo que necesita ser tenido en cuenta al obtener el estado inicial de autenticación. Así que, con el auth exchange, mi objetivo era hacerlo extensible para que pudiera ser utilizado tanto para React Native como para la web y para las diferentes implementaciones de autenticación. Así que, admite tanto React como React Native. Es decir, puedes obtener el token de forma asincrónica o sincrónica. Admite la actualización de tokens, y tanto como una mutación como un punto de obtención separado. Puedes configurar tu encabezado de autenticación, de cualquier manera que funcione la autenticación en tu aplicación. Así que, a veces tienes un token de portador o a veces solo un token o tal vez algunos encabezados adicionales. Y finalmente, podrás determinar qué constituye un error de autenticación en tu API y cerrar sesión o manejar eso según sea necesario. Así que, algunas APIs usan, todavía usan códigos de error HTTP para errores de autenticación y algunas APIs usan códigos de autenticación y esos pueden ser configurados de varias maneras. Así que, el auth exchange admite varias implementaciones en un lado del servidor.

Con respecto a DevTools. Ahora, no profundizaré mucho en DevTools, pero basta con decir que, Go tiene DevTools y sorpresa, sorpresa, puedes instalarlos como un exchange. Esto está disponible como una extensión de Chrome o Firefox o como una aplicación de Electron. Con los 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 exchanges que has configurado localmente.

Muy bien, es hora de hablar sobre el almacenamiento en caché. Por defecto, Urql utiliza el almacenamiento en caché de documentos. Evitará enviar la misma solicitud a la API de GraphQL repetidamente almacenando en caché el resultado de cada consulta. Esto básicamente funciona de la misma manera que lo hace un caché en el navegador. Entonces, 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é consultas, también necesitamos invalidar los resultados almacenados en caché que necesitamos. Entonces, con el almacenamiento en caché de documentos, asumimos que un resultado puede ser invalidado por una mutación que se ejecuta en datos que se han consultado previamente, la invalidación de caché se realiza solo a través de la propiedad de nombre de tipo. Entonces, cuando enviamos una mutación que contiene tipos que también contienen los resultados de otra consulta, ese resultado de consulta se elimina del caché.

Y esto nos lleva a la opción alternativa de almacenamiento en caché para Urql, el almacenamiento en caché normalizado. El caché de documentos es sencillo y efectivo, pero tiene algunas limitaciones. Entonces, antes de entrar en el almacenamiento en caché normalizado, echemos un vistazo a por qué era necesario y cuáles eran las limitaciones del caché de documentos. En primer lugar, a medida que tu aplicación crece, comienza a duplicar muchos datos. Considera, por ejemplo, una lista paginada con parámetros de filtro. Debido a que el caché se clavea por la consulta y los parámetros, terminarás almacenando los mismos elementos varias veces. Con el caché de documentos, porque solo usamos el nombre de tipo para datos e invalidación y no ningún tipo de ID, no hay forma de reconciliar automáticamente los datos. Y esto nos lleva al número tres, que es que si tu aplicación tiene alguna mutación, no podrás tener soporte sin conexión con el caché de documentos. La solución de almacenamiento en caché normalizado para urql se llama graph cache y está diseñada para resolver estos problemas difíciles. Recuerda toda la extensibilidad de antes, los exchanges siendo no opinados y reemplazables? Bueno, graph cache es un reemplazo directo para el caché de documentos predeterminado. No voy a hablar muy profundamente sobre graph cache, pero voy a mencionar las cuatro características principales, bueno, algunas características interesantes cuando se trata de graph cache. En primer lugar, obviamente tenemos actualizaciones optimistas, pero lo único sobre cómo graph cache hace actualizaciones optimistas es que nunca toca realmente los datos reales. Siempre crea una capa sobre tus datos existentes. Cuando la consulta tiene éxito, realmente ejecuta tu actualizador personalizado en los datos reales. Así que mientras tenemos la fuente de verdad del servidor, tus datos reales están sin modificar. Sé que otras soluciones de caché tienden a crear un registro simulado con un ID simulado y luego reemplazarlo más tarde, así que graph cache no hace nada de eso.

En segundo lugar, tenemos conciencia del esquema. Esto significa que obtenemos la consulta de introspección y así podemos hacer que el caché sea consciente de ella. Entonces, puedes ser advertido cuando estás haciendo algo mal, por ejemplo, si estás usando el tipo de condición incorrecto como consulta, fragmentos inválidos, consultando campos no consultables, cosas así. Y luego, dado que el caché es consciente de tu esquema, también puede servirte datos parciales. Así que un buen ejemplo de esto es, por ejemplo, un sitio de e-commerce. Entonces, en un sitio de e-commerce, tienes una lista de productos, y para mostrar esta lista, normalmente consultarías, solo la imagen, el nombre, tal vez el precio. Mientras que si vas a la página de detalles del producto de ese producto, tendrás todo tipo de detalles sobre tamaños, materiales, etcétera. Así que con datos parciales, cuando pasas de una lista de productos a una página de detalles del producto, podemos realmente devolver los datos que ya tenemos en el caché. Así que puedes comenzar, puedes mostrar el nombre de la imagen y el precio de inmediato sin esperar a que el producto regrese con todos los detalles.

Y finalmente, y esto es realmente importante, conmutatividad. Esta es la fuerza impulsora para poder hacer offline first, asegurando que las consultas se apliquen en un caché en el orden en que se ejecutan. Así que, por ejemplo, si haces tres consultas en orden, en realidad no hay garantía de que regresen del servidor en ese orden. Así que si la segunda consulta se devuelve primero, lo que hace Graphcache es que en realidad la aplica de la misma manera que una actualización optimista sobre tu caché. Luego finalmente, cuando la primera consulta regresa, se aplicarán en orden. Así que con Graphcache, podemos construir aplicaciones offline first, y eso es increíble.

Para mí personalmente, lo encuentro especialmente poderoso para aplicaciones móviles donde los usuarios esperan un nivel de funcionalidad incluso cuando no están conectados a Internet. Con conciencia del esquema, actualizaciones optimistas y conmutatividad, Graphcache está diseñado para manejar el soporte offline de manera efectiva.

Y finalmente, ¿qué hay del tamaño del bundle? Bueno, a menudo lo primero que surge cuando se habla de Urql es lo pequeño que es en comparación con las alternativas. Y bueno, sí, el tamaño del bundle es pequeño y hay números para ello. Pero en lugar de centrarse realmente en los números, podría ser importante centrarse en por qué se hizo un esfuerzo para reducir el tamaño del bundle. En última instancia, cuanto más pequeño es el tamaño del bundle, más cortos son los tiempos de análisis. Graphcache también tiene un bajo impacto de presión de memoria y es rápido en dispositivos más lentos. Queremos asegurarnos de que los usuarios en países y áreas alrededor del mundo con conexiones a Internet más lentas aún obtengan la mejor experiencia posible en la web. Esto lleva a una web rápida e inclusiva.

Eso es todo de mi parte. Realmente espero que hayas encontrado este conocimiento sobre Urql valioso. Si quieres saber más, te voy a dejar con dos recursos principales. Primero, obviamente, tenemos la documentación oficial. Es realmente completa. Podrás encontrar información adicional sobre todos los temas que cubrí aquí hoy. Pero más importante, tenemos la comunidad de Urql, que vive 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 hacen que mantener un ojo en ella sea una prioridad y todas las discusiones son respondidas y puedes preguntar prácticamente sobre cualquier cosa relacionada con Urql desde problemas de implementación, hasta una solicitud de función, o incluso pedir una elaboración sobre el e-source alrededor de la biblioteca en sí misma.

Muchas gracias. Hola. Hola, Caddy. Buen verte de nuevo. Oh, buen verte de nuevo. Me gusta el maquillaje.

Has ido con todo. Sí. Hoy, vamos por el color invertido. Ayer, era como un fondo negro y estrellas blancas. Hoy, es como, bueno, no sé. No soy coreano. Tengo una vibra completamente diferente. Así que, optamos por el esquema de color invertido. El delineador. Sí, gracias. Tienes que hacer algo con este trabajo de MC, ¿verdad?

Sí, entonces, Urkel, tu charla. Incluso tenemos una serie de preguntas de los espectadores. ¿Estás listo para responder algunas? Bien, hagámoslo. Muy bien. Pregunta uno de Alexander. Con soporte de primera mano para frameworks tan diversos, ¿cómo aseguras que tu soporte tenga la mejor integración posible? ¿Todos los frameworks para los que se proporciona integración son utilizados por Formidable? Entonces, no todos son utilizados por Formidable. Por ejemplo, la integración con Vue es bastante reciente y no tenemos ningún proyecto con Vue, hasta donde yo sé. Sé que todos los enlaces de framework tienen la aprobación del tipo de mantenedor. Así que, lo que intentamos hacer es, sé que cuando se crean los enlaces de framework, se pasan por los mantenedores de ese framework para que digan, sí, esto suena bien, o como, no, te has perdido algo.

Eso es interesante. Así que, llamas a la puerta de los mantenedores del proyecto y dices, tengo algo, por favor aprueba. Bueno, más o menos. Quiero decir, la gente está genuinamente bastante feliz de tener cosas que usan su framework 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 realmente se une y trabaja en lugar de la realidad del código abierto donde a menudo todavía eres tú haciendo todo el trabajo. Sí, sí, exactamente. Muy bien, pregunta número dos de Djapar Dejad. Solo por curiosidad, ¿el cliente Apollo tiene un concepto similar al intercambio DDoop de Urkel? Ahora, esa es una pregunta astuta, porque está yendo completamente fuera del tema y preguntando sobre tu cliente Apollo, pero veamos. Oh, creo que eso es, seré honesto y diré que no lo sé.

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. Oye, siempre es bueno decir que no sabes. Cuando no sabes, de lo contrario la gente se enoja mucho cuando solo inventas respuestas. Extraño. Sí, con eso. Es como, oh no, puedes usarlo en producción hoy, se escapa.

Bien, pregunta número tres de Juan. Cuando dices que elimina entradas duplicadas, ¿quieres decir que eliminaría campos duplicados en la misma consulta? Por ejemplo, ¿qué pasaría si la consulta 1 está pidiendo nombre y edad, y la consulta 2 está pidiendo nombre y nacionalidad de una persona? Nota que ambas solicitudes usaron la misma consulta de tipo persona. Entonces podemos devolver nombre, edad o nacionalidad. Esa es otra excelente pregunta, Phil o Jovi. Lo que asumiría es que está claveada por la consulta real, así que toda la cosa de la consulta tendría que ser la misma. Pero no estoy 100% seguro. Justo.

Así que lo que he hecho es escanear las preguntas que están por venir. Diré que un tema fuerte es, ¿qué pasa con Apollo? Así que a los miembros de la audiencia, como alguien que ha usado ambas plataformas, los documentos de Apollo para las preguntas de Apollo son probablemente súper clave. Pero repasemos estas y veamos qué podemos hacer. Pregunta número cuatro de Radha, muy a nivel alto. ¿Cómo se compara Urql con Apollo? Y supongo que se refieren al cliente frontend de Apollo en lugar de su oferta de servidor? Sí, así que comparar en términos de implementación o filosofía, supongo, es la pregunta. La pregunta no especifica, así que puedes elegir la que quieras.

Sí, así que son similares en que ambos son clientes de GraphQL. Sabes, en el espacio frontend, la intención original era usar con React. Son realmente bastante diferentes cuando se trata de las ideas alrededor de esto y bastante diferentes alrededor de la gestión de caché. Así que, Urql no fue realmente construido para ser como Apollo, pero mejor. Fue como volver a la mesa de dibujo alrededor de crear un cliente de GraphQL y como, ¿qué es lo que realmente necesitamos? Como desde los primeros principios, así que empezar desde cero. Y con el tiempo, por ejemplo, la API de hooks. Así que, notarás que la API para interactuar con los clientes de Apollo y Urql es bastante similar. Así que, todavía tienes el hook de consulta de uso porque eso es genial estos días. Sabes, todavía estás analizando en un GraphQL como una cadena porque, sabes, así es como consultas clientes de GraphQL.

Así que, hay similitudes solo porque ambas bibliotecas han llegado a una solución similar, pero son bastante diferentes en cuanto a las ideas detrás de ellas. Así que, una cosa que es realmente increíble sobre Urql, y creo en lo que a mí respecta, esa es como la razón número uno para considerar Urql es que la comunidad es extremadamente receptiva. Así que, si tienes un problema o una pregunta, como un problema de implementación o simplemente una pregunta como algunas de estas que no he querido responder todo lo que necesitas hacer es ir a las pestañas de discusión en Urql y a menos que tu comentario sea como un troll tienes prácticamente garantizado obtener respuestas. Así que, si echas un vistazo a las discusiones, sabes como ninguna de ellas queda sin respuesta, lo cual es realmente agradable porque básicamente sabes que si decides optar por Urql basado en las características que tiene, entonces sí, sabrás que tendrás apoyo. No te encontrarás en una posición donde digas, oh no hace lo que quiero. ¿Es siquiera posible? Hay alguien a quien preguntar. Mientras que, con los clientes de Apollo, solo porque hay tantos otros productos que Apollo gestiona como el cliente es solo una pequeña, como para ellos, oferta de código abierto y sabes, no siempre tiene, ya sabes, la prioridad número uno de soporte. Sí, definitivamente puedo relacionarme con eso. Hago mucho trabajo en Federation que es uno de los brazos más pequeños de sus ofertas de código abierto y sabes, definitivamente hay personas muy útiles pero a veces cuando estás como profundamente en algún plan de consulta apresurado me gusta, creo que esto probablemente está muy bajo en la enorme pila de productos para mantener así que aquí estoy tratando de resolverlo por mí mismo. Sí, exactamente y también como la comunidad. Sé que, bueno, estoy seguro de que muchos de ustedes saben así que Phil y Joey son las dos personas principales tanto en la construcción de mucho de Urql y todo Graphcache pero también gestionando la comunidad y su prioridad número uno es hacer que la comunidad sea amigable y útil y luego eso, sabes, todos solo quieren ayudarse mutuamente a construir cosas increíbles.

Bueno, una pregunta para mí ahora. Mencionaste que Urql es muy, muy pequeño. ¿Cómo logra esto? Porque obviamente quiero decir que 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 preguntar 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 las bibliotecas más pequeñas. Yo también tengo un pequeño libro negro. Acabo de notar pero solo dice, podemos, veamos si la cámara enfoca. No, absolutamente falló. Está bien, dice lista de enemigos en él. Tal vez si estamos justo al lado de mi cara. Ahí tienes. Solo quiere estar cerca de tu cara por alguna razón. Sí, exactamente, es como que la detección de rostros es muy importante pero en su lugar tiene una nota sobre off zero dentro.

Bien, vamos a llegar a algún lugar. Oh, iba a decir para una respuesta más seria a esa pregunta es en realidad, así que primero es asegurarse de que cada uno de los componentes de Urql sean como bibliotecas separadas. Así que está Urql core que es como el núcleo de la biblioteca que en cierto modo, ya sabes, hace lo de Urql, gestiona el flujo. Y la vigilancia muy estricta en lo que entra en esa biblioteca. Así que no tendrías simplemente 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í, así que luego todo lo demás está como en Exchanges. Así que Urql está construido para ser modular. Así que cualquier cosa que quieras, simplemente obtienes un exchange para ello. Así que el núcleo es lo mínimo absoluto que necesitas, por eso es tan pequeño. Y luego simplemente conectas y colocas, obtienes solo las partes que necesitas. Y porque todo está en su propia pequeña biblioteca y también minimizando dependencias, así que no instalarías LeftPad, no instalarías LowDash, así que son las dependencias más pequeñas posibles. Sí, eso es básicamente todo.

Sí, voy a elegir otra pregunta de la lista de preguntas, que es una elección sesgada y rápidamente te darás cuenta por qué. De Alexander, ¿algún plan para soportar Rescript como lenguaje de uso? No he oído hablar de esto. ¿Rescript? Rescript es como rebautizaron ReasonML. Oh. Ups. 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í, nada que ver aquí, amigos. Um, oh, así que el— Oh, aparentemente Reason es soportado. Y Rescript llegará pronto. Genial. Bueno, ahí lo tenemos. Um, genial.

Voy a combinar dos preguntas aquí. Espero que no te importe, Nikan y Bastiaan. ¿Hay alguna gran característica obvia— alguna gran característica obvia que Apollo tenga que Urkel no, y si estuvieras tratando de hacer un reemplazo directo, ¿podrías predecir algún cambio importante? Um, así que no puedes— así que la API es muy similar, pero no es idéntica. Así que no puedes simplemente, ya sabes, reemplazar UseQuery con UseQuery, como, de Urkel. Porque creo que si recuerdo correctamente, sé que Urkel devuelve un array desde UseQuery, mientras que Apollo devuelve un objeto. Así que tienes que cambiar la desestructuración. Así que hay una pequeña manera de hacerlo, así que hay un pequeño cambio en la API, sí, entre ellos. Fuera de eso, déjame pensar. Así que si no estás usando cache, así que si solo estás usando, como, solo haciendo algunas consultas, haciendo algunas mutaciones, no tenemos una implementación de cache personalizada o algo así, creo que simplemente funcionaría. Si tienes un cache personalizado, entonces obviamente la implementación de cache es ligeramente diferente. La forma en que interactúas con él es ligeramente diferente. Es un intercambio que insertas, y luego si tienes un cache, y si haces, por ejemplo, actualizaciones offline u optimistas, también necesitas escribir las consultas de actualización para esas. Así que esas podrían ser ligeramente diferentes. Así que básicamente, si tienes una implementación simple, que es solo algunas consultas y mutaciones, creo que funcionaría bastante bien fuera de solo cambiar la sintaxis ligeramente.

Genial. Y otra pregunta para mí, ¿cómo eligieron qué bibliotecas soportar? Teníamos cosas como Preact, por ejemplo, que es un marco de trabajo web basado en componentes menos común. ¿Cómo se armó esa lista? ¿Es solo cosas que Formidable ha querido usar en ese momento? ¿O hay más planificación involucrada?

Bueno, creo que, así que el soporte para Preact es, bueno, Preact es un reemplazo directo para React, lo que significa que el soporte para Preact es realmente muy fácil de lograr. Entonces, ¿por qué no tenerlo? También... Y es como, oh sí, también soportamos Preact, porque todos lo hacen técnicamente. Sí, exactamente. Pero también, 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 de marco de trabajo estén a la altura? Si alguna vez hay un experto en hallazgos de marco de trabajo de Preact, sería Jovi. Así que esa fue una bastante fácil.

El otro punto de vista, creo que en general, hay simplemente un marco de trabajo que nos interesa, como fuera de Preact. Y de eso se tratan esos robots. Angular, creo que no hay una gran cantidad de, como no muchos mantenedores de Oracle, pero no ha habido mucho interés en Angular. Sí, el diagrama de Venn donde las personas que quieren usar Oracle y el tipo de personas que usan Angular probablemente no están muy en, la intersección de eso probablemente sea bastante delgada.

Oh, en realidad tenía una respuesta a una pregunta anterior que olvidé mencionar, que era sobre, creo que no respondí la segunda parte de la pregunta, que era sobre qué tiene Oracle que Apollo no tiene. Y como una de las principales cosas era sobre Graphcache. Así que Graphcache está construido para ser desde cero para poder trabajar offline, lo cual es muy emocionante porque básicamente como con Apollo, su caché es una especie de gestión de estado. Mientras que con Oracle, el caché de Oracle es una especie de espejo del caché del servidor. Así que está destinado a ser tu caché de servidor local y todas las actualizaciones se aplican en el orden correcto. Y sí, así que básicamente la forma en que está construido desde cero es para poder soportar offline, lo cual me emociona 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 usando Graphcache, puedes prácticamente hacer que funcione offline, lo cual es increíble. Sí, no, eso parece realmente genial. Parece una forma muy inteligente de lidiar con un problema común. He visto tantas implementaciones hechas a mano de lo que siempre termina siendo más o menos consultas persistentes. Sí, sí. Quiero decir, he creado algunas implementaciones usando Apollo tratando de lograr offline primero, y creo que con Graphcache, es realmente la primera vez que siento que funciona y estoy bastante seguro de la solución. Sí, y tengo algunos planes para crear algunos tutoriales al respecto, así que creo que es algo muy emocionante para React Native. Mm-hmm.

Bien, maravilloso. Bueno, creo que hemos respondido todas las preguntas que tenemos, y creo que mi cámara también se está volviendo más embrujada 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 promocionar a la audiencia. Me encantaría que más personas le dieran una oportunidad a urql y simplemente nos dieran su opinión.

Como, sé que sigo diciendo la sección de la comunidad en el sitio de GitHub, pero ese es el lugar de referencia. Como, pruebas urql y dices, oh, no me gusta porque no hace esta cosa. Solo publica allí y luego podemos responder. Podemos decir tal vez, oh, sí, está planeado. O, no lo estamos haciendo por esto. Así que, realmente estamos interesados en que la gente lo pruebe y dé su opinión.

Bueno, ahí lo tienes. Ahí lo tienes. Dale una oportunidad a urql hoy. Muchas gracias, Cady.