Panel Discussion: GraphQL Client-Side Libraries

Haré una rápida ronda de presentaciones para todos ustedes antes de que nos sumerjamos en la discusión y comencemos a tomar preguntas. Así que, hoy tenemos aquí con nosotros a Joe. Joe es un ingeniero de software en MetaFacebook, trabajando en la organización de React en React, Relay. También tenemos a Phil. Phil es un ingeniero en Graph CDN, anteriormente en Formidable, trabajando en el equipo central de Urql. Puede que hayas oído hablar de ello. Gran herramienta. Urql es un cliente de GraphQL que se inició allí. Y componentes también. También tenemos a Dominique con nosotros. Dominique es un ingeniero de frontend de Viena, Austria. Trabaja como líder técnico de frontend en AdWordy y mantiene la biblioteca React Query. Y por último, pero no menos importante, Ellen. Tenemos a Ellen aquí con nosotros, quien es una defensora de desarrolladores móviles en Apollo GraphQL, enfocándose en SDKs de iOS y Android. Ella vive en Madison, Wisconsin y disfruta de todo lo relacionado con el aire libre, así como de tallar cosas raras con láseres. Vaya, eso es súper genial. Diría que es súper fascinante. Impresionante. Definitivamente también es un pasatiempo de pandemia. Absolutamente. Estaba a punto de decir eso.

Voy a hacer una rápida ronda de presentaciones para todos ustedes antes de que nos sumerjamos en la discusión y comencemos a tomar preguntas. Así que, hoy tenemos aquí con nosotros a Joe. Joe es un software ingeniero en MetaFacebook, trabajando en la org de React en React, Relay. También tenemos a Phil. Phil es un ingeniero en Graph CDN, anteriormente en Formidable trabajando en el equipo central de Urql. Puede que hayas oído hablar de ello. Gran herramienta. Urql es un cliente de GraphQL que se inició allí. Y componentes también. También tenemos a Dominique con nosotros. Dominique es un ingeniero frontend de Viena, Austria. Trabaja como líder técnico frontend en Edwardity y mantiene la biblioteca React Query. Y por último, pero no menos importante, Ellen. Tenemos a Ellen aquí con nosotros, quien es una defensora de desarrolladores móviles en Apollo GraphQL, enfocándose en SDKs de iOS y Android. Ella vive en Madison, Wisconsin y disfruta de todas las cosas al aire libre, así como de tallar cosas raras con láseres. Vaya, eso es súper genial. Diría que es súper fascinante. Impresionante. Definitivamente también es un pasatiempo de pandemia. Absolutamente. Estaba a punto de decir eso. Y como solo hablar de cosas raras que nos ayudan a desestresarnos. También tengo un montón de cosas así. Solo, ya sabes, una gran parte de mi expresión y cómo puedo expresarme como una persona creativa. Así que definitivamente es súper interesante.

Muy bien. Así que creo que es bueno comenzar con una pregunta simple, como una pregunta básica sobre qué problemas o casos de uso creen que GraphQL o los clientes de GraphQL han sido más efectivos en abordar? Y cómo han mejorado el estado del arte para el desarrollo de aplicaciones. Y nos encantaría escuchar sus pensamientos. Y esta podría ser solo esa una pregunta que podría establecer el primer paso para la discusión completa. Y podemos simplemente continuar desde allí.

Está bien. Así que creo que es bueno comenzar con una pregunta simple, como una pregunta básica sobre qué problemas o casos de uso ustedes piensan que GraphQL o los clientes de GraphQL han sido más efectivos en abordar? Y cómo han mejorado el estado del arte para el desarrollo de aplicaciones. Y nos encantaría escuchar sus pensamientos. Y esta podría ser solo esa una pregunta que podría establecer el primer paso para la discusión completa. Y podemos simplemente partir de ahí. ¿Qué tal si comenzamos contigo, Joe? Sí, claro. Esa es una gran pregunta. Sí, supongo que la mayoría de los clientes de GraphQL han comenzado a ayudar. Realmente ayudó a escalar las aplicaciones. Eso probablemente sea lo más importante. Sabes, todos estamos familiarizados con el enfoque REST, ¿verdad? De tener estos tipos de endpoints personalizados, endpoints versionados, y simplemente no realmente se alinean con aplicaciones ricas que tienen muchos componentes reutilizables, ya sean aplicaciones web o aplicaciones móviles. Sabes, tienes estos componentes de UI reutilizables. Esto se ha convertido en un estándar en la industria, gracias a React en gran parte. Pero ahora que ese tipo de desarrollo basado en componentes se ha convertido en un estándar, realmente hemos comenzado a ver la forma en que REST simplemente no escaló. Y así GraphQL, fundamentalmente, creo que ha ayudado a abordar eso. También creo que ha ayudado a formalizar la forma en que pensamos sobre la gestión de datos en aplicaciones del lado del cliente. Así que muchas de las preocupaciones que las personas tal vez tenían que enfrentar pero no tenían un nombre, los clientes de GraphQL nos han ayudado a entender cuáles son esas preocupaciones. Así que la consistencia de datos es algo muy fundamental, pero realmente no pensábamos en ello tanto hasta que llegó GraphQL.

¿Qué tal si comenzamos contigo, Joe? Sí, claro. Esa es una gran pregunta. Sí, supongo que la mayoría de los clientes de GraphQL han comenzado a ayudar. Realmente ayudó a escalar aplicaciones. Eso probablemente sea lo más importante. Sabes, todos estamos familiarizados con el enfoque de REST, ¿verdad? De tener estos tipos de endpoints personalizados, endpoints versionados, y simplemente no realmente se alinean con aplicaciones ricas que tienen muchos componentes reutilizables, ya sean aplicaciones web o aplicaciones móviles. Sabes, tienes estos componentes de UI reutilizables. Esto se ha convertido en un estándar en la industria, gracias a React en gran parte. Pero ahora que ese tipo de desarrollo basado en componentes se ha convertido en estándar, realmente hemos comenzado a ver la forma en que REST simplemente no escaló.

Y así GraphQL, fundamentalmente, creo que ha ayudado a abordar eso. Creo que también ha ayudado a formalizar la forma en que pensamos sobre la gestión de datos en aplicaciones del lado del cliente. Así que muchas de las preocupaciones que las personas tal vez tenían que enfrentar pero no tenían un nombre, los clientes de GraphQL nos han ayudado a entender cuáles son esas preocupaciones. Así que la consistencia de datos es algo muy fundamental, pero realmente no pensamos en ello tanto hasta que llegó GraphQL. Y así los clientes de GraphQL han ayudado con esos tipos de cosas como una carrera, como carreras de datos, incluso. Las personas pensaron en ellas antes, pero creo que ahora pensamos en ellas de manera más formal. Eso es realmente interesante, definitivamente hay muchas cosas con las que realmente estoy de acuerdo contigo, definitivamente hay muchas cosas que no notamos, que queríamos optimizar o mejorar en nuestro desarrollo de aplicaciones hasta que llegó GraphQL.

Y luego, como todos estos clientes de GraphQL a medida que han evolucionado, han estado abordando estos tipos de puntos de dolor para muchos de nuestros desarrolladores. Así que es una combinación de GraphQL evolucionando, pero también como todos estos grandes, grandes clientes de frontend, como los clientes de GraphQL que realmente han estado ayudando con eso. ¿Qué piensas, Dominic? Sí, creo que GraphQL en sí tuvo un gran impacto en cómo pensamos sobre la gestión de datos en general que estamos obteniendo del servidor. Así que GraphQL creo que le dio mucho poder al frontend y al backend y mucho control cuando puedes, lo que no podías hacer con REST, simplemente especificar los campos que deseas consultar y obtenerlo al nivel adecuado de granularidad. De granularidad que deseabas para tu específico. Y esa fue la primera vez que escuché sobre GraphQL donde pensé, sí, esto es realmente genial. Pero lo que realmente no me di cuenta al principio fue que en realidad todos esos clientes gráficos vienen con una caché separada para gestionar esos datos.

Eso es realmente interesante, definitivamente hay muchas cosas con las que realmente estoy de acuerdo contigo, definitivamente hay muchas cosas que no notamos, que queríamos optimizar o mejorar en nuestro desarrollo de aplicaciones hasta que llegó GraphQL. Y luego, como todos estos clientes de GraphQL a medida que han evolucionado, han estado abordando estos tipos de puntos de dolor para muchos de nuestros desarrolladores. Así que es una combinación de la evolución de GraphQL, pero también de todos estos grandes, grandes clientes de front-end, como los clientes de GraphQL que realmente han estado ayudando con eso. ¿Qué piensas, Dominic? Sí, creo que GraphQL en sí mismo tuvo un gran impacto en cómo pensamos sobre la gestión de datos en general que estamos obteniendo del servidor.

Así que GraphQL creo que le dio mucho poder al front y al back y mucho control cuando puedes, lo que no podías hacer con REST, simplemente especificar los campos que deseas consultar y obtenerlo al nivel correcto de granularidad.

De granularidad que deseabas para tu específico. Y esa fue la primera vez que escuché sobre GraphQL donde pensé, sí, esto es realmente genial. Pero lo que realmente no me di cuenta al principio fue que en realidad todos esos clientes gráficos vienen con una caché separada para gestionar esos datos. Porque cuando escuché sobre esto por primera vez, realmente pensé, está bien, esto es genial. Puedo obtener algunos datos, pero luego aún necesitaría algún medio para distribuir estos datos a lo largo de mi aplicación. No sé qué tiene que ver uno con el otro, pero las cachés que vienen con esto son también el verdadero poder de los clientes de GraphQL y las bibliotecas de front-end. Y eso también ha sido inspirado, obviamente, por React query para ir en esa dirección, para proporcionar una biblioteca que gestiona este estado de servicio, este agente del estado, no solo para GraphQL, sino también para REST al final. Gracias.

Absolutamente. También me encantaría escuchar tus pensamientos, Phil, sobre esto.

Es difícil agregar mucha más información a esto de lo que Joe ya ha hecho. Quiero decir, Oracle como cliente ha llegado tan tarde a todo este juego actual. Realmente ha sido tan temprano. Para GraphQL en su conjunto, mapeando este flujo de datos unidireccional que ya tenemos en las aplicaciones, en aplicaciones componentizadas específicamente, ha beneficiado a todos tanto y nos ha permitido jugar mucho más con lo que los clientes pueden hacer automáticamente y qué tipo de experiencias podemos crear en las aplicaciones sin ir a grandes longitudes como individuos que solo quieren construir una aplicación. Y creo que recientemente, especialmente con la especificación, trabajando en muchos más cambios, personalmente estoy muy emocionado por la RFC de nulabilidad que nos permite controlar qué tipo de datos fluyen hacia nuestras aplicaciones como anulables o requeridos. Esto va a impulsar aún más esto. Absolutamente, suena bien. Ellen, ¿tienes algún otro pensamiento que te gustaría agregar a esto? Sí, tengo.

Creo que para mí, lo más grande que trabajar con GraphQL realmente ha abierto para mí es la comunicación entre el front end y el back end. Y no me refiero a datos reales que van y vienen, me refiero a personas hablando entre sí.

Una de las cosas con las que constantemente me encontré en un trabajo anterior que estaba usando un cliente REST era que algo estaría en un endpoint REST, y estaríamos usando un endpoint REST diferente para una pantalla diferente.

Porque cuando escuché sobre esto por primera vez, realmente pensé, está bien, esto es genial. Puedo obtener algunos datos, pero luego aún necesitaría algún medio para distribuir estos datos a lo largo de mi aplicación. No sé qué tiene que ver uno con el otro, pero las cachés que vienen con esto son también el verdadero poder de los clientes de GraphQL y las bibliotecas de front end. Y eso también ha inspirado, obviamente, React query a ir en esa dirección, para proporcionar una biblioteca que gestione este estado de servicio, este agente del estado, no solo para GraphQL, sino también para REST al final. Gracias.

Absolutamente. También me encantaría escuchar tus pensamientos, Phil, sobre esto. Es difícil agregar mucha más información a esto de la que Joe ya ha dado. Quiero decir, Oracle como cliente ha llegado tan tarde a todo este juego actual. Realmente ha sido tan temprano. Para GraphQL en su totalidad, de alguna manera mapeando este flujo de datos unidireccional que ya tenemos en las aplicaciones, en aplicaciones componentizadas específicamente, ha beneficiado tanto a todos y nos ha permitido jugar mucho más con lo que los clientes pueden hacer automáticamente y qué tipo de experiencias podemos crear en las aplicaciones sin ir a grandes longitudes como individuos que solo quieren construir una aplicación. Y creo que recientemente, especialmente con la especificación, trabajando en muchos más cambios, personalmente estoy muy emocionado por el RFC de nulabilidad que nos permite controlar qué tipo de datos fluyen hacia nuestras aplicaciones como anulables o requeridos. Esto va a impulsar aún más esto.

Así que tendríamos que ir y decir, hey, chicos, ¿pueden agregar este campo a este otro endpoint? Y tomaría un mes porque tendríamos que ser priorizados, y luego haríamos la cosa, y luego el sitio se caería y pasaría algo más sucedería. Y solo poder decir, aquí hay un contrato que te dice qué valores están disponibles para ti, y también qué tipo son es realmente, realmente, realmente crítico. Y realmente es algo donde pasé de siempre que tenía una API REST, particularmente una que no controlaba, siempre escribiría dos conjuntos de pruebas, uno que golpeaba datos simulados, y uno que golpeaba el servidor de staging en vivo, porque podría decir mucho más rápido si cometí un error o si alguien cambió algo en el servidor. Y con GraphQL, siempre que las personas realmente estén adhiriéndose al esquema, eso se vuelve innecesario. Si estás evolucionando adecuadamente el esquema, si realmente te aseguras de que no estás eliminando cosas sin deprecarlas adecuadamente primero, si realmente te aseguras de que estás evolucionando las cosas, la necesidad de eso desaparece por completo. Y es enorme para móvil, solo porque una de las cosas más grandes con las que nos encontramos con los endpoints REST es que simplemente las personas cambian algo, y una versión anterior de la aplicación simplemente se rompe por completo. Y la forma en que se supone que GraphQL debe funcionar es que las cosas continúan siendo soportadas mientras estén realmente en uso. Y eso previene un nivel de ruptura que es tan común en otras aplicaciones que creo que es simplemente absolutamente crítico para móvil. No, estoy totalmente de acuerdo. Y me encanta cómo mencionaste o, como, destacaste la forma en que GraphQL resalta los beneficios del lado humano de las cosas, como la comunicación entre equipos, ¿verdad?

Porque es algo tan subestimado, ¿verdad? Como, GraphQL está empoderando a los desarrolladores reales y no solo en términos de, como, las características que podemos enviar ahora o, como, los beneficios tácticos de esto, sino también, como, el lado humano de esto y cuánto nos ha empoderado para, como, comunicarnos mejor con nuestros compañeros de equipo. Sí, así que definitivamente estoy de acuerdo con eso. Y simplemente me encanta ese punto. Luego también, algunos de los puntos que ustedes han mencionado, eso también me lleva a esta pregunta de seguimiento sobre, como, en nuestro desarrollo de aplicaciones, como dijo Joe, que había tantas cosas que realmente no notamos que estaban yendo mal hasta que llegó GraphQL. ¿Crees que, debido a ese aspecto, crees que tener clientes que tengan soporte de GraphQL integrado sería, como, solo una experiencia elaborada para GraphQL en el lado del cliente sería realmente útil, o es, en el lado alternativo, es mejor tener, como, clientes que no son específicos de GraphQL, diría, sino como una utilidad para ello? ¿Cuáles son tus pensamientos sobre eso? Podemos comenzar contigo, Ellen. Sí, quiero decir, creo que vengo del lugar de apoyar dos SDKs que están en lenguajes muy fuertemente tipados, y creo que, sabes, lo que definitivamente hemos encontrado es que, al menos en Swift y Kotlin, sé que hay otras experiencias móviles que a veces tienen un enfoque diferente, pero sé que en Swift y Kotlin, una de las grandes cosas que hemos encontrado es poder compilar todo a una consulta segura por tipo, ha sido enorme para muchas personas en términos de poder asociar ciertas cosas con vistas diseñadas individualmente y cosas así, pero también solo en términos de poder procesar datos que están obteniendo de GraphQL, e incluso si necesita ser, en algún momento, transformado en un modelo de vista o algo así, sigue siendo mucho, mucho más fácil al menos tener una idea de dónde estás comenzando para muchas de estas cosas.

Y creo que no es algo donde... Sé que en... En la web, hay muchas cosas donde es como, las cosas de relay están muy, muy ligadas a los principios de UI de relay, y eso no es tanto el caso en móvil. Sé que alguien estaba diciendo, creo que fue Joe, estaba diciendo que hay algunas cosas que se manejan un poco diferente en Meta, pero creo que en el mundo más amplio de iOS y Android, creo que es algo donde la gente está tratando realmente duro de integrar esto con SwiftUI y Jetpack Compose, que son marcos más reactivos que están inspirados en React.

Pero es algo donde no hay tanto un vínculo tan estrecho como creo que hay, entre GraphQL y React, y particularmente GraphQL y relay. Eso suena genial. Phil, ¿tienes algún pensamiento sobre esto? Depende, supongo. Hay un grado de cuánto dependemos de GraphQL dependiendo de qué cliente de GraphQL aquí estamos hablando. Creo que es particularmente interesante, y en realidad estoy esperando a ver lo que Dominik tiene que decir sobre esto, sobre diferenciar entre GraphQL como un patrón de UI y como un principio orientador de cómo construimos nuestras aplicaciones y un cliente como una biblioteca de obtención. Y creo que hay un equilibrio interesante que puede ir en cualquier dirección, dependiendo del caso de uso y dependiendo de los usuarios. Y ahora decidimos no agregar ningún shim, por así decirlo, para ejecutar GraphQL en el lado del cliente y en su lugar depender únicamente de APIs.

Absolutamente, suena bien. Ellen, ¿tienes algún otro pensamiento que te gustaría agregar a esto? Sí, tengo. Creo que para mí, lo más grande que trabajar con GraphQL realmente ha abierto para mí es la comunicación entre el front end y el back end. Y no me refiero a datos reales que van y vienen, me refiero a personas hablando entre sí. Una de las cosas con las que constantemente me encontré en un trabajo anterior que estaba usando un cliente REST era que algo estaría en un endpoint REST, y estaríamos usando un endpoint REST diferente para una pantalla diferente. Así que tendríamos que ir y decir, hey, chicos, ¿pueden agregar este campo a este otro endpoint?

Y tomaría un mes porque tendríamos que priorizarlo, y luego haríamos la cosa, y luego el sitio se caería y sucedería algo más pasaría. Y solo poder decir, aquí hay un contrato que te dice qué valores están disponibles para ti, y también qué tipo son es realmente, realmente, realmente crítico. Y realmente es algo donde pasé de siempre que tenía una API REST, particularmente una que no controlaba, siempre escribiría dos conjuntos de pruebas, uno que golpeaba datos simulados, y uno que golpeaba el servidor de staging en vivo, porque podría decir mucho más rápido si cometí un error o si alguien cambió algo en el servidor.

Y con GraphQL, siempre que las personas realmente estén cumpliendo con el esquema, eso se vuelve innecesario. Si estás evolucionando adecuadamente el esquema, si realmente te aseguras de que no estás eliminando cosas sin deprecarlas adecuadamente primero, si realmente te aseguras de que estás evolucionando las cosas, la necesidad de eso desaparece por completo. Y es enorme para móvil, solo porque una de las cosas más grandes con las que nos encontramos con los endpoints REST es que simplemente las personas cambian algo, y una versión anterior de la app simplemente se rompe por completo.

Y creo que los mismos beneficios se aplican a por qué es un poco diferente hablar sobre un cliente de GraphQL y hablar sobre la obtención en general, porque depende de cómo estás construyendo tu aplicación y si te lanzas por completo, por así decirlo, o no. Sí. Sí, eso tiene mucho sentido. Y estoy de acuerdo. También me gustaría, me encantaría escuchar lo que Dominik tiene que decir sobre esto. Me encantaría escuchar de ti, Dominik.

Así que ni siquiera diría que ReactQuery es una biblioteca de obtención, pero incluso iría un paso más allá y diría que ReactQuery es solo un administrador de estado de Azure. Y esto siempre confunde a algunas personas cuando digo que ReactQuery no está atado a la obtención de datos en absoluto. Realmente no le importa cómo produces los resultados. De hecho, solo necesita una promesa resuelta o rechazada. Y cómo construyes eso depende completamente de ti. Y creo que este es un enfoque completamente diferente al que tienen otras bibliotecas. Así que no está atado a GraphQL en absoluto. No está atado a REST en absoluto. Y esto te da un poco de flexibilidad cuando tienes que trabajar con múltiples backends donde a veces tienes GraphQL, a veces tienes REST diferentes endpoints que tienes que alcanzar. Incluso he visto algunos usuarios leer datos de la API de Ethereum o algo relacionado con Web3 para obtener datos a través de ReactQuery. Así que solo para gestionar los estados que tienes que son asíncronos. Pero, por supuesto, ReactQuery se utiliza más prominentemente con la obtención de datos. Y sí, no está atado a GraphQL así que eso es un compromiso que estás deshaciendo.

Creo que son todos compromisos. La caché que tiene ReactQuery es una caché de documentos muy minimalista y no tienes todas las capacidades que podrías tener con una caché de GraphQL muy específica. Pero también tienes otros beneficios como poder usar múltiples fuentes o tener un contenedor de caché muy predecible y confiable que también te dará el poder que necesitas para hacer la reobtención que deseas en los momentos que lo deseas. Absolutamente. Y creo que solo para reiterar lo que algunos de ustedes han dicho sobre como atar a tus clientes a GraphQL o no. Creo que depende totalmente de si estás completamente invertido en construir tu aplicación utilizando GraphQL en su totalidad o muchas empresas, muchos productos lo están, tienen como código C y no migran completamente a GraphQL de inmediato. Tienen que pasar por como construir capas progresivas sobre esas REST APIs existentes. Y creo que tiene sentido tener algún tipo de un marco impulsado por utilidades como un cliente que podría estar bien adaptado si deseas trabajar con GraphQL podría estar bien adaptado si deseas trabajar con REST APIs pero que tampoco está completamente atado a los patrones guiados por GraphQL en sí. Así que eso tiene mucho sentido. Joe, ¿tienes algún otro pensamiento sobre esto? Sí, sí, creo que hay una especie de, hemos tocado dos piezas. Uno es el grado en que tu cliente está acoplado a GraphQL. Y luego eso de lo que Ellen habló un poco fue cuánto estás acoplado a la biblioteca de UI dada, ¿verdad? Y así para el primer tipo de acoplamiento a GraphQL.

Y todas esas cosas son realmente fundamentales para construir un cliente muy poderoso para obtener consistencia de datos. Así que lo que tendemos a ver son básicamente clientes que son como, como dijiste, Dominic, con React Query, donde realmente se centra en la caché de documentos. Pero incluso entonces, no sabes lo suficiente sobre lo que hay en ese documento para hacer cosas como invalidar automáticamente basándote en cambios porque no puedes hacer el enfoque de Oracle de solo usar nombres de tipo, que es un enfoque que probablemente va a invalidar en exceso bastante, pero al menos te da invalidación automática. Y así hay un verdadero compromiso. Y así creo que, supongo que mi tipo de esperanza para el ecosistema es que trabajemos para facilitar la construcción de servidores GraphQL para que las personas puedan entonces aprovechar las capacidades del cliente de GraphQL, en lugar de decir, bueno, simplemente vayamos al denominador común más bajo y construyamos clientes que solo puedan hacer lo que podríamos hacer con REST porque solo queremos facilitar la adopción. Y así creo que los clientes hacen diferentes compromisos a lo largo de ahí. Hay, supongo, toda otra pregunta de integrar en la capa de vista, que es, eso es como casi una pregunta separada.

Absolutamente, no, eso tiene mucho sentido. Y solo, es bueno aprender sobre qué tipo de compromisos habría si, como dependiendo de tu enfoque, eso también plantea una pregunta que realmente quería escuchar todos sus pensamientos al respecto, pero Ellen ya respondió parcialmente eso pero aún me gustaría profundizar más en ello y escuchar de todos ustedes sobre, ya saben, como una de las innovaciones de GraphQL es introducir un esquema fuertemente tipado que expone información rica sobre las capacidades del servidor, pero luego creo que la mayoría de los clientes no o como no eligen, o no pueden usar mucha de esta información del esquema por defecto. Entonces, ¿cuánto crees que para tu escenario o para el espacio en el que estás trabajando, cuánto crees que esto sigue siendo cierto? ¿Y cuáles son tus pensamientos al respecto? Ellen, me encantaría comenzar contigo sobre esta pregunta, en realidad. Sí, creo que eso básicamente no es cierto en móvil. Creo que particularmente porque, de nuevo, como dije, una de las cosas que puedes hacer cuando tienes tanto el esquema que describe lo que es posible y luego la consulta que vas a hacer que dice, está bien, ¿qué es lo que realmente estoy pidiendo? Puedes hacer mucha validación sobre eso y luego también puedes generar código seguro en tipos que es realmente útil. Y sé que hay algunas cosas como sé que GraphQL code gen es enorme en este espacio, en TypeScript en particular, pero otro método que he visto en iOS, que es básicamente no cómo lo estamos haciendo, en Apollo, pero es algo más que he visto es esencialmente poder usar el esquema para crear consultas seguras en tipos cuando estás creando esas consultas en tiempo de ejecución. Así que hay muchas cosas que puedes hacer que realmente pueden aprovechar eso. Y creo que, honestamente, creo que eso es una gran parte de la propuesta de valor para móvil solo porque hay tantas cosas que tenemos que hacer para tomar cosas de JSON y convertirlas en algo que sea utilizable en un lenguaje seguro en tipos. Y tener ese nivel de validación incluso en tiempo de compilación, es súper, súper útil. Eso definitivamente suena útil y realmente conveniente pero en realidad comencé contigo solo para ver ese tipo de contraste entre el caso en el desarrollo móvil y luego cómo es para la web. Entonces, Joe, ¿tienes algún comentario sobre esto desde tu lado? Ha sido realmente interesante ver cómo esto se ha desarrollado en el ecosistema. Quiero decir, definitivamente para móvil donde estamos trabajando con lenguajes muy fuertemente tipados creo que todos están, básicamente tu mano está forzada, ¿verdad? Vas a usar esta información del esquema aunque cómo la usamos allí sigue siendo interesante. Pero en la web, creo que el ecosistema en la web tiende a enfocarse en la facilidad de comenzar y la simplicidad, ¿verdad? Ves mucho de, hay una especie de naturaleza cíclica donde tienes una biblioteca que aparece, resuelve más y más problemas. Inevitablemente, eso significa que tiene más características, más como, ya sabes, es un poco, lo miras y dices, Oh, eso me da mucho, como, no necesito todo eso. Y luego, así que, ya sabes, las aplicaciones comienzan. Y así, otras bibliotecas aparecen y dicen como, Oh, somos más fáciles de usar. Luego obtienen más adopción, añaden más características. Y luego algunos, como, ahora han caído en el mismo patrón.

en el mismo patrón. Y luego, así que, y solo ves esto como sucediendo sin fin en el ecosistema de JavaScript. Círculo de la vida. Sí, es honestamente como desarrollador de bibliotecas, es bastante frustrante de ver. Porque es como, ustedes solo van a encontrarse con este problema a continuación, y luego este problema a continuación y este problema a continuación.

Y así, y lo que eso significa, sin embargo, es que, bueno, obviamente una de las formas más fáciles de comenzar es simplemente no usar el esquema. Y lo que eso significa es que estás ofreciendo una experiencia mucho peor al desarrollador. Al aprovechar el esquema, puedes implementar correctamente la especificación gráfica.

No puedes implementar correctamente la especificación gráfica si no conoces el esquema, si no conoces los tipos de objetos, si no sabes qué tipos implementan qué interfaces. Y así vemos esto donde hay múltiples clientes en la web donde si no haces un trabajo extra, en realidad no obtendrás un comportamiento correcto. Y te estarás preguntando, espera, ¿por qué es esto, y básicamente cada cliente que no sea Relay, por defecto, obtendrás un comportamiento incorrecto en ciertas partes de la especificación porque no utilizan la información completa del esquema por defecto. Y así creo que es solo una forma realmente interesante en que ha ido el ecosistema. Definitivamente hay compromisos, ¿verdad? Hace que sea más fácil comenzar. Y así creo que eso no es para criticar, que estamos haciendo diferentes compromisos, pero es solo muy interesante cómo el esquema proporciona información tan rica y, sin embargo, no todos aprovechamos eso en la web. Y creo que eso es solo un verdadero compromiso de, no es tan fácil construir algunas de estas características en JavaScript como nos gustaría. Creo que en las plataformas nativas, simplemente tenemos, la gente está acostumbrada a, ya sabes, un paso de construcción. Así que eso es como, claro, por supuesto que vas a tener un paso de construcción, así que tengamos más extra, ya sabes, añadamos más allí para dar aún más valor al desarrollador, mientras que en la web, es como, oh, otro paso de construcción. Y así hay como más de un, como, está bien, bueno, tal vez no tengamos un paso de construcción y hagamos algunos compromisos para obtener esa facilidad de uso y luego encajar en el ecosistema de JS. No, eso definitivamente tiene mucho sentido. Como, es como entender el valor que GraphQL trae y luego querer usarlo, pero luego también no poder de alguna manera como aprovechar todo el poder que podrías con tus aplicaciones, como construirlo con GraphQL. Así que Phil, ¿qué piensas sobre esto?

Definitivamente hay compromisos, sí. Pero creo que hasta cierto punto, no siempre como la biblioteca ofrece nuestro compromiso a hacer, al menos no en la opinión que tenemos en términos de Urql donde proporcionamos dos cachés por defecto diferentes. Cuando solo lo instalas, tienes una caché de documentos que es muy primitiva y puedes cambiar a una caché normalizada, en cuyo punto realmente recomendamos a la gente usar algo que llamamos conciencia del esquema, que es literalmente solo usar datos de esquema introspectivo para un comportamiento correcto. Pero la razón por la que digo que no es nuestra decisión hacer en la web es porque hay tantas diferentes formas de usar la web, por así decirlo, para crear aplicaciones y páginas web. Y esa es la distinción que creo que vale la pena resaltar.

A veces, cuando un desarrollador está creando una página muy basada en contenido. Por ejemplo, algún tipo de página de noticias, digamos, los datos son muy estáticos y no son altamente interactivos. Y por lo tanto, pueden no estar interesados en algunas de las características dinámicas que obtienen de la caché normalizada. Y hay diferentes compromisos que quieren hacer. Y es más un caso de datos y de molestar al configurar la caché normalizada y por lo tanto no lo hacen. Así que forzarlos a pasar por ese flujo de configuración es un poco un compromiso extraño que tendrían que hacer porque en realidad no están interesados en eso. Pero para nosotros, lo que significa es que si alguien está realmente construyendo una aplicación, si alguien opta por la caché normalizada, somos mucho más agresivos al advertir a las personas si se encuentran con problemas. Y creo que eso es lo único en este momento que podemos hacer, aparte de tal vez recomendar un generador de código gráfico, que en realidad está más del lado de integrar con tipos, integrando tus consultas con tu lenguaje y tu aplicación más estrechamente y evitando errores. Pero creo que al menos desde nuestro lado, hay un poco de matiz en esa discusión sobre cuándo el usuario está listo para actualizar, por así decirlo, cuándo un usuario está listo para asumir esa complejidad adicional. Y creo que hemos llegado a un acuerdo con dejar que el usuario decida cuándo llega ese momento.

Eso es definitivamente una perspectiva muy interesante, como más centrada en el usuario, supongo. Y sigue siendo como, como dije antes, sigue siendo como si estuvieras usando GraphQL, pero entonces es más un viaje que solo un paso. Así que es más progresivo y saber para qué estás listo y con qué te sientes cómodo, y luego llegar allí lentamente al potencial completo. Así que eso tiene mucho sentido. Dominic, ¿tienes algún comentario que agregar a esto?

Sí, bueno, no mucho. Así que estoy de acuerdo con Joe. También he visto la lucha de la vida donde la gente quiere bibliotecas más pequeñas con más características. Y luego agregas más características y la biblioteca es demasiado grande. Y luego alguien dice, usemos la más pequeña y luego comienza todo de nuevo. Y al mismo tiempo, construcciones más rápidas, pero más cosas sucediendo en los pasos de construcción que obtenemos más corrección y más seguridad. Y sí, también son compromisos de nuevo, por supuesto, porque React Query es una biblioteca muy no opinativa cuando se trata de cómo produces esa promesa. También no podemos aprovechar tanto de la información que podrías tener. Un código GraphQL, de nuevo, como se mencionó, es una muy buena manera de encontrar el término medio entre ello. También puedes crear tus hooks de consulta de uso desde React Query con eso para obtener al menos algo de seguridad de vuelta. Y sí, la caché normalizada también es un tema que siempre surge mucho. Es algo que la gente está preguntando, ¿por qué React Query no tiene una caché normalizada? Y la respuesta es, sí, es múltiple. Así que en un caso, es un problema muy difícil de resolver, creo. Y es especialmente muy difícil de resolver si no tienes GraphQL. Así que si no estás en ese tipo específico, entonces se volverá aún más difícil. Así que no hemos realmente, sí, solo para decir que no hay una gran empresa detrás de React Query, no hemos realmente pensado mucho en esto. Pero también una de las cosas que la gente quiere con más frecuencia, incluso si no quieren una caché normalizada, es esta revalidación automática que también obtienes del esquema. Y esto es algo en lo que hemos estado pensando en también agregar solo para dar esta experiencia a los desarrolladores y también a los usuarios.

Eso suena genial, Dominik. Esa es una gran perspectiva. Así que me encanta eso. Eso también me lleva a esta pregunta sobre la seguridad de tipos. Y hay como dos lados diferentes a esto. El primero es como GraphQL introduce un esquema fuertemente tipado, así que solo tiene sentido usar un lenguaje fuertemente tipado para desbloquear el potencial completo del superpoder de GraphQL. Pero también quiero escuchar de ti, Dominik, sobre tu lado de, ya que dijiste que React Query es un cliente muy no opinativo, así que me encantaría escuchar sobre solo desde la perspectiva de un cliente, no un cliente específico de GraphQL, ¿tiene sentido o cuáles son los beneficios y desventajas de construir un cliente usando un lenguaje fuertemente tipado versus uno débilmente tipado versus un lenguaje no tipado? Y luego podemos ver el contraste con los clientes específicos de GraphQL.

que podrían haberle pasado al ecosistema de JavaScript, y React Query inicialmente también fue escrito en JavaScript y solo proporcionó los tipos, pero luego muy rápido en la versión dos, lo reescribimos en TypeScript. Y para nosotros como los autores de la biblioteca, creo que simplemente trae una facilidad de mantenimiento y seguridad de tipos que tenemos dentro si la biblioteca también está escrita en TypeScript. Y luego también se proyecta eso en los consumidores porque obtienen los tipos que tenemos que usar. Por supuesto, hay una curva involucrada en ello. Quiero decir, esto es también donde escuchaste sobre personas que comienzan con TypeScript que preferirían hacerlo en JavaScript. Pero creo que da resultados muy rápido si simplemente sigues ese camino.

No lo haría de ninguna otra manera. Suena increíble. Exactamente lo que esperaba. Así que es realmente bueno escuchar eso. Joe, ¿tienes algún pensamiento de tu lado sobre este tema acerca de, ¿qué piensas sobre emparejar GraphQL con un lenguaje fuertemente tipado o como en comparación con un lenguaje débilmente tipado o no tipado y los beneficios potenciales o las desventajas de eso? Sí, quiero decir, creo que, estábamos usando relay hace mucho tiempo antes de Flow, supongo que alrededor del mismo tiempo en que Flow estaba comenzando internamente, ¿verdad? Donde gran parte del código que consumía consultas de relay no estaba escrito en un lenguaje tipado y proporcionó mucho valor desde entonces. Así que creo que un cliente de GraphQL te brinda muchas capacidades, ¿verdad? Como la capacidad de fusionar todas tus dependencias de datos en una sola solicitud, ¿verdad? La consistencia de los datos, todas las cosas que, muchas de las cosas de las que hemos hablado en realidad no son específicas de los lenguajes de tipo. Son solo estas capacidades fundamentales que GraphQL te brinda. Obviamente, porque tienes el esquema, también puedes producir tipos fuertes. Y sí, soy un gran fan de la tipificación fuerte. Así que, ciertamente, como, creo que es incluso mejor, vas a obtener una aplicación mejor, más confiable en general. Creo que si construyes con un lenguaje fuertemente tipado, definitivamente es complicado construir el cliente en sí en un lenguaje fuertemente tipado, porque en última instancia, si estás trabajando con una caché normalizada, tienes que tener una gran cantidad de datos mezclados. Y así, básicamente tienes este esquema fuertemente tipado donde el fragmento, digamos, dice que necesita leer el campo nombre y se supone que debe ser una cadena. Pero lo que tienes en la tienda es, incluso si tu representación, incluso si estás usando un lenguaje fuertemente tipado donde tienes un enum o unión adecuada expresando el hecho de que los datos del campo podrían ser una cadena o un bool o lo que sea, aún en algún momento tienes que decir, está bien, voy a esperar que sea una cadena ahora. Voy a esperar que este valor de campo sea una cadena y esto es como la cosa fundamental donde en última instancia, cuando pasas de una base de datos, que es lo que la caché normalizada es hasta una aplicación, tienes este...

mientras construyes un cliente como este. Suena bien y creo que eso también podría haber sido como una discusión más profunda pero tal vez podríamos guardarlo para una masterclass especial. Así que nos encantaría escuchar más pensamientos al respecto. Pero Phil, ¿tienes algún otro pensamiento sobre esto? Quiero decir, al final de los usuarios, es impensable hoy en día, creo, al menos en la web no usar TypeScript con GraphQL debido a la seguridad que te brinda. Supongo que volviendo a, creo que lo que Dominic más reflejó sobre construir clientes o clientes de GraphQL con un lenguaje tipado y en este caso, ni siquiera el lenguaje fuertemente tipado. Creo que cuando estás construyendo algo como una caché y a lo que Joe se refiere, es que sin estas garantías de tipo, descubrir todos los errores habría sido imposible para nosotros. De hecho, teníamos tantos requisitos para nosotros mismos en términos de cómo debería funcionar un código o específicamente caché de Graph o caché normalizada que muchas partes que teníamos inicialmente estaban incluso escritas en rescript, anteriormente Reason. Supongo que esa es la forma aprobada por Facebook slash Meta irónicamente. Pero con el tiempo esto se desvaneció porque los reemplazamos con partes reescritas en TypeScript. Dicho esto, sí, quiero decir, para nosotros y para los usuarios, los beneficios de usar TypeScript sobre nada en absoluto son bastante claros. Y quiero decir, las desventajas han desaparecido con el tiempo.

Así que creo que no hay nada realmente que agregar a eso. Interesante. Sí, definitivamente. Ellen, ¿cuál es tu perspectiva sobre esto? Sí, quiero decir, así que solo admitiré que personalmente, estoy muy sesgada a favor de los lenguajes fuertemente tipados. Como son básicamente lo que he usado durante toda mi carrera de programación. Pero creo que una de las cosas que puede ser una desventaja es que si estás trabajando con un lenguaje fuertemente tipado, tienes que encajar algo que está construido para un lenguaje que no es fuertemente tipado en lo que sea que sea tu paradigma de lenguaje fuertemente tipado. Un lugar donde encontramos problemas con esto con el cliente de iOS en Apollo es que tenía esta gran idea de intentar convertir básicamente fragmentos en protocolos para Swift. Y una historia extremadamente larga resumida es que Swift no soporta del todo la forma en que quería que funcionara porque realmente no tiene soporte completo para covarianza. Y fue interesante, nuestro cliente de Android y Kotlin pudo como ejecutar esa idea porque Kotlin sí tiene soporte para covarianza y contravarianza, es bastante completo. Y pudieron realmente avanzar significativamente más en eso de lo que yo terminé desechando como un año de trabajo. Así que es algo donde tomar algo que está construido para un lenguaje de tipo débil y tratar de ponerlo en un lenguaje de tipo fuerte a veces tiene sus desventajas. Pero estoy muy de acuerdo con todos aquí como aprovechar esta información que obtienes gratis del esquema es tan, tan, tan útil para escribir una aplicación correcta que es algo que recomiendo encarecidamente hacer si puedes. Absolutamente, sí, no, eso definitivamente tiene mucho sentido. Y lo que realmente saqué de esta última pregunta y todas sus respuestas es que todos están como a bordo de los beneficios de TypeScript o como lenguajes fuertemente tipados y luego, de alguna manera, las desventajas están desapareciendo con el tiempo y la forma en que los clientes están evolucionando. Así que muchas gracias, amigos. Esa fue una gran discusión. Aprendí mucho de esto. Creo que nos estamos quedando sin tiempo. Así que si alguien no tiene comentarios, me encantaría cerrar esto y tal vez podamos llevarlo adelante más tarde en la masterclass especial. Tal vez nuestra audiencia tenga algunas preguntas. Así que muchas gracias. Esto fue, tuve un gran momento.

Y eso previene un nivel de ruptura que es tan común en otras aplicaciones que creo que es simplemente absolutamente crítico para móvil. No, estoy totalmente de acuerdo. Y me encanta cómo mencionaste o, como, destacaste la forma en que GraphQL resalta los beneficios del lado humano de las cosas, como la comunicación entre equipos, ¿verdad? Porque es algo tan subestimado, ¿verdad? Como, GraphQL está empoderando a los desarrolladores reales y no solo en términos de, como, las características que podemos enviar ahora o, como, los beneficios tácticos de esto, sino también, como, el lado humano de esto y cuánto nos ha empoderado para, como, comunicarnos mejor con nuestros compañeros de equipo. Sí, así que definitivamente estoy de acuerdo con eso. Y simplemente me encanta ese punto.

Luego también, algunos de los puntos que ustedes han mencionado, eso también me lleva a esta pregunta de seguimiento sobre, como, en nuestro desarrollo de aplicaciones, como dijo Joe, que había tantas cosas que realmente no notamos que estaban yendo mal hasta que llegó GraphQL. ¿Crees que, debido a ese aspecto, crees que, como, tener clientes que tengan soporte de GraphQL integrado sería, como, solo una experiencia elaborada para GraphQL en el lado del cliente sería realmente útil, o es, en el lado alternativo, es mejor tener, como, clientes que no son específicos de GraphQL, diría, sino como una utilidad para ello? ¿Cuáles son tus pensamientos sobre eso? Podemos comenzar contigo, Ellen.

Sí, quiero decir, creo que vengo del lugar de apoyar dos SDKs que están en lenguajes muy fuertemente tipados, y creo que, sabes, lo que definitivamente hemos encontrado es que, al menos en Swift y Kotlin, sé que hay otras experiencias móviles que a veces tienen un enfoque diferente, pero sé que en Swift y Kotlin, una de las grandes cosas que hemos encontrado es poder compilar todo a una consulta segura por tipo, ha sido enorme para muchas personas en términos de poder asociar ciertas cosas con vistas diseñadas individualmente y cosas así, pero también solo en términos de poder procesar datos que están obteniendo de GraphQL, y incluso si necesita ser, en algún momento, transformado en un modelo de vista o algo así, sigue siendo mucho, mucho más fácil al menos tener una idea de dónde estás comenzando para muchas de estas cosas.

Y creo que no es algo donde... Sé que en... En la web, hay muchas cosas donde es como, las cosas de relay están muy, muy estrechamente ligadas a los principios de UI de relay, y eso no es tanto el caso en móvil. Sé que alguien estaba diciendo, creo que fue Joe, estaba diciendo que hay algunas cosas que se manejan un poco diferente en Meta, pero creo que en el mundo más amplio de iOS y Android, creo que es algo donde la gente está intentando realmente duro integrar esto con SwiftUI y Jetpack Compose, que son frameworks más reactivos que están inspirados en React. Pero es algo donde no hay tanto un vínculo estrecho como lo hay, creo, entre GraphQL y React, y particularmente GraphQL y relay. Eso suena genial. Phil, ¿tienes algún pensamiento al respecto?

Depende, supongo. Hay un grado de cuánto dependemos de GraphQL dependiendo de qué cliente de GraphQL aquí estamos hablando. Creo que es particularmente interesante, y en realidad estoy esperando a escuchar lo que Dominik tiene que decir sobre esto, sobre diferenciar entre GraphQL como un patrón de UI y como una especie de principio guía de cómo construimos nuestras aplicaciones y un cliente como una biblioteca de obtención. Y creo que hay un equilibrio interesante que puede ir en cualquier dirección, dependiendo del caso de uso y dependiendo de los usuarios. Y ahora decidimos en realidad no agregar ningún shim, por así decirlo, para ejecutar GraphQL en el lado del cliente y en su lugar solo depender de APIs.

Y específicamente, creo, hace un par de años, esa fue una decisión más controvertida ya que la gente no estaba del todo lista aún para enviar APIs de GraphQL a producción y aceptar solicitudes y construirlas. Pero creo que ha habido muchos más casos y muchas más ventajas de GraphQL que han surgido más recientemente y han salido a la luz con el tiempo que muestran que cuando estás construyendo con GraphQL, cuando estás construyendo un esquema de GraphQL, es bastante importante diseñar ese esquema. Y creo que los mismos beneficios se aplican a por qué es un poco diferente hablar sobre un cliente de GraphQL y hablar sobre la obtención en general, porque depende de cómo estás construyendo tu aplicación y si te lanzas por completo, por así decirlo, o no.

Sí. Sí, eso tiene mucho sentido. Y estoy de acuerdo. También me gustaría, me encantaría escuchar lo que Dominik tiene que decir sobre esto. Me encantaría escuchar de ti, Dominik. Así que ni siquiera diría que ReactQuery es una biblioteca de obtención de datos, sino que incluso iría un paso más allá y diría que ReactQuery es solo un gestor de estado de Azure. Y esto siempre confunde a algunas personas cuando digo que ReactQuery no está atado a la obtención de datos en absoluto. Realmente no le importa cómo produces los resultados. En realidad, solo necesita ya sea una promesa resuelta o una promesa rechazada. Y cómo construyes eso depende completamente de ti. Y creo que este es un enfoque completamente diferente al que tienen otras bibliotecas. Así que no está atado a GraphQL en absoluto. No está atado a REST en absoluto. Y esto te da un poco de flexibilidad cuando tienes que trabajar con múltiples backends donde a veces tienes GraphQL, a veces tienes REST diferentes endpoints que tienes que alcanzar. Incluso he visto a algunos usuarios leer datos de la API de Ethereum o algo relacionado con Web3 para obtener datos a través de ReactQuery. Así que solo para gestionar los estados que tienes que son asíncronos. Pero, por supuesto, ReactQuery se utiliza más prominentemente con la obtención de datos. Y sí, no está atado a GraphQL así que ese es un compromiso que estás deshaciendo. Creo que son todos compromisos. La caché que tiene ReactQuery es una caché de documentos muy minimalista y no tienes todas las capacidades que podrías tener con una caché de GraphQL muy específica. Pero también tienes otros beneficios como poder usar múltiples fuentes o tener un contenedor de caché muy predecible y confiable que también te dará el poder que necesitas para hacer la reobtención que deseas en los momentos que lo desees. Absolutamente.

Y creo que solo para reiterar lo que algunos de ustedes han dicho sobre atar a sus clientes a GraphQL o no. Creo que depende totalmente de si estás completamente invertido en construir tu aplicación utilizando GraphQL por completo o muchas empresas, muchos productos lo están, tienen como código C y no migran completamente a GraphQL de inmediato. Tienen que pasar por como construir capas progresivas sobre esas APIs REST existentes. Y creo que tiene sentido tener algún tipo de marco impulsado por utilidades como un cliente que podría estar bien adaptado si deseas trabajar con GraphQL podría estar bien adaptado si deseas trabajar con APIs REST pero que tampoco está completamente atado a los patrones impulsados por GraphQL en sí. Así que eso tiene mucho sentido.

Joe, ¿tienes algún otro pensamiento sobre esto? Sí, sí, creo que hay una especie de, hemos tocado dos piezas. Una es el grado en que tu cliente está acoplado a GraphQL. Y luego lo que Ellen habló un poco sobre fue cuánto estás acoplado a la biblioteca de UI dada, ¿verdad?

Y así que para el primer tipo de acoplamiento a GraphQL. Sí, hay verdaderos compromisos allí como todos ustedes han hablado, ¿verdad? No todos tienen sus datos sus datos de backend en GraphQL. Incluso en Meta todavía hay algunas aplicaciones que tienen sus datos que no están expuestos a través de GraphQL por varias razones. Pero creo que hay compromisos reales con eso. Así que el GraphQL, el hecho de que te da un esquema tipado el esquema puede expresar mucha información de la que los clientes pueden aprovechar. Y así la razón por la que tenemos estos clientes potentes es el esquema GraphQL. Simplemente hay capacidades que podemos hacer con un cliente GraphQL que simplemente no se pueden hacer fácilmente con puntos finales REST arbitrarios, incluso si están completamente tipados, incluso si tienes una definición completa de TypeScript o cualquier otra definición para tus tipos que está proporcionando mucha información rica de tipos. De hecho, hay más información que un esquema GraphQL puede proporcionar. Por ejemplo, indicando a través de directivas cuál es la clave primaria, si esta entidad es almacenable en caché, esos tipos de información. Y luego también solo conocimiento sobre enums y cosas así, interfaces, la capacidad de introspección dinámica para realmente obtener el tipo, poder confiar en eso. ¿Cuál es el tipo concreto real de valor en tiempo de ejecución? No puedes hacer eso en general con un punto final REST. Y todas esas cosas son realmente fundamentales para construir un cliente muy potente para obtener consistencia de datos. Así que lo que tendemos a ver son básicamente clientes que son como, como dijiste, Dominic, con React Query, donde está realmente enfocado en el almacenamiento en caché de documentos. Pero incluso entonces, no sabes lo suficiente sobre lo que hay en ese documento para hacer cosas como invalidar automáticamente basándote en cambios porque no puedes hacer el enfoque de Oracle de simplemente usar nombres de tipos, que es un enfoque que probablemente va a invalidar en exceso bastante, pero al menos te da invalidación automática.

Y así hay un verdadero compromiso. Y así creo que, supongo que mi tipo de esperanza para el ecosistema es que trabajemos para facilitar la construcción de servidores GraphQL para que las personas puedan entonces simplemente aprovechar las capacidades del cliente GraphQL, en lugar de decir, bueno, simplemente vayamos al denominador común más bajo y construyamos clientes que solo pueden hacer lo que podríamos hacer con REST porque solo queremos hacerlo fácil de adoptar. Y así creo que los clientes hacen diferentes compromisos a lo largo de eso. Hay, supongo, toda otra pregunta de integrar en la capa de vista, que es, eso es como casi una pregunta separada. Absolutamente, no, eso tiene mucho sentido. Y solo, es bueno aprender sobre qué tipo de compromisos habría si, como dependiendo de tu enfoque, eso también plantea una pregunta que realmente quería escuchar todos sus pensamientos al respecto, pero Ellen ya respondió parcialmente eso pero aún me gustaría profundizar más en ello y escuchar de todos ustedes sobre, ya saben, como una de las innovaciones de GraphQL es introducir un esquema fuertemente tipado que expone información rica sobre las capacidades del servidor, pero luego creo que la mayoría de los clientes no o como no eligen, o no pueden usar mucha de esta información del esquema por defecto. Entonces, ¿cuánto crees que para tu escenario o para el espacio en el que estás trabajando, cuánto crees que esto sigue siendo cierto? ¿Y cuáles son tus pensamientos al respecto? Ellen, me encantaría comenzar contigo sobre esta pregunta, en realidad. Sí, creo que eso básicamente no es cierto en móvil. Creo que particularmente porque, de nuevo, como dije, una de las cosas que puedes hacer cuando tienes tanto el esquema que describe lo que es posible y luego la consulta que vas a hacer que dice, está bien, ¿qué es lo que realmente estoy pidiendo? Puedes hacer mucha validación sobre eso y luego también puedes generar código seguro en tipos que es realmente útil. Y sé que hay algunas cosas como sé que GraphQL code gen es enorme en este espacio, en TypeScript en particular, pero otro método que he visto en iOS, que es básicamente no cómo lo estamos haciendo, en Apollo, pero es algo más que he visto es esencialmente poder usar el esquema para crear consultas seguras en tipos cuando estás creando esas consultas en tiempo de ejecución. Así que hay muchas cosas que puedes hacer que realmente pueden aprovechar eso. Y creo que honestamente, creo que eso es una gran parte de la propuesta de valor para móvil solo porque hay tantas cosas que tenemos que hacer para tomar cosas de JSON y convertirlas en algo que sea utilizable en un lenguaje seguro en tipos.

Y tener ese nivel de validación incluso en tiempo de compilación, es súper, súper útil. Eso definitivamente suena útil y realmente conveniente pero en realidad comencé contigo solo para ver ese tipo de contraste entre el caso en el desarrollo móvil y luego cómo es para la web.

Entonces, Joe, ¿tienes algún comentario sobre esto desde tu lado? Ha sido realmente interesante ver cómo esto se ha desarrollado en el ecosistema. Quiero decir, definitivamente para móvil donde estamos trabajando con lenguajes muy fuertemente tipados creo que todos están, básicamente tu mano está forzada, ¿verdad? Vas a usar esta información del esquema aunque cómo la usamos allí sigue siendo interesante.

Pero en la web, creo que el ecosistema en la web tiende a enfocarse en la facilidad para comenzar y la simplicidad, ¿verdad? Ves mucho de, hay una especie de naturaleza cíclica donde tienes una biblioteca que aparece, resuelve más y más problemas. Inevitablemente, eso significa que tiene más características, más como, ya sabes, es una especie de, lo miras y dices, Oh, eso me da mucho, como, no necesito todo eso.

Y así en otras bibliotecas vienen y dicen como, Oh, somos más fáciles de usar. Entonces obtienen más adopción, añaden más características. Y luego algunos, como, ahora han caído en el mismo patrón. Y entonces, y solo ves esto como sucediendo sin fin en el ecosistema de JavaScript. Círculo de la vida.

Sí, honestamente como desarrollador de bibliotecas, es bastante frustrante de ver. Porque es como, ustedes solo van a chocar con este problema a continuación, y luego este problema a continuación y este problema a continuación. Y así, y lo que eso significa, sin embargo, es que, bueno, obviamente una de las formas más fáciles de comenzar es simplemente no usar el esquema.

Y lo que eso significa es que estás ofreciendo una experiencia mucho peor al desarrollador. Al aprovechar el esquema, en realidad puedes implementar la especificación gráfica correctamente. No puedes implementar la especificación gráfica correctamente si no conoces el esquema, si no conoces los tipos de objetos, si no sabes qué tipos implementan qué interfaces.

Y así vemos esto donde hay múltiples clientes en la web donde si no haces un trabajo extra, en realidad no obtendrás un comportamiento correcto. Y te estarás preguntando, espera, ¿por qué es esto, y básicamente cada cliente que no sea Relay, por defecto, obtendrás un comportamiento incorrecto en ciertas partes de la especificación porque no utilizan la información completa del esquema por defecto. Y así creo que es solo una manera realmente interesante en la que ha evolucionado el ecosistema. Definitivamente hay compromisos, ¿verdad? Facilita comenzar. Y así creo que eso no es para criticar, que estamos haciendo diferentes compromisos, pero es solo muy interesante cómo el esquema proporciona información tan rica y aún así no todos aprovechamos eso en la web.

Y creo que eso es solo un verdadero compromiso de, no es tan fácil construir algunas de estas características en JavaScript como nos gustaría. Creo que en las plataformas nativas, simplemente tenemos, la gente está acostumbrada a, ya sabes, un paso de construcción. Así que eso es como, claro, por supuesto que vas a tener un paso de construcción, así que tengamos más extra, ya sabes, añadamos más allí para dar aún más valor al desarrollador, mientras que en la web, es como, oh, otro paso de construcción. Y así hay como más de un, como, está bien, tal vez no tengamos un paso de construcción y hagamos algunos compromisos para obtener esa facilidad de uso y luego encajar en el ecosistema de JS.

No, eso definitivamente tiene mucho sentido. Como, es como entender el valor que GraphQL aporta y luego querer usarlo, pero luego también no poder de alguna manera como aprovechar todo el poder que podrías con tus aplicaciones, como construirlo con GraphQL. Así que Phil, ¿qué piensas sobre esto? Definitivamente hay compromisos, sí. Pero creo que hasta cierto punto, no siempre es como la biblioteca ofrece nuestro compromiso a hacer, al menos no en la opinión que tenemos en términos de Urql donde proporcionamos dos cachés predeterminadas diferentes. Cuando solo lo instalas, tienes una caché de documentos que es muy primitiva y puedes cambiar a una caché normalizada, en cuyo punto realmente recomendamos a las personas usar algo que llamamos conciencia del esquema, que es literalmente solo usar datos de esquema introspectivo para un comportamiento correcto.

Pero la razón por la que digo que no es nuestra decisión hacer en la web es porque hay tantas diferentes formas de usar la web, por así decirlo, para crear aplicaciones y páginas web. Y esa es la distinción que creo que vale la pena resaltar. A veces, cuando un desarrollador está creando una página muy basada en contenido. Por ejemplo, algún tipo de página de noticias, digamos, los datos son muy estáticos y no son altamente interactivos.

Y por lo tanto, es posible que ni siquiera estén interesados en algunas de las características dinámicas que obtienen de la caché normalizada. Y hay diferentes compromisos que quieren hacer. Y es más un caso de datos y de molestias de datos al configurar la caché normalizada y, por lo tanto, no lo hacen. Así que forzarlos a pasar por ese flujo de configuración es un poco un compromiso extraño que tendrían que hacer porque en realidad no están interesados en eso.

Pero para nosotros, lo que significa es que si alguien está realmente construyendo una aplicación, si alguien opta por la caché normalizada, somos mucho más agresivos al advertir a las personas si se encuentran con problemas. Y creo que eso es lo único que podemos hacer ahora mismo que podemos hacer, aparte de tal vez recomendar un co-generador gráfico, que en realidad está más del lado de integrar con tipos, integrando tus consultas con tu lenguaje y tu aplicación más de cerca y evitando errores. Pero creo que al menos de nuestra parte, hay un poco de matiz en esa discusión sobre cuándo el usuario está listo para actualizar, por así decirlo, cuándo un usuario está listo para asumir esa complejidad adicional. Y creo que hemos llegado a un acuerdo con dejar que el usuario decida cuándo llega ese momento.

Eso es definitivamente un enfoque realmente interesante, más centrado en el usuario, supongo. Y sigue siendo como, como dije antes, sigue siendo como si estuvieras usando GraphQL, pero entonces es más bien un viaje que solo un paso. Así que es más progresivo y saber para qué estás listo y con qué te sientes cómodo, y luego llegar lentamente a todo su potencial. Así que eso tiene mucho sentido.

Dominic, ¿tienes algún comentario que agregar a esto? Sí, bueno, no mucho. Así que estoy de acuerdo con Joe. También he visto la lucha de la vida donde la gente quiere bibliotecas más pequeñas con más características. Y luego agregas más características y la biblioteca es demasiado grande. Y luego alguien dice, usemos la más pequeña y luego comienza todo de nuevo. Y al mismo tiempo, compilaciones más rápidas, pero más cosas sucediendo en los pasos de compilación que obtenemos más corrección y más seguridad. Y sí, también son compensaciones nuevamente, por supuesto, porque React query es una biblioteca muy poco opinativa cuando se trata de cómo produces esa promesa.

También no podemos aprovechar tanto de la información que podrías tener. Un código de GraphQL, nuevamente, como se mencionó, es una muy buena manera de encontrar el término medio entre ello. También puedes crear tus hooks de use query desde React query con eso para obtener al menos algo de seguridad de vuelta. Y sí, la caché normalizada también es un tema que siempre surge mucho. Es algo que la gente está preguntando, ¿por qué React query no tiene una caché normalizada? Y la respuesta es, sí, es múltiple. Así que en un caso, es un problema muy difícil de resolver, creo.

Y es especialmente muy difícil de resolver si no tienes GraphQL. Así que si no estás en ese tipo específico, entonces se volverá aún más difícil. Así que realmente no hemos, sí, solo para decir que no hay una gran empresa detrás de React Query, realmente no hemos llegado a pensar mucho en esto. Pero también una de las cosas que la gente está queriendo más frecuentemente, incluso si no quieren una caché normalizada, es esta revalidación automática que también obtienes del esquema. Y esto es algo en lo que realmente hemos estado pensando en también agregar solo para dar esta experiencia a los desarrolladores y también a los usuarios.

Eso suena genial, Dominik. Esa es realmente una gran perspectiva. Así que me encanta eso. Eso también me lleva a esta pregunta sobre la seguridad de tipo. Y hay como dos lados diferentes a esto. El primero es que GraphQL introduce un esquema fuertemente tipado, así que solo tiene sentido usar un lenguaje fuertemente tipado para desbloquear el potencial completo del superpoder de GraphQL. Pero también quiero escuchar de ti, Dominik, sobre tu perspectiva, ya que dijiste que React Query es un cliente muy no opinado, así que me encantaría escuchar sobre solo desde la perspectiva de un cliente, no un cliente específico de GraphQL, ¿tiene sentido o cuáles son los beneficios y desventajas de construir un cliente usando un lenguaje fuertemente tipado versus un lenguaje débilmente tipado versus un lenguaje no tipado? Y luego podemos ver el contraste con los clientes específicos de GraphQL.

Sí, así que soy un fan de los lenguajes fuertemente tipados y también, quiero decir, si hablamos de TypeScript siendo un lenguaje muy fuertemente tipado, todavía creo que es una de las mejores cosas que podrían haberle pasado al ecosistema de JavaScript, y React Query inicialmente también fue escrito en JavaScript y solo proporcionó los tipos, pero luego muy rápido en la versión dos, lo escribimos en TypeScript. Y para nosotros como autores de la biblioteca, creo que solo trae una facilidad de mantenibilidad y seguridad de tipo que tenemos dentro si la biblioteca también está escrita en TypeScript. Y luego también se proyecta eso en los consumidores porque obtienen los tipos que tenemos que usar. Por supuesto, hay una curva involucrada en esto. Quiero decir, aquí es donde escuchaste sobre personas comenzando con TypeScript que preferirían hacerlo en JavaScript. Pero creo que vale la pena muy rápido si simplemente sigues ese camino. No lo haría de ninguna otra manera.

Suena increíble. Exactamente lo que esperaba. Así que es realmente bueno escuchar eso. Joe, ¿tienes algún pensamiento de tu parte sobre este tema sobre, ¿qué piensas sobre emparejar GraphQL con un lenguaje fuertemente tipado o como versus un lenguaje débilmente tipado o no tipado y los beneficios potenciales o las desventajas de eso? Sí, quiero decir, creo que, estábamos usando relay hace mucho tiempo antes de Flow, supongo que alrededor del mismo tiempo en que Flow estaba comenzando internamente, ¿verdad? Donde gran parte del código que consumía consultas de relay no estaba escrito en un lenguaje tipado y proporcionó mucho valor desde entonces. Así que creo que un cliente de GraphQL te da muchas capacidades, ¿verdad? Como la capacidad de coalescer todas tus dependencias de datos en una sola solicitud, ¿verdad? La consistencia de datos, todas las cosas que, muchas de las cosas de las que hemos hablado no son realmente específicas de los lenguajes de tipo. Son solo estas capacidades fundamentales que GraphQL te da. Obviamente, porque tienes el esquema, también puedes producir tipos fuertes. Y sí, soy un gran fan de la tipificación fuerte. Así que, ciertamente, como, creo que es incluso mejor, vas a obtener una aplicación mejor y más confiable en general. Creo que si construyes con un lenguaje fuertemente tipado, definitivamente es complicado construir el cliente en sí en un lenguaje fuertemente tipado, porque al final, si estás trabajando con una caché normalizada, tienes que tener muchos datos mezclados. Y así, básicamente tienes este esquema fuertemente tipado donde el fragmento, digamos, dice que necesita leer el campo de nombre y se supone que debe ser una cadena. Pero lo que tienes en la tienda es, incluso si tu representación, incluso si estás usando un lenguaje fuertemente tipado donde tienes un enum o unión adecuada expresando el hecho de que los datos del campo podrían ser una cadena o un bool o lo que sea, aún en algún momento tienes que decir, está bien, bueno, voy a esperar que sea una cadena ahora. Voy a esperar que este valor de campo sea una cadena y esto es como la cosa fundamental donde al final, cuando pasas de una base de datos, que es lo que la caché normalizada es hasta una aplicación, tienes este... El límite que estás cruzando de un mundo dinámico no tipado, ¿verdad? Así que puedes obtener mucha seguridad de tipo dentro del código del cliente, pero hay un límite en ese límite. Pero afortunadamente, de nuevo, tenemos un esquema. Pero solo tienes que tener cuidado en cómo diseñas el cliente para evitar que los datos se escriban en la caché que violan el esquema. Y así, eso es algo de lo que debes estar consciente mientras construyes un cliente así.

Suena bien y creo que eso también podría haber sido como una discusión más profunda pero tal vez podríamos guardarlo para una charla especial. Así que nos encantaría escuchar más pensamientos al respecto. Pero Phil, ¿tienes algún otro pensamiento sobre esto? Quiero decir, desde el punto de vista de los usuarios, es impensable en estos días, creo, al menos en la web no usar TypeScript con GraphQL debido a la seguridad que te da. Supongo que para volver a, creo que lo que Dominic más reflejó sobre construir clientes o clientes de GraphQL con un lenguaje de tipo y en este caso, ni siquiera un lenguaje fuertemente tipado. Creo que cuando estás construyendo algo como una caché y lo que Joe está insinuando, es que sin estas garantías de tipo, encontrar todos los errores habría sido imposible para nosotros. De hecho, teníamos tantos requisitos para nosotros mismos en términos de cómo debería funcionar un código o específicamente caché de Graph o caché normalizada que muchas partes que teníamos inicialmente estaban incluso escritas en rescript, anteriormente Reason. Supongo que esa es la forma aprobada por Facebook / Meta irónicamente. Pero con el tiempo esto se desvaneció porque los reemplazamos con partes reescritas en TypeScript. Dicho esto, sí, quiero decir, para nosotros y para los usuarios, los beneficios de usar TypeScript sobre nada en absoluto son bastante claros. Y quiero decir, las desventajas han desaparecido con el tiempo. Así que creo que no hay nada realmente que agregar a eso. Interesante. Sí, definitivamente.

Ellen, ¿cuál es tu perspectiva sobre esto? Sí, quiero decir, así que solo admitiré que personalmente, estoy increíblemente sesgada a favor de los lenguajes fuertemente tipados. Como son básicamente lo que he usado toda mi carrera de programación. Pero creo que una de las cosas que puede ser una desventaja es que si estás trabajando con un lenguaje fuertemente tipado, tienes que encajar algo que está construido para un lenguaje que no es fuertemente tipado en lo que sea que sea tu paradigma de lenguaje fuertemente tipado. Un lugar donde encontramos problemas con esto con el cliente de iOS en Apollo es que tenía esta gran idea de intentar convertir básicamente fragmentos en protocolos para Swift. Y una historia extremadamente larga resumida es que Swift no soporta del todo la forma en que quería que funcionara porque realmente no tiene soporte completo para covarianza. Y fue interesante, nuestro cliente de Android y Kotlin pudo como ejecutar esa idea porque Kotlin sí tiene soporte para covarianza y contravarianza, es bastante completo. Y pudieron realmente avanzar significativamente más en eso de lo que yo terminé desechando como un año de trabajo. Así que es algo donde tomar algo que está construido para un lenguaje de tipo débil y tratar de ponerlo en un lenguaje de tipo fuerte a veces tiene sus desventajas. Pero estoy muy de acuerdo con todos aquí como aprovechar esta información que obtienes gratis del esquema es tan, tan, tan útil para escribir una aplicación correcta que es algo que recomiendo encarecidamente hacer si puedes hacerlo.

Absolutamente, sí, no, eso definitivamente tiene mucho sentido. Y lo que realmente saqué de esta última pregunta y todas sus respuestas es que todos están como a bordo de los beneficios de TypeScript o como lenguajes fuertemente tipados y luego, en cierto modo, las desventajas están desapareciendo con el tiempo y la forma en que los clientes están evolucionando. Así que muchas gracias, chicos. Fue una gran discusión. Aprendí mucho de esto. Creo que nos estamos quedando sin tiempo. Así que si alguien no tiene comentarios, me encantaría cerrar esto y tal vez podamos llevarlo adelante más tarde en la charla especial. Tal vez nuestra audiencia tenga algunas preguntas.

Así que muchas gracias. Esto fue, tuve un gran momento. Tener esta discusión con todos ustedes. Adiós. Gracias. Gracias. Muchas gracias. Gracias. Muchas gracias por unirte a nosotros hoy. Gracias por venir y espero que podamos tener muchas más de estas discusiones en el futuro. Muchas gracias por tener esta discusión con todos ustedes. Adiós. Muchas gracias por tener esta discusión con todos ustedes. Adiós. Muchas gracias por tener esta discusión con todos ustedes. Adiós. Muchas gracias por tener esta discusión con todos ustedes. Muchas gracias por tener esta discusión con todos ustedes.