Tu Ritmo con GraphQL

♪ Hola, soy Phil. Y hoy estoy aquí en GraphQL Galaxy para hablar contigo sobre encontrar tu ritmo con GraphQL. Esta charla es un poco desde mi perspectiva sobre cómo comenzar en el ecosistema actual, lo que podrías encontrar, los problemas que he visto que la gente encuentra, y lo que significa usar GraphQL hoy en día.

Un poco sobre mí, puedes encontrarme en las redes sociales como Kitten en GitHub o como underscore PhilPL en Twitter, o en Mastodon, si eso es lo tuyo. Actualmente mantengo Urkel, junto con otras personas. Urkel es un cliente de GraphQL que fue fundado originalmente por Formidable y es compatible con frameworks como React, Preact, Vue y Svelte. Actualmente estamos trabajando en Unoco, un equipo de apoyo que se encargará de mantener este proyecto a tiempo completo.

Actualmente, lo que hemos visto en el último año es que Urkel ha crecido mucho, y eso se corresponde con el crecimiento de GraphQL en general. No solo Urkel está creciendo, sino que si miramos el número de clientes de Apollo, podemos ver que también los números solo van en aumento y GraphQL se está volviendo más popular. Más personas que nunca están adoptando GraphQL y subiéndose a bordo.

Esto nos lleva a algunos problemas, y recibo muchas preguntas sobre Urkel. Recibo muchas preguntas sobre GraphQL. Por lo general, estos problemas no son nuevos para mí. Pero en la madurez actual de GraphQL, me hago algunas preguntas sobre estos problemas, ¿por qué todavía estamos luchando con problemas sencillos? Nada responde mejor a eso que la encuesta sobre el estado de GraphQL en 2022. En esa encuesta, básicamente pidieron a las personas que respondieran una serie de preguntas y midieran la popularidad de las bibliotecas y la satisfacción con el ecosistema. Pero también tenían una sección sobre los puntos de dolor de GraphQL, y las personas podían votar en varias cosas sobre lo que actualmente encuentran doloroso en el ecosistema.

Si lo miramos, vemos algunos puntos comunes que pueden no ser demasiado sorprendentes. Vemos que las personas lidian con el manejo de errores, y eso es doloroso, problemas de rendimiento, almacenamiento en caché del cliente, y así sucesivamente. Lo que encuentro sorprendente aquí, sin embargo, son algunos de estos puntos que realmente no esperaría ver en este punto del ecosistema. Así que vemos que las personas están luchando para que su API sea rendimiento. Están luchando con los esquemas, el abandono y la versión. Y eso me preocupa, pero en este punto, me sorprende que no hayamos avanzado en estos problemas y no tengamos buenas respuestas para ellos.

GraphQL, por supuesto, también tiene puntos fuertes, y la encuesta sobre el estado de GraphQL lo midió. Y de manera similar, aquí vemos puntos fuertes muy sólidos que encontrarías en cualquier introducción a GraphQL. Por ejemplo, la seguridad de tipos en primer lugar, la introspección a continuación. Pero hay algunos puntos aquí que me preocupan. El exceso de datos todavía se considera un punto fuerte importante que GraphQL resuelve. Sin embargo, el exceso de datos ni siquiera es un principio fundamental de lo que GraphQL pretende resolver. De hecho, lo veo como un problema fundamental que cualquier API bien diseñada probablemente debería abordar. También vemos aquí que la unión de esquemas vuelve a surgir, y esto es bastante interesante, ya que significa que mucha gente piensa que la unión de esquemas es tanto una ventaja importante de GraphQL como un punto de dolor importante.

Por último, vemos a la comunidad como el último punto en los puntos fuertes de GraphQL. Años después de GraphQL y con muchas opciones diferentes para elegir, me resulta sorprendente que las personas tengan dificultades para ver a la comunidad de GraphQL tan acogedora como debería ser. Al ingresar a GraphQL, creo que estás siguiendo una trayectoria muy similar a la de muchos otros equipos, y al principio piensas que la propuesta de valor de GraphQL es muy emocionante y sorprendente, y estás ansioso por resolver tus problemas. Más adelante, es posible que te preguntes: ¿cómo me preparo para tener éxito? ¿Cómo logro que mi equipo tenga éxito? Luego, las cosas se vuelven un poco problemáticas para la mayoría de las personas. Te haces preguntas como: ¿estoy obteniendo valor de GraphQL en general? ¿Realmente estás encontrando las herramientas adecuadas para el trabajo? Más adelante, muchos equipos se arrepienten de muchas elecciones iniciales y hacen pequeños ajustes. En este punto, las personas vuelven atrás y revisan sus decisiones.

Esta charla ha sido un poco difícil de escribir. Ahora veo a muchas personas diferentes ingresar al espacio de GraphQL. Equipos muy diferentes pueden comenzar en cualquier momento y cada uno tiene diferentes expectativas de GraphQL. Y muchos equipos probablemente se quedan sin tiempo tratando de solucionar sus problemas y abandonan el espacio antes de poder comunicar lo que necesitaban de GraphQL. Volviendo a estos tres puntos diferentes, las preguntas que quiero plantear son: ¿cuál es la propuesta de valor de GraphQL? Si estás ingresando a GraphQL y probablemente estás en esta conferencia porque quieres usarlo o porque ya lo estás usando, ¿qué es lo que quieres obtener de GraphQL? ¿Y cómo te preparas para tener éxito si ya sabes lo que quieres? Y por último, ¿cómo me mantengo en el camino correcto? GraphQL puede ser abrumador, pero ¿cómo me mantengo en el buen camino para usarlo correctamente? Creo que la primera pregunta es en torno a lo que todo gira. ¿Por qué debería usar GraphQL? Y eso es con lo que quiero comenzar. Creo que GraphQL tiene una propuesta de valor diferente para muchas personas diferentes. Y creo que tenemos que mirar dos ejes aquí. Tenemos que usar un eje que nos muestre cómo piensan las personas del frontend o cómo piensas tú cuando estás mirando tu stack de frontend. Y cómo un equipo de backend podría verlo. Un equipo de backend podría verlo. Pero GraphQL también cambia dependiendo de si estás mirando organizaciones pequeñas o grandes, equipos pequeños y grandes, incluso múltiples equipos que trabajan en ello. La dificultad aquí es que estarás en un lugar diferente al de cualquier otra persona. La mayoría de los puntos en este eje plantearán algún problema de alguna forma, y es posible que tengas preguntas muy diferentes dependiendo de dónde te encuentres. Dependiendo de si estás muy enfocado en el frontend y eres un equipo más pequeño o un equipo más grande que tiene muchos servicios de backend. En cualquier situación, es posible que ya estés convencido de usar GraphQL. Después de todo, estás en GraphQL Galaxy. Sin embargo, esto se debe a que GraphQL tiene respuestas muy sólidas a problemas básicos que cualquier API enfrenta. Ya he mencionado el exceso de datos antes, pero muchas soluciones diferentes pueden surgir al pensar en cómo puedo resolver el exceso de datos. GraphQL no es la única respuesta si solo estás pensando en problemas simples. Y eso me lleva a la siguiente parte, cortando a través de la exageración de GraphQL. ¿Por qué estamos usando realmente GraphQL? Y por qué las razones que estamos pensando a veces son un poco demasiado simples. Y quiero reducir esto en estas partes separadas en este eje. Y quiero comenzar con el frontend, ya que como mantenedor de clientes de GraphQL, estoy más familiarizado con eso.

Y cuando estás analizando GraphQL en el frontend hoy en día, es posible que encuentres que el valor que las personas ven en GraphQL está disminuyendo y que no están tan emocionadas como solían estarlo. Hoy en día, tenemos muchas opciones para aumentar la productividad de los desarrolladores frontend. Y cuando estás configurando un nuevo proyecto, tienes una variedad de opciones para elegir. Puedes optar por un enfoque de generación de sitios estáticos de Jamstack, los componentes del servidor Reactor en el horizonte, los patrones de carga vuelven a ser populares, y has visto eso en Next y en el próximo Remix. Y están surgiendo nuevas bibliotecas como TRPC, que hacen que las funciones externas sean fácilmente invocables y con tipos. La propuesta de valor completa de GraphQL pierde su ventaja si nos enfocamos en demasiados problemas diferentes que son un poco demasiado pequeños. Por ejemplo, si estamos considerando estas dos cosas diferentes, la gente pregunta, ¿es TRPC más fácil, pero agrega el mismo valor a mi proyecto? ¿O la generación de sitios estáticos está tan desconectada de la necesidad real de GraphQL, aunque podríamos usar métodos mucho más simples para obtener nuestros datos?

Me gustaría retroceder un paso aquí y decir, ok, pienso en el desarrollo frontend en términos de tener vistas de IU que están compuestas por árboles de componentes, y cada componente tiene un conjunto de requisitos de datos. Si miramos, por ejemplo, la generación de sitios estáticos desde esa perspectiva, podemos exportar nuestras vistas de antemano y los proveedores de datos como GraphQL desaparecen en el lado del cliente. Pero esto deja de lado puntos importantes sobre interacciones y casos de uso, como si una vista no es serializable. Entonces, si estás pensando en aplicaciones móviles o aplicaciones web no, PWAs, y así sucesivamente. El siguiente punto es obviamente, ¿pero RPC y REST aún pueden resolver estos problemas? ¿Qué pasa si simplemente perdemos el esquema y solo usamos RPC? ¿Qué perdemos realmente si abandonamos GraphQL y solo nos enfocamos en la entrada y salida, obtenemos nuestros datos y estamos contentos? Ese es el problema, si elegimos realmente comparar GraphQL con los métodos de recuperación de datos, muchos de estos supuestos puntos fuertes que la gente piensa cuando piensa en GraphQL desaparecen. Estos puntos pueden ser el exceso de datos, pero también podemos pensar en prevenir solicitudes en cascada, podemos pensar en problemas de rendimiento donde GraphQL nos brinda herramientas para optimizar los resolutores. Podemos pensar en fragmentar nuestros datos, pero todos estos puntos se pueden resolver con soluciones basadas en RPC.

Entonces, si volvemos a la segunda idea y pensamos en los requisitos de datos en GraphQL, creo que aquí es donde GraphQL realmente brilla y donde la propuesta de valor se vuelve muy fuerte. Si piensas en GraphQL como su esquema que se mapea directamente a la estructura de datos de tu aplicación, ahí es donde encuentras mucho valor. Que puedes estar perdiendo si estás pensando en problemas técnicos como el exceso de datos. Entonces, la pregunta que quiero hacer a cualquiera que ya haya comenzado con GraphQL y que se haya desilusionado un poco al probarlo en un equipo es, bueno, es posible que te hayas convencido de los problemas básicos en lugar de centrarte en los problemas más grandes y las soluciones más sólidas que GraphQL puede ofrecerte. Después de todo, GraphQL es una especificación y un marco bastante completo, y puede ayudarnos a escribir modelos de datos declarativos, puede ayudarnos a tener un esquema de tipos. Y también, para dar un ejemplo, entra en un concepto que me gustaría llamar el lingua franca de GraphQL, que es uno de los principios de diseño principales de GraphQL, como también se menciona en la sección de descripción general de la especificación, que GraphQL es centrado en el producto. Y en eso, puede servir como un lenguaje común no solo técnicamente para el servidor y para el cliente y la comunicación de la API, sino que también es un lenguaje que tus ingenieros frontend y backend pueden usar para comunicar lo que quieren decir cuando hablan de datos. Entonces, la lección que aprendo de eso y lo que quiero decirle a la mayor cantidad de personas posible es pregúntate, en comparación con no tenerlo, ¿qué hará GraphQL por tu equipo? Y si puedes responder esa pregunta por ti mismo, ya estás en un lugar mucho mejor. Y es entonces cuando comienzas a tener una perspectiva diferente sobre el astronómicamente grande ecosistema de GraphQL y las diferentes elecciones que debes hacer. Y dije antes, una de las ventajas de GraphQL es que viene con todo incluido. Y lo hace, en cierto sentido, la especificación tiene la implementación de referencia. Obtenemos documentación incorporada. La introspección es una gran característica, pero aún tenemos que tomar muchas decisiones. Y es entonces cuando el otro eje de organizaciones pequeñas y grandes se vuelve muy importante, porque es posible que tomes decisiones diferentes según los requisitos que tengas, según el tamaño de tu equipo o equipos. Y estás expuesto a muchas opciones en estos días si estás mirando GraphQL.

Incluso si solo estamos considerando el desarrollo web y JSFirst, tienes muchas decisiones que tomar. Debes elegir entre diferentes clientes de GraphQL. Por ejemplo, podrías preguntarte, ¿voy a usar Relay, Urql o el cliente de Apollo? Debes elegir un servidor de GraphQL. Y podrías elegir Mercurius, GraphQL Yoga o el servidor de Apollo. Podrías elegir un constructor de esquemas de GraphQL. Y eso te brinda una forma más agradable de organizar tu API. Podrías elegir Pothos, TypeGraphQL, GraphQL Nexus o GraphQL Code Generator. Y esa elección incluso podría desaparecer o cambiar si estás usando un generador de GraphQL. Podrías usar AWS AppSync o Amplify. Podrías usar Graphil, Hazura, DGraph o GraphQL Mesh para generar una API, y eso reemplaza parte de la construcción manual del esquema. Y eso depende más de tus fuentes de datos. Estas son muchas elecciones. Y la buena noticia es que, aunque esto pueda parecer mucho, esto depende de las necesidades de tu equipo, pero aún hay muchas decisiones que tomar. A menudo tienes una selección más pequeña de cosas para elegir, sin embargo, si consideras tus restricciones y requisitos.

Entonces, tu cliente de servidor puede no estar escrito en JS, en cuyo caso todas las opciones de backend, si estás escribiendo en un lenguaje diferente, pueden reducirse a una variedad de soluciones diferentes, pero un conjunto más pequeño. O en el lado del cliente, es posible que tengas un framework de UI específico con el que estás trabajando, y no todos los clientes de GraphQL admitirán todas las bibliotecas de UI y frameworks. O tienes requisitos de tiempo de ejecución específicos y lo que hace tu cliente, o lo que tiene que hacer tu backend. No todos los clientes admitirán eso. El almacenamiento en caché normalizado es básicamente un requisito que a menudo veo en las personas, y he limitado el conjunto de clientes de GraphQL en esa lista a aquellos que tienen almacenamiento en caché normalizado.

También es posible que ya tengas opiniones específicas sobre cómo deseas crear consultas de GraphQL y eso también puede influir en esto. Y Relay ya viene con algunas de estas decisiones predefinidas. Desde mi perspectiva como mantenedor de Urql, vemos muchas combinaciones diferentes, pero combinaciones muy fijas en estas herramientas. Por ejemplo, para Urql, vemos, por ejemplo, mucho de GraphQL Yoga mezclado con GraphQL Nexus. Pero si estás usando PostGraphQL Relay juntos, esa podría ser una elección más estrechamente acoplada que otras porque Relay también tiene ciertos requisitos en el esquema y PostGraphQL también tiene muchas opiniones que se mezclan bien con Relay.

Si estás diseñando en el cliente, una de las cosas que debes hacer es estructurar tus consultas y los requisitos de datos y ver cómo estás construyendo estas consultas o los patrones que deseas aplicar probablemente sea más importante que las características específicas del cliente. Por ejemplo, Relay tiene, como acabo de decir, muchas opiniones. Entonces, tiene opiniones sobre cómo combinar consultas y cómo una vista típicamente ejecutará una sola consulta y elevará y compondrá fragmentos en ella. Si te gusta eso, entonces por ejemplo, echa un vistazo a Relay o aplica el mismo patrón a otros clientes de GraphQL y tu decisión será mucho más fácil.

En cuanto a los constructores de esquemas, me enfocaría más en la estructura del equipo y es posible que tengas que hacerlo después de todo. Es posible que no desees elegir cualquier servidor GraphQL o cualquier constructor de esquemas en particular solo porque es técnicamente interesante, pero es posible que desees considerar quién está escribiendo tu esquema y quién es tu autor de esquemas, y luego adaptar esas prácticas a la estructura del equipo y al constructor de esquemas que elijas.

Por último, quiero hablar un poco sobre los equipos de backend y eso está muy alejado de lo que hago todos los días, pero tengo mucha experiencia en ello, construyendo APIs y acompañando a las personas como consultor en el proceso de construcción de una API de GraphQL. Y si estamos pensando en una API de GraphQL, es posible que pienses en un esquema monolítico. Esta es la estructura que puedo imaginar si estamos pensando en GraphQL. GraphQL agrega y combina datos de diferentes fuentes de datos, ya sea Stripe billing junto con tu base de datos, junto con algún tipo de canalización de activos, ¿quién sabe? Y esos recursos van a tu puerta de enlace de GraphQL, tienes un esquema en tu aplicación, se realiza el acceso. Por supuesto, otras personas y otros equipos pueden pensar en ello de manera diferente, pueden estar pensando en múltiples aplicaciones que tienen, tal vez tengan una aplicación para Android, iOS y web. Y piensan en cómo todos estos clientes quieren acceder a ese esquema de manera ligeramente diferente y luego acceder a los recursos a través de ese esquema. En realidad, las personas descubren rápidamente que es obviamente una combinación de ambas. Tienes muchos recursos diferentes que se proporcionan a través del esquema a esas aplicaciones. Y tú, como diseñador de esquemas, eres responsable de asegurarte de que ese acceso funcione para todas estas aplicaciones y se ajuste a lo que están tratando de mostrar.

Mucha gente se obsesiona con la idea de que tenemos múltiples recursos, tenemos múltiples servicios. Entonces, claramente podríamos agrupar GraphQL en esquemas separados. Y luego fusionar esos esquemas en una puerta de enlace. La gente a veces se paraliza por esta decisión sobre si ya deberían adoptar una arquitectura de microservicios con GraphQL. Y si bien hay diferentes términos para ello y podríamos considerar diferentes formas de tomar esa decisión, considera si es un problema técnico si deseas estructurar tu servicio de GraphQL como múltiples microservicios o si tienes una pregunta de gobernanza en lugar de tener múltiples equipos que trabajan en recursos y APIs separadas y quieres que sigan siendo capaces de trabajar por separado. Muchas veces he visto a los equipos luchar con eso. Y la respuesta a menudo es que debes establecer alguna gobernanza. Y vale mucho la pena si todos diseñan un esquema juntos y se unen para construir un monolito primero. Incluso si no estás construyendo un monolito y estás eligiendo una de estas otras soluciones, entonces aún puedes decidir que unirse y diseñar el esquema con un equipo centralizado realmente vale la pena al principio al comenzar. Los monolitos de GraphQL son puertas de enlace. Esto también abre diferentes respuestas más fáciles. Muchas personas que están migrando a GraphQL están haciendo la puerta de enlace de GraphQL y el acceso a las antiguas APIs REST o APIs antiguas en general. Entonces, la otra pregunta que debes considerar es dónde quieres comenzar a usar GraphQL. A menudo, GraphQL es una solución para el front-end y el back-end y puede reemplazar muchas de las funcionalidades que antes hacíamos con APIs específicas para cada aplicación. Pero debes preguntarte si quieres que GraphQL vaya más allá y reemplace todos mis servicios y todas mis APIs antiguas. A menudo, simplemente puedes absorber esa funcionalidad en el monolito en su lugar. Entonces, el problema es preguntarte cuál es la arquitectura mínima que tu equipo puede adoptar hoy para beneficiarse de GraphQL. Ahora, todas estas categorías separadas de problemas son básicamente problemas de cómo evitar caer en la trampa de GraphQL. Todos estos problemas son muy similares en el sentido de que son preguntas que puedes hacerte al principio, pero que pierden importancia si te enfocas en hacer que las cosas funcionen hoy y si te mantienes fiel a tus elecciones. Sin embargo, el ecosistema no siempre tiene respuestas excelentes, es posible que te preguntes qué sucede si quiero pasar a esquemas federados en el futuro. ¿Qué sucede si necesito almacenamiento en caché normalizado en el futuro? Necesito cambiar mi decisión sobre qué clientes de GraphQL usar. Y la respuesta a eso es que el ecosistema aún no tiene respuestas excelentes, no tenemos todas las respuestas sobre cómo moverse cuando estás creciendo como organización hacia nuevas soluciones, excepto las soluciones tradicionales de comenzar de nuevo con algunas partes.

Por otro lado, como ya he mencionado, el lado del cliente tiene muchas opiniones y enfoques posibles para escribir tus consultas y estructurar tu aplicación. Pero esa guía puede ser bastante confusa. Y hoy en día, solo Relay tiene las opiniones más sólidas sobre cómo estructurar tu aplicación. Y aunque eso funciona para React y hay adaptaciones para otros marcos de UI, todavía estamos un poco lejos de tener la experiencia de desarrollo perfecta combinada con buenas opiniones que te brinden más orientación para construir estas aplicaciones.

Entonces, cuando construyas tu API de GraphQL, si estás comenzando con GraphQL, lo que puedo recomendarte es que, para tu equipo, encuentres la mayor intersección de características y requisitos de lo que necesitas. Elige las herramientas y no te distraigas al principio. Muchas personas están contentas y son productivas con GraphQL, ya sea en organizaciones pequeñas o grandes, porque han tomado decisiones sólidas. Y cuando esas decisiones resultan tener fallos, aún se mantienen fieles a ellas por un tiempo para descubrir cuáles son los problemas reales. Porque a veces puede haber problemas de gobernanza en su lugar.

Ahora, esto solo dura 20 minutos y eso es todo en mi charla. Pero si tienes más preguntas, puedes ir a la sesión de preguntas y respuestas o puedes contactarme en Twitter o Mastodon, o puedes consultar la documentación de Oracle en este enlace. ¡Salud! Brian, hola de nuevo, es bueno estar aquí. Muchas gracias por estar aquí. Genial. Y ahora vamos a comenzar con la sesión de preguntas y respuestas. Como recordatorio, puedes seguir haciendo preguntas en Discord en el canal de preguntas y respuestas de Andromeda. Pero comencemos echando un vistazo a las respuestas a tu pregunta de la encuesta. Esta es divertida. La pregunta fue, ¿cómo te sientes acerca de GraphQL en una palabra? Parece que has obtenido algunas respuestas positivas aquí. ¿Qué opinas sobre los resultados, Phil? Wow, eso es realmente positivo. Es interesante. Qué momento interesante en GraphQL. Y siento que estamos en el umbral de muchas cosas. Así que me alegra ver que es positivo. Por otro lado, esperaba al menos un poco de negatividad. No sé. ¿Quién más espera negatividad? No debería esperar eso. Creo que es bueno esperar comentarios, ¿verdad? Siempre puedes crecer cuando recibes comentarios. Pero supongo que tal vez la audiencia aquí hoy se siente bien después de ver todas las charlas y todo eso.

Me alegra verlo. Genial. Así que podemos seguir adelante y comenzar con algunas de las preguntas que tenemos. La primera pregunta es, ¿cuál es el futuro del cliente de Urkel GraphQL? Esa es una pregunta muy oportuna. Ayer anunciamos que Urkel se está trasladando a una organización independiente en GitHub. Urkel fue fundado en Formidable. Si ya has visto el repositorio de Urkel, es posible que estés acostumbrado a ver asociado a Formidable con eso. Y solía trabajar allí. Jorvi y yo mantuvimos Urkel en gran medida mientras estábamos en Formidable. Y por eso ayudé a comenzar el proyecto y darle forma a lo que es hoy. Hemos tenido muchas conversaciones con ellos sobre el futuro del proyecto y su longevidad. Hemos llegado a un acuerdo interesante, que es, si ya lo hemos estado manteniendo, ¿por qué no hacerlo explícito? Así que Urkel ahora es bastante independiente. Verás a Urkel-GraphQL como una organización en GitHub. Básicamente, nos comprometemos a seguir manteniéndolo, pero lo estamos llevando hacia un nuevo nivel y tratando de encontrar una nueva estabilidad en el proyecto donde cualquiera puede entrar y ayudar. Eso es realmente increíble. Felicitaciones. Es una noticia emocionante sin duda.

Luego, en cuanto al futuro del cliente, desde una perspectiva técnica, ¿hay algo que esté por venir que quieras señalar o en lo que estés trabajando? Sí, para hacer referencia a parte de mi charla, creo que estamos en un punto interesante donde muchas personas nuevas están ingresando a GraphQL y muchas personas están descubriendo cómo podemos hacer crecer GraphQL. Ya llevamos muchos años en esto y las personas están alcanzando los límites de donde comenzaron con GraphQL. Entonces, las personas están comenzando sus primeros proyectos y las API son una cosa, pero también estamos viendo a muchas personas que ahora están escalando hacia múltiples API, que las están escalando hacia organizaciones cada vez más grandes. He visto a muchas empresas y equipos luchar con eso. Es gracioso decir equipos porque en algunas organizaciones pueden estar en una encrucijada donde otro equipo se está uniendo al desarrollo de una API de GraphQL y ya estás en el punto en el que estás manteniendo múltiples aplicaciones que utilizan esa API. Y mantener un cliente de GraphQL, desde mi perspectiva, creo que aún no estamos haciendo lo suficiente para ayudar a las personas, tanto a las que están comenzando como a las que están escalando hacia aplicaciones realmente grandes. Obviamente, hoy hemos escuchado sobre GraphQL Code Generator. También hemos escuchado sobre otros clientes hoy. Y creo que el mensaje principal aquí es que si estás buscando clientes de GraphQL hoy y, por ejemplo, estás considerando Relay, ya estás viendo muchas opiniones y mucha ayuda para comenzar con eso. Aunque la crítica más grande de Relay ha sido en el pasado que su documentación no es increíble. Por otro lado, con Urql, la crítica más grande que recibimos es que no hacemos lo suficiente porque no somos buenos anunciando cómo se debe usar. Así que realmente estoy deseando enfocarme con Urql en construir una historia coherente de cómo se usa y llegar a esa mejor etapa de experiencia de desarrollo donde las personas puedan comenzar a trabajar con ella tal como es. Sí, definitivamente hay desarrolladores, especialmente cuando estás escalando, a los que les gusta ese tipo de documentación con opiniones o cómo se debe usar, cómo se debe abordar la toma de decisiones. En ese mismo sentido, en cuanto a la escalabilidad y a medida que las organizaciones crecen y evalúan qué clientes utilizar o si van a incorporar una herramienta específica, ¿cuáles son algunas mejores prácticas para evaluar eso? Creo que lo primero con lo que siempre comienzo es, supongo que la respuesta más larga está en mi charla, es quedarse con lo que te resulta cómodo. Y muchas veces las personas buscan encontrar la respuesta perfecta que funcione para ellos en, digamos, meses o años. Y creo que cuando estoy evaluando herramientas, lo que estoy buscando es, ¿cómo podemos obtener la mejor experiencia de desarrollo en este momento? Y eso tal vez sea un poco de pragmatismo. He trabajado como consultor durante muchos años. Y lo que estás buscando es, ¿cómo hacemos feliz a nuestro equipo en este momento? ¿Cómo llegamos a una fase productiva y feliz del proyecto? Entonces, el período de configuración inicial a menudo es exagerado por muchas personas porque están pensando en, bueno, pero si nos equivocamos aquí, nos quedaremos atascados y seguiremos iterando. Y tendremos que volver a esto. Y la verdad del asunto es que creo que GraphQL ha alcanzado un punto en el que es tan grande y popular que esperaríamos que esté muy maduro en este momento. Esperaríamos que no haya elecciones incorrectas. Pero en realidad, creo que GraphQL se ha desarrollado de manera un poco diferente a otras comunidades como la comunidad de React. Donde todo no gira realmente en torno a una sola biblioteca, sino que todo gira en torno a una sola especificación y una sola forma de hacer las cosas. Y eso significa que para bibliotecas y herramientas, tenemos muchas opciones diferentes para elegir. Y puedes perderte mucho si estás pensando en, bueno, ¿qué pasa si me equivoco? Porque la respuesta probablemente sea que en seis meses, lo que elijas ahora tal vez no sea la herramienta correcta para ti. Y debes estar dispuesto a aceptarlo. Debes estar dispuesto a decir, centrémonos en el resultado. La lógica empresarial que estoy escribiendo, en eso me estoy enfocando. ¿Cómo escribimos eso? Creo que el tipo de herramientas de GraphQL que debes elegir es probablemente la primera pregunta que debes resolver rápidamente. Sí, muy buenos puntos allí.

Creo que es muy fácil quedarse atrapado en esa parálisis del análisis y a veces simplemente tienes que optar por lo que es mejor para el problema que estás resolviendo en ese momento. Así que sí, muy buenos puntos.

Tenemos otra pregunta, probablemente la última a la que tendremos tiempo de responder. ¿Por qué decidió el equipo de Urkel dejar de dar soporte a ReScript? ¿Hay alguna respuesta o información al respecto? No he oído hablar de ReScript en bastante tiempo.

Entonces, la razón por la que el proyecto Urkel era mantenido por alguien en Formidable, eso era Parker, y Parker en algún momento, incluso antes que yo, dejó Formidable. Y en ese momento, ese proyecto básicamente estaba en modo de mantenimiento. Y ahora algunas partes principales de Urkel fueron escritas originalmente en Reason, que es una especie de biblioteca de mecanismo de transmisión. Recientemente lo migré a TypeScript también. Y hay dos razones para eso. La razón por la que nos deshicimos de ReScript/Reason y la biblioteca principal es que realmente no ha ganado suficiente tracción como para que suficientes personas puedan escribirlo. Y estaba frenando las contribuciones externas. Cuando cambiamos ese subrepositorio a TypeScript, inmediatamente volvimos a recibir contribuciones, lo cual es bastante sorprendente, casi en una semana. La otra parte es en términos de Reason en Urkel, no solo es Reason-ReScript un lenguaje separado, aunque se integra muy estrechamente con React, sigue siendo un lenguaje de programación separado. Así que estábamos viendo patrones completamente diferentes y mantener esos patrones completamente separados se estaba convirtiendo en una carga. Así que al final del día, dijimos, bueno, o bien podemos decir en el próximo año o meses, nos vamos a centrar en TypeScript y hacerlo realmente bien, o nos vamos a centrar menos en eso y expandirlo a más sectores. Pero dado que ya nos estamos enfocando en el soporte de múltiples bibliotecas de interfaz de usuario y tenemos un buen soporte de TypeScript, poner Reason-ReScript encima era un poco complicado.

De acuerdo, sí, eso tiene sentido. Muchas gracias por responder esa pregunta. Muy bien, solo nos queda un minuto. Muchas gracias por estar aquí con nosotros, Phil. ¿Hay algo más que te gustaría añadir antes de despedirnos? No estoy seguro. No estoy seguro de eso. Por eso esperaba que la encuesta fuera un poco más picante y un poco más controvertida. Bueno, si tienes alguna opinión picante para Phil, puedes encontrarlo en línea o ponerte en contacto con él para cualquier comentario constructivo. Pero muchas gracias por estar aquí, Phil, y por responder nuestras preguntas y por tu charla realmente interesante. Gracias por tenerme aquí.