Lista de deseos de GraphQL 2021: Las principales oportunidades y desafíos de GraphQL para 2021

Hola a todos, estoy muy contento de estar aquí. Soy Tanmay y voy a hablarles un poco sobre mi lista de deseos de GraphQL 2021. Estos son los resúmenes de algunos desafíos y, por supuesto, a través de esos desafíos, oportunidades que tenemos como comunidad frente a nosotros para construir más herramientas, hacer algunas especificaciones adicionales e intercambiar más ideas entre nosotros.

Para comenzar un poco, tal vez con una breve introducción. Soy Tanmay, soy el CEO y cofundador de Hasura, y gran parte de lo que les voy a hablar es lo que hemos aprendido de nuestra comunidad, de nuestros usuarios de la comunidad y los patrones que hemos visto de nuestros usuarios empresariales, especialmente. Y así, con eso, comencemos haciendo un rápido balance de dos cosas. Primero, dónde estamos con GraphQL hoy en día. La buena noticia es que estamos súper... GraphQL se ha vuelto cada vez más popular, lo cual es genial, pero la noticia un poco triste es que han pasado cinco años con GraphQL y aún no es realmente mainstream. Si pensamos en dónde, por ejemplo, Kubernetes o CNCF, que fue otra gran ola que ocurrió en el ecosistema recientemente, estaba en un nivel muy diferente en términos de adopción, interés e inversión empresarial en comparación con donde está GraphQL hoy en día. Y eso no necesariamente es algo malo, pero es algo interesante de notar que todavía hay ciertos puntos de inflexión que creo que necesitamos superar para que GraphQL se convierta en mainstream. Y espero que los desafíos y oportunidades de los que vamos a hablar nos ayuden a comprender eso un poco y ver si podemos construir cosas para resolver algunos de estos problemas y llevar GraphQL al mainstream en los próximos años como comunidad.

Entonces, las dos cosas o dos puntos de contexto que me gustaría agregar antes de adentrarnos en algunos de estos desafíos son la razón por la que a las personas les gusta GraphQL y los casos de uso no son homogéneos, ¿verdad? Las personas no están utilizando GraphQL y les gusta GraphQL por razones ligeramente diferentes. Y creo que es importante diferenciar entre estos dos. El primer caso de uso, y lo llamaré un caso de uso centrado en el cliente, es principalmente cuando usamos GraphQL para ayudar a las personas y ayudar a nuestros desarrolladores a construir mejores aplicaciones de interfaz de usuario, ¿verdad? Y aquí, lo que es atractivo de GraphQL a nivel técnico es que nos brinda la capacidad, o brinda al cliente y al servidor, un contrato y la capacidad de optimizar automáticamente la lógica de obtención de datos, ¿verdad? En lugar de depender, y este es el problema de las llamadas API REST n más uno, ¿verdad? En lugar de hacer muchas llamadas API REST para renderizar una página de interfaz de usuario en particular, puedes obtener eso desde la aplicación de manera dinámica en una sola consulta agrupada. Y GraphQL es una especificación para hacer eso, ¿verdad? Y aquí estamos pensando principalmente en GraphQL como una API más optimizada para obtener datos. Correcto. Y este es un problema nuevo que ha surgido cuando nos hemos movido hacia aplicaciones con una carga pesada en el cliente, ¿verdad? Esto no era un problema con aplicaciones renderizadas puramente en el servidor, como PHP o algo así en el pasado, donde gran parte de la obtención de datos que requería múltiples cantidades de datos para renderizar un componente de interfaz de usuario se hacía en el servidor que estaba renderizando la propia interfaz de usuario. Y luego esa interfaz de usuario se enviaba simplemente al cliente que iba a usarla, ¿verdad? Pero a medida que las cosas se vuelven más dinámicas, nos hemos dado cuenta de que hacer múltiples llamadas API debido a la red no es bueno. Y necesitamos una forma automática de transferir eso. Otra conveniencia similar en un problema técnico aquí es que JSON, que fue el formato de intercambio de datos que ha surgido en la última década, no tenía tipos y requería cierta tipificación, y GraphQL era una forma técnica más agradable de hacerlo, ¿verdad? Y así, esta es una razón muy técnica y cómo GraphQL nos está ayudando a construir mejores interfaces de usuario. Y aquí estás pensando en GraphQL simplemente de una manera muy abstracta, no completamente correcta, como una mejor manera de agrupar y tipar, ¿verdad? Eso es básicamente sin entrar en la ergonomía de GraphQL. Pero el segundo aspecto, y el segundo tipo de caso de uso y por qué a las personas les gusta GraphQL, es lo que llamo un caso de uso centrado en la plataforma, ¿verdad? Y aquí a las personas les gusta GraphQL como una especificación para impulsar una experiencia de API unificada, para decir que, en lugar de mirar mi servicio y tener 10 puntos finales, puedo tener un punto final y luego navegar por un gráfico de los modelos que esta API sirve. O si tengo múltiples servicios, tal vez pueda construir un agregador como un backend para el frontend a veces, o incluso un agregador de API interno que permita a los desarrolladores ver todos estos modelos juntos y sea más fácil consumir y explorar la API. Y esta es una gran parte del atractivo de GraphQL, que es esta facilidad de exploración y consumo, lo cual puede ser una afirmación ligeramente controvertida, pero que no tiene nada que ver con el beneficio técnico de optimización de rendimiento de GraphQL. Estos son casi dos aspectos independientes del caso de uso y por qué a uno le gusta GraphQL. Y, por supuesto, porque GraphQL es una API JSON, es una gran API para interactuar cuando tienes fuentes o servicios de datos heterogéneos, poder ver eso como un gráfico JSON unificado es genial. Es como una experiencia de MongoDB sobre todos tus datos a través de un tipo de API. Y esto no tiene mucho que ver con el beneficio técnico de GraphQL, que es la agrupación y la tipificación, que ayuda, por supuesto. La tipificación está en el medio de un beneficio técnico y una ergonomía.

Los fragmentos son fundamentales y las herramientas relacionadas con los fragmentos son fundamentales para automatizar el trabajo pesado de construir una interfaz de usuario que componga todos sus requisitos en una sola consulta y obtenga esos datos. Y aquí, nuevamente, tal vez una afirmación un poco controvertida, los fragmentos no son muy útiles para la reutilización. No es que esté particularmente emocionado de crear un archivo separado donde almaceno todas mis consultas y fragmentos de GraphQL y luego me refiero a esos fragmentos y los uso en mis componentes. Ese no es un caso de uso particularmente emocionante para mí en cuanto a los fragmentos. Prefiero simplemente especificar la consulta junto a mi componente. Prefiero colocar los requisitos de obtención de datos dentro de mi componente de interfaz de usuario como desarrollador. En lugar de tocar 10 archivos diferentes, prefiero tocar el archivo de mi componente. Y en este caso, lo que los fragmentos realmente nos permiten hacer es, como desarrollador que trabaja en un componente de interfaz de usuario en particular, puedo trabajar en un solo componente y puedo especificar mis requisitos de datos como un fragmento. Y varias personas pueden trabajar en diferentes componentes, especificando sus requisitos como un fragmento, que se fusionarán automáticamente. La belleza de este enfoque es que debe suceder automáticamente. Si esto se hace manualmente en el sentido de que escribo un fragmento aquí, luego tengo que importar el fragmento en otro lugar. Y luego tengo que especificar que, hey, estoy usando este fragmento. Tengo que ir al componente de nivel superior y especificar mi consulta de nivel superior que está usando un fragmento en algún lugar. No es una gran experiencia. Y se pierde el beneficio de usar GraphQL para automatizar esta composición de consultas de datos. Ahora, Relay ha hecho un trabajo fabuloso al tomar estos varios conceptos que se requieren para componer lógica de obtención de datos automáticamente. Y las herramientas que se requieren para tratar automáticamente con fragmentos, ¿verdad? Sin tener que hacer el trabajo manual de escribir fragmentos, tal vez en un archivo separado o importarlos y reutilizarlos y demás. Pero desafortunadamente, esta idea no ha surgido de los clientes de Relay, porque el compilador de Relay también es un poco complicado. Pero tomar ese compilador de Relay y usarlo para construir otros clientes de GraphQL es algo que debemos hacer más. Creo que hay algunos trabajos interesantes que se están realizando aquí con algunos de los clientes. Creo que si no me equivoco, el cliente de Angular. Pero hay muchas ideas interesantes aquí que debemos llevar más allá del ecosistema de React hacia otros ecosistemas de interfaz de usuario también. Alternativamente, hay mucho amor que debemos dar a la documentación de Relay y ponerla al día para que ese cliente sea más utilizable y accesible, ¿verdad? Curiosamente, están surgiendo otros enfoques para resolver un problema similar en torno a la obtención de datos y optimizar la obtención de datos automáticamente, ¿verdad? SWR, que es Stale-while-revalidator, el nombre de un concepto pero también el nombre de una biblioteca o herramienta que construyeron las personas de Versal, y Vulkane, que es otro enfoque que utiliza HTTP2, son enfoques muy interesantes que permiten una idea similar de permitir a los desarrolladores de interfaz de usuario construir sus componentes de interfaz de usuario, especificando su llamada a la API que obtiene datos, pero luego automatizando parte de esa lógica de obtención de datos sin que los desarrolladores tengan que hacer demasiado trabajo para componer eso y hacerlo lo más eficiente posible, ¿verdad? Y así, hay enfoques interesantes no basados en GraphQL que también pueden tener cierta superposición con GraphQL. Y lo interesante de estos enfoques es que, como no dependen de GraphQL, no tienen que agregar ninguna de esa complejidad de GraphQL. Y así, esta es un área de trabajo en la que estoy particularmente emocionado y espero que haya más cosas que sucedan en los próximos meses.

Recientemente hice una charla en React Summit hace unos meses hablando sobre esta idea de relay y fragmentos, lo cual fue mi viaje para comprender un enfoque fragmentado basado en relay, y realmente me sorprendió. Si estás interesado en este tema, vale la pena verlo. Sean y Gabriel han creado una excelente serie de publicaciones en el blog y una introducción a relay, que también vale la pena leer y comprender estas ideas que hacen que relay, y especialmente algunas de las herramientas basadas en fragmentos, sean increíbles.

Además, las bibliotecas Vulkan y SW también valen la pena revisar y comprender.

El siguiente problema del que me gustaría hablar es tener clientes nativos de GraphQL más allá de los frameworks de UI. Este es, nuevamente, un enfoque ligeramente más centrado en la plataforma del que estoy hablando, donde tienes esta API y no necesariamente la vas a utilizar en una UI, puedes utilizarla en una UI, puedes utilizarla en una aplicación de escritorio, puedes utilizarla en un servicio. Creo que eso es algo genial de REST, que no había un estándar muy específico que todos siguieran cuando las personas construían puntos finales de REST. Hay un estándar muy específico, pero las personas son bastante flexibles con él, y es muy flexible y las personas hacen muchas cosas. Y eso facilitó la integración de REST. Hay muchas opciones para integrar la API REST con lo que estabas construyendo, ya sea una UI o un servicio o cualquier otra cosa, ¿verdad? GraphQL hoy en día está extremadamente optimizado para la UI, pero hacer que una API de GraphQL sea utilizable en frameworks que no sean de UI también tiene una gran ventaja porque reduce el riesgo para las personas que están construyendo estos servicios, ¿verdad? Alguien como un desarrollador que construye un servicio. Si tengo que construir un servicio de GraphQL y un servicio de REST, no es divertido, ¿verdad? Y eso es uno de esos grandes riesgos, que si construyo una API completa de GraphQL y mañana otros clientes necesitan una API REST, ¿verdad? Otros desarrolladores u otros equipos u otras aplicaciones, ¿entonces mantenemos ambas APIs? Y eso es mucho trabajo, ¿verdad? Porque parece que en la conversación de GraphQL versus REST, va a ser más de GraphQL y REST en lugar de GraphQL versus REST, ¿verdad? Y por lo tanto, una de las cosas críticas que se requieren para que eso suceda es un poco más de trabajo en las herramientas del cliente de GraphQL, ¿verdad? Y creo que uno de los desafíos aquí es que las APIs de GraphQL no son necesariamente fáciles de consumir e integrar porque son demasiado flexibles. Esto no es algo malo desde el punto de vista de un desarrollador, pero tal vez desde el punto de vista de la integración y la pila tecnológica, es un poco desafiante.

Un lugar donde esto se hace evidente es cuando intentas generar tipos de código, ¿verdad? Si tienes una consulta diferente que obtiene diferentes fragmentos del mismo tipo base, podrías tener un nuevo tipo para cada consulta, ¿verdad? Y luego tienes una explosión de tipos en la aplicación, lo cual no es necesariamente un problema, pero podría resultar en algunos problemas. Rob Zoo habló sobre, ya sabes, una especie de magia avanzada del cliente de GraphQL que tuvieron que hacer en la aplicación de Java Android para no activar una recolección de basura excesiva, ¿verdad? Y así, cuando pensamos en traer estas ideas de un mejor cliente de GraphQL, que tiene menos y menos explosión de tipos para cada tipo de consulta que haces, o una experiencia de consumo más optimizada, creo que eso será fundamental para ayudar a que la adopción de GraphQL sea más fluida para los desarrolladores, sin importar lo que estén construyendo.

Dos de los enfoques que me emocionan aquí son, por supuesto, el gran trabajo que están haciendo las personas del generador de código de GraphQL en la comunidad, pero también enfoques como Juke en el mundo de SQL que proporcionan una abstracción nativa a SQL en lugar de una abstracción basada en objetos para entidades de datos. Y creo que GQLs de Sam Denty es otra idea y enfoque muy interesante que creo que Sam comenzó este año, que permite una experiencia de consumo más nativa para GraphQL. Por supuesto, la mayoría de esto está sucediendo en la comunidad de TypeScript y JavaScript, sería interesante ver este movimiento más allá de la comunidad de TypeScript y JavaScript.

Bien, el siguiente desafío es superar la brecha entre las herramientas de GraphQL y REST. Lo interesante de las APIs REST y todo el ecosistema de APIs REST es la inmensa cantidad de herramientas, herramientas de infraestructura, herramientas de proveedores en las que se ha invertido para ayudar a las personas a operar y lidiar con la introducción de APIs REST, ¿verdad? Específicamente, el monitoreo de la calidad del servicio y los controles de salud, ¿verdad? Por lo que puedes utilizar una herramienta de proveedor sin tocar tu pila tecnológica. Simplemente puedes integrar, agregar una herramienta de proveedor que comenzará a brindarte una página de estado o una página de salud que te indique cuál es la calidad de tu API, ¿verdad? Qué está fallando con códigos de estado 5xx, 4xx, cosas así, ¿verdad? Puedes configurar alertas y monitoreo bastante fácilmente, nuevamente sin hacer demasiado trabajo. Al utilizar esta herramienta de proveedor o una herramienta de infraestructura sin afectar demasiado tu trabajo, tu lógica de aplicación o tu servidor de aplicaciones, ¿verdad?

Aquí el problema con GraphQL y una de esas cosas para las que aún no creo que tengamos una buena solución es que GraphQL devuelve errores dentro del cuerpo de la respuesta, no en los códigos de estado, ¿verdad? De hecho, pueden ser errores parciales, ¿verdad? Y no hay noción de errores parciales en un código de estado. Esto significa que la herramienta que estamos utilizando para monitorear la calidad del servicio, informar errores o enviar alertas debe buscar dentro del cuerpo de la respuesta para comprender si hay un error o no. Esto es un desafío porque el cuerpo de la respuesta es información muy crítica y privada. No quieres tomar esos datos y enviarlos a una herramienta de terceros para su análisis, ¿verdad? Porque eso es esencialmente como datos de API privados muy sensibles, ¿verdad? Y por lo tanto, hay desafíos aquí para poder superar eso. Por supuesto, el almacenamiento en caché en el lado del servidor es un problema del que hemos estado hablando desde los inicios de GraphQL en cuanto a poder aprovechar los diversos puntos de red que existen entre un servidor y un cliente, ¿verdad? Todo, desde una CDN hasta los balanceadores de carga hasta los servidores en el medio que se asegurarán de que podamos realizar algún tipo de almacenamiento en caché en el lado del servidor, ¿verdad? E indicar a estos diversos puntos de red en el medio qué política de almacenamiento en caché queremos. Una idea interesante podría ser tener algún tipo de mapeo automatizado legible por humanos de GraphQL a REST, ¿verdad? Debe ser automatizado para que, como desarrolladores que construimos o utilizamos la API de GraphQL, casi no nos preocupemos por eso, ¿verdad? Debe haber suficiente, es casi similar a una idea de consultas persistidas, pero llevada un poco más lejos. Y tal vez se vea algo así, ¿verdad? Donde dices que tienes una consulta, parametrizas las variables y luego la conviertes en un punto final REST idiomático. Para que en producción, en realidad solo estés utilizando estos puntos finales REST idiomáticos y todo sobre tus herramientas funcione, pero durante el desarrollo, puedes aprovechar todas las ventajas de GraphQL, ¿verdad? Algo similar a esta idea también es utilizar GraphQL como una representación intermedia y no como una API final. Y esto realmente tiene un atractivo centrado en la plataforma, que dice que a las personas realmente les gusta explorar las APIs de GraphQL y GraphQL, ¿verdad? Si se trata de utilizar esas APIs de GraphQL en sus aplicaciones, debido a todos los desafíos de los que hablamos, ¿verdad? O si es un servicio, no lo están consumiendo dentro de una aplicación o una UI. Encogimiento de hombros emoji, ¿verdad? Básicamente, a las personas no les emociona cambiar la forma en que piensan acerca de sus clientes de API en lo que están construyendo para usar GraphQL.

Entonces, aquí, ¿existe alguna forma de obtener los beneficios de GraphQL a partir de la exploración, herramientas, documentación, navegación, obtener esa porción correcta de datos, ¿verdad? Todos esos beneficios, sin tener que cambiar la forma en que funcionan nuestros clientes de API. Relacionado con esa idea anterior, ¿podríamos usar GraphQL como un paso intermedio en el ciclo de vida de nuestra API, ¿verdad? Podemos decir, como desarrollador, quiero consumir una API en particular. Entonces, entro en GraphiQL, pruebo cualquier consulta de GraphQL que desee. Luego envío mi consulta de GraphQL y digo, esta es la API que quiero. Luego pasa por una revisión, ya sea automatizada o humana o lo que sea, ¿verdad? Tal vez una verificación de rendimiento o cualquier verificación que desee hacer. Y luego, durante el desarrollo, obtengo un punto final REST o gRPC o cualquier otro punto final para el que tengamos todas las herramientas configuradas, ¿verdad? Aquí podemos obtener el catálogo de metadatos, los beneficios del diccionario de datos y los beneficios de exploración de la API de GraphQL. Pero sin tener que obligar a nuestros usuarios a utilizar la introducción de GraphQL, para que tengan que reinventar esas herramientas, ¿verdad? Es algo similar a la idea anterior.

El siguiente problema del que me gustaría hablar aquí es cuando pensamos en varios servicios de GraphQL que queremos unir, hay algunos desafíos interesantes. Imagina, por ejemplo, si tienes múltiples esquemas de relay, ¿verdad? Y quieres, por ejemplo, tienes esta puerta de enlace de GraphQL o algún tipo de agregador que delega en los esquemas, pero los esquemas no son solo esquemas de GraphQL, son esquemas de relay, lo que significa que todos ellos, por ejemplo, van a tener un campo de nodo, ¿verdad? Y van a prevenir un campo de nodo. Ahora, cuando intentas agregarlos, no puedes simplemente juntar estos esquemas y ponerlos en un tipo, ¿verdad? No puedes agregarles un prefijo o un espacio de nombres porque eso no tiene sentido, ¿verdad? El campo de nodo tiene cierta semántica asociada, el campo de ID que cada tipo tendría también tiene cierta semántica asociada, y agregar un espacio de nombres o un prefijo o simplemente juntarlo todo en una API no es útil. Entonces, lo que realmente queremos hacer es que los servicios intercambien más información. Digamos, por ejemplo, en nuestra organización, hemos creado ciertos estándares comunes, estas interfaces similares a la interfaz de nodo que queremos usar. ¿Cómo intercambiamos esta información entre nosotros y en la puerta de enlace, ¿verdad? Y aumentamos ese resultado de introspección, tal vez sean cosas adicionales en el SDL y cosas adicionales en los directores del SDL o una API separada o lo que sea. Pero este es esencialmente el trabajo que tenemos que hacer, que básicamente estás delegando a estos otros servicios y tienes que volver a implementar el campo de nodo como un resolvedor de GraphQL en esa capa de agregación de GraphQL, ¿verdad? Y luego eso se delega al campo de nodo en estos servicios ascendentes, ¿verdad? Y luego tienes que asegurarte de que puedes manipular los datos, la respuesta de ID, ¿verdad? Cada identificador debe cambiarse en el nivel del agregador para que el identificador tenga la indicación de qué servicio proviene para poder delegarlo adecuadamente, ¿verdad?

Creo que las dos últimas ideas rápidas que cubriré, y estas son dos ideas cortas, son la idea de un esquema basado en roles, que creo que es particularmente atractiva, especialmente en grandes empresas. Uno de los problemas aquí es que suena muy bien decir, ¿y si todas nuestras API fueran una única API universal y centralizada de GraphQL? Suena bien, pero podría no ser tan bueno si tienes 20,000 puntos finales o recursos de API, ¿verdad? Porque entonces es demasiado. Y lo que realmente quieres hacer es que cuando ingreso a GraphiQL, no quiero ver tantas API, ¿verdad? Digamos que es una situación de comercio electrónico, tengo una API separada para el comerciante, una API para el consumidor y una API para operaciones, ¿verdad? Las operaciones son internas de la organización, por ejemplo. En estos casos, no quiero que las personas del comerciante vean ni siquiera la API del consumidor, ¿verdad? Ni siquiera quiero que intenten hacer consultas, intentar molestar poniendo un token y obtener un resultado nulo. Ni siquiera quiero que vean esa parte del esquema, ¿verdad? Entonces, aquí, esta idea de vincular esa autorización o la identidad del consumidor al esquema que estás obteniendo, ¿verdad? Donde es algo dinámico, no es un esquema incorporado que tenías en el momento de la compilación, sino un esquema dinámico que refleja al usuario que lo está utilizando, es muy útil y hace que el consumo de GraphQL en estilo de plataforma sea muy conveniente. Lo último de lo que quiero hablar, que realmente es un conjunto de cosas a tener en cuenta, es que a medida que WebSockets y HTTP2 y HTTP3 maduran, hay algunas cosas interesantes que debemos hacer como comunidad. Seguir empujando GraphQL y asegurarnos de que la especificación de GraphQL o las especificaciones para formas particulares de usar GraphQL, tal vez no la especificación principal en sí, también evolucionen continuamente. Y especialmente con AdDef o AdStream que se agregan como características experimentales a la especificación de GraphQL. Integrar eso con WebSockets, hoy en día, por ejemplo, funciona con multipart form en HTTP1, pero integrarlo con WebSockets y luego HTTP2 server push o HTTP3 server push también será bastante interesante. Y aquí habrá algunos desafíos en la forma en que manejamos las cargas de trabajo con estado porque esencialmente estas... Esencialmente, cuando estamos haciendo más de estas transmisiones de desarrollo o estilo de empuje sobre protocolos más nuevos y estilos más nuevos que podrían ser más eficientes, estas cargas de trabajo tienen estado en el sentido de que, ya sabes, si alguien se suscribe a algo, no pueden cambiar repentinamente a un servidor diferente que esté sirviendo esas suscripciones, ¿verdad? Y por lo tanto, hay un poco de trabajo que debe hacerse en el backend en sí mismo en cómo podemos manejar estas cosas, especialmente desde el punto de vista del equilibrio de carga, la escalabilidad y la seguridad. Y por lo tanto, estas son algunas cosas interesantes que están sucediendo. Todavía son muy experimentales y muy nuevas, pero hay algunas cosas interesantes que están sucediendo y que son útiles y será bueno seguir evolucionando GraphQL en esa dirección también.

De acuerdo, lamento un poco haberme pasado de tiempo y con eso, terminaré esto. No dudes en comunicarte conmigo, hablar un poco más sobre esto y emocionado de seguir interactuando con ustedes, hablar sobre estos desafíos, aprender sobre otros desafíos que enfrentan. Soy Tanmay Go en Twitter, no dudes en comunicarte y, por supuesto, pondré a disposición las diapositivas y los recursos para que también puedas consultarlos.

Gracias por recibirme. Hola a todos, gracias Fish. Bien, bien, bien, bien. Espero que todos estén bien. Sí, esa fue una charla increíble, por cierto. Muchas gracias.

Entonces, ¿qué piensan de los resultados de la encuesta? ¿Era lo esperado? Esa era mi intuición. Mi intuición era que más personas iban a votar por GraphQL para la integración y adopción de API y la experiencia de herramientas de la comunidad. Y menos por el beneficio teórico de GraphQL, la diferencia de rendimiento N más uno y la seguridad de tipos, que fue una gran parte del diseño original de GraphQL y por qué se construyó, ¿verdad? Así que es muy interesante ver esa diferencia y creo que eso es en parte lo que impulsa la importancia de GraphQL para la integración y adopción de API, que es uno de los problemas principales que mencioné anteriormente, porque creo que hay una cantidad tremenda de trabajo que aún debemos hacer para que GraphQL sea fácil y más común.

Definitivamente. Y creo que esa fue una gran pregunta para comenzar la charla. Así que fue realmente interesante descubrirlo. También tenemos una pregunta de Discord y un pequeño amigo la dejó para que te la haga. Entonces, la pregunta de Bosjan es: cuando la mitad del mundo esté utilizando GraphQL, ¿cuáles son los desafíos que predices? ¿Cuándo uniremos varios gráficos? Sí, esa también es una buena pregunta. Hola Bosjan. Creo que, sí, creo que nunca habrá un mundo donde todo sea GraphQL, desafortunadamente, ¿verdad? Por lo tanto, habrá un porcentaje de cosas que se muevan a GraphQL. Lo digo con todo el amor por GraphQL. Así que no creo que eso vaya a suceder, pero será interesante ver cómo surgen esos casos de uso, ¿verdad?

Creo que hay dos casos amplios que veo en los que las personas quieren unir, en cierto modo, gráficos, ¿verdad? Uno es este nivel inicial de problema con el que muchos de nosotros estamos lidiando, que es que tenemos muchos puntos finales de API diferentes y tenemos que construir interfaces de usuario, y es una gran molestia tener que mirar todos esos puntos finales diferentes y combinarlos en la interfaz de usuario o en alguna interacción entre la interfaz de usuario y el backend para crear una especificación de API, y cosas así, ¿verdad? Ese es un caso de uso en el que tal vez no necesariamente estamos uniendo gráficos, pero tal vez estamos creando un modelo común de GraphQL o una puerta de enlace o una capa de agregación, que es esencialmente una mejor versión de una API por lotes o una puerta de enlace de API, ¿verdad? Es como una versión dos de eso, es una puerta de enlace de API programable, tal vez. Y ese es un caso de uso que está surgiendo, ¿verdad? Y lo interesante es que también hay muchas aproximaciones alternativas a esa parte del problema. Muchas personas piensan, sabes qué, deja que los microservicios y la explosión de puntos finales de API ocurran, encontraremos una forma diferente de solucionar ese problema, y Vulkan del que hablé es una gran forma, un gran enfoque en ese sentido. Pero la otra forma de unir gráficos y datos, creo que no solo está en la comunidad de la interfaz de usuario a la que la mayoría de nosotros pertenecemos, sino también en la comunidad de API y datos, ¿verdad?, que son las personas que están, tal vez dentro de una gran empresa, tienen varias líneas de negocio, ¿verdad?, tienen, o incluso en una startup, ¿verdad?, tienen personas haciendo todo tipo de cosas, ¿verdad?, no todos están necesariamente construyendo la aplicación, que tal vez sea una gran parte del negocio, pero también hay muchas otras cosas sucediendo. Y para muchos de ellos, necesitan esta capacidad de decir, bueno, aquí está mi núcleo de datos, y aquí hay algunos datos adicionales, aquí hay algunos datos en mi servicio SAS, aquí hay algunos datos aquí, y quiero tener un modelo JSON común en todos ellos, ¿verdad?, y creo que poder cumplir con ese caso de uso, eso es cuando vamos a ver muchas cosas interesantes, vamos a ver otra ronda de interés por GraphQL, o por algo similar a GraphQL, para decir, unamos esos gráficos, ¿verdad?, así que creo que dependerá del caso de uso. Definitivamente creo que tenemos que cerrar la brecha entre GraphQL y los servicios y herramientas de API existentes para que eso suceda con éxito, así que veamos cómo resulta.

Sí, definitivamente, hay mucha emoción en torno a las capas de acceso de datos unificadas de GraphQL.

Creo que eso es algo que todos esperan con ansias y están realmente emocionados de ver. Sí, sí, sí, y déjame agregar una nota de precaución allí, de la que hablé en el panel de discusión de ayer, ¿verdad?, como la idea de unificar un gráfico suena muy atractiva, pero debes asegurarte de unificarlo por las razones correctas, ¿verdad?, como por ejemplo en una empresa grande, no quieres tener un gráfico unificado de todo tu ecosistema de API, ¿verdad?, porque te volverías loco, miras el millón de APIs y piensas, no quiero esto, solo quiero esos tres puntos finales de API, ¿verdad? Solo necesito hacer estas tres cosas. No quiero ver todas estas millones de cosas interconectadas porque solo me interesan esas tres cosas. Así que creo que el caso de uso para unificar el gráfico va a ser, o como, o unificar datos, ¿verdad?, si has comenzado a nivelar más, creo que será muy interesante de ver. Absolutamente, sí, tiene mucho sentido. Además, Tanmay, mencionaste que aprendiste mucho de GraphQL, quiero decir, mucho sobre la adopción de GraphQL de la comunidad de usuarios de Hasura y tus clientes empresariales. Entonces, en tu opinión, ¿cuál es la parte más fácil y la más difícil, bueno, convencer no es la mejor palabra, pero demostrar la magia de GraphQL que brinda a los usuarios más confianza para adoptarlo? Creo que la parte de la adopción, creo que la parte de la adopción de GraphQL es realmente, es la razón por la que todos hablamos de GraphQL, ¿verdad? Esa adopción inicial es realmente fácil, ¿verdad? Puedes hablar de GraphQL, puedes decir esto, puedes decir aquello, pero al final cuando miras GraphQL y miras como, ya sabes, ser capaz de, esa experiencia de juntar cosas, ¿verdad? Y lo que la gente votó, el 78% de las API votaron por una experiencia de integración. Sabes, eso gana corazones y mentes muy rápidamente, ¿verdad? Los desafíos en torno a GraphQL son básicamente el día dos de GraphQL, ¿verdad? Que es como, oh Dios mío, el resto de mi stack no funciona con GraphQL. Nada funciona. La seguridad no funciona, el monitoreo no funciona, ¿verdad? Como todas las herramientas existentes, tenemos que reconstruirlas. Necesitamos un equipo enorme para reconstruirlas, ¿verdad? Y de repente te das cuenta de que estás empezando a resolver un montón de problemas que ni siquiera son importantes para tu negocio. Y creo que esa es una de esas partes arriesgadas, esa es la parte donde muchos, especialmente los usuarios empresariales, se preocupan mucho, ¿verdad? Y es muy arriesgado porque legítimamente es muy arriesgado, ¿verdad? Si estoy en el negocio de hacer algo, de hacer X, GraphQL no es mi negocio, ¿verdad? No quiero arruinar todo este enorme equipo de exportación de GraphQL y preocuparme por la adopción de GraphQL, ¿verdad? Y qué pasa si en cinco años, GraphQL cambia o GraphQL ya no existe o surge un nuevo GraphQL, ¿verdad? Así que es muy difícil. Y eso, creo, es uno de esos aspectos arriesgados. Pero no creo que haya, creo que los problemas del día cero los estamos resolviendo muy bien como comunidad, ¿verdad? Y hay muchas herramientas excelentes que están surgiendo para ayudar con los problemas iniciales o del día cero. Y luego creo que los problemas del segundo día, ¿verdad? Ahí es donde surgen algunas de las objeciones y objeciones muy legítimas, ¿verdad? No es que las personas sean estúpidas o algo así. Es solo que tienen objeciones muy legítimas, eso es lo que espero que podamos solucionar un poco en 2021 como comunidad. Absolutamente, esa fue una respuesta maravillosa. Muchas gracias Tanmay por esta sesión de preguntas y respuestas realmente interesante. Y nuevamente, tus charlas fueron realmente geniales. Así que muchas gracias por dedicarnos tu tiempo. Gracias Shashank. Gracias por tenerme, a todos. Me uniré al chat especial. Así que nos vemos allí y nos vemos en Discord. Muy bien, adiós. Gracias. Gracias. Gracias. Gracias. Gracias.