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

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

A medida que GraphQL entra en su sexto año, hemos avanzado mucho como comunidad y ecosistema. Pero aún queda mucho trabajo por hacer para que GraphQL se vuelva completamente popular y mantenga su impulso. En esta charla, destacaré los principales desafíos técnicos y de herramientas que enfrentan los profesionales al adoptar GraphQL y espero generar nuevas ideas y discusiones sobre lo que necesitamos especificar, construir y mejorar.

Estoy emocionado de compartir una lista de oportunidades e ideas que abarcan a) las cosas aburridas que deben hacerse (por ejemplo, ¡verificación de salud y manejo de errores!), b) los problemas difíciles que deben resolverse (por ejemplo, límites de velocidad y seguridad) y c) los desafíos emocionantes (por ejemplo, GraphQL y wasm) que enfrentamos como comunidad de GraphQL.

Espero que al final de la charla tengamos una idea clara de cuáles son los principales desafíos y por qué, y que estemos entusiasmados por discutir estos desafíos y construir posibles soluciones en 2021.

This talk has been presented at GraphQL Galaxy 2020, check out the latest edition of this Tech Conference.

FAQ

Tanmay es el CEO y cofundador de Hasura, y ha compartido su experiencia y los patrones observados en la comunidad y usuarios empresariales de GraphQL.

Tanmay menciona que aunque GraphQL se ha vuelto más popular, todavía no es completamente mainstream comparado con otras tecnologías como Kubernetes.

Las personas aprecian GraphQL por diferentes razones; algunos valoran su capacidad para optimizar la obtención de datos en aplicaciones con interfaces de usuario pesadas, mientras que otros lo prefieren para crear APIs unificadas y explorables.

Uno de los desafíos es la falta de herramientas eficientes para manejar fragmentos de GraphQL, lo que es fundamental para mejorar la obtención automática de datos en interfaces de usuario.

Tanmay sugiere trabajar en mejores clientes de GraphQL para otros frameworks fuera de React, mejorar la documentación de Relay y explorar nuevas herramientas y enfoques como SWR y Vulkan.

Los fragmentos son cruciales para definir requerimientos de datos específicos de componentes en una aplicación, permitiendo una composición automática de consultas que mejora la eficiencia.

Tanmay indica que el monitoreo en GraphQL es complicado porque los errores se reportan dentro del cuerpo de la respuesta en vez de en los códigos de estado, lo que requiere herramientas especializadas para su manejo.

Tanmai Gopal
Tanmai Gopal
35 min
02 Jul, 2021

Comments

Sign in or register to post your comment.
Video Summary and Transcription
GraphQL aún no ha alcanzado la adopción generalizada y todavía hay puntos de inflexión que superar. Los fragmentos en los clientes de GraphQL necesitan mejoras, y enfoques no GraphQL como SWR y Vulkane ofrecen alternativas para automatizar la obtención de datos. Los clientes de GraphQL más allá de los marcos de UI presentan desafíos, pero herramientas como el generador de código GraphQL y Juke ofrecen soluciones. El uso de GraphQL como una representación intermedia y la conexión entre GraphQL y REST son conceptos atractivos. Unir gráficos y datos en diferentes casos de uso es un desafío, pero están surgiendo soluciones como un modelo GraphQL común o una puerta de enlace de API programable. No es necesario unificar todo el ecosistema de API en grandes empresas, enfocarse en puntos finales de API específicos puede ser más beneficioso.

1. Introducción a GraphQL y sus casos de uso

Short description:

Hola a todos, soy Tanmay, el CEO y cofundador de Hasura. Comencemos por entender dónde estamos con GraphQL hoy en día. Aunque GraphQL se ha vuelto más popular, aún no ha alcanzado la adopción generalizada. Todavía hay ciertos puntos de inflexión que debemos superar. A las personas les gusta GraphQL por diferentes razones, como optimizar la lógica de obtención de datos para aplicaciones de interfaz de usuario y brindar una experiencia de API unificada. GraphQL proporciona una mejor manera de agrupar y tipar datos, lo que lo hace ideal para aplicaciones con una carga pesada en el cliente. También ofrece facilidad de exploración y consumo, lo que permite a los desarrolladores ver múltiples modelos juntos. Estos aspectos hacen de GraphQL una herramienta poderosa para interactuar con fuentes o servicios de datos heterogéneos.

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.

2. Desafíos en los clientes de GraphQL y fragmentos

Short description:

Los fragmentos son fundamentales para automatizar la obtención de datos en los clientes de GraphQL, pero las herramientas relacionadas con los fragmentos necesitan mejoras. Es tedioso escribir e importar fragmentos manualmente, y dificulta la composición automática de consultas de datos. El compilador de Relay ha avanzado en la automatización del manejo de fragmentos, pero este concepto debería extenderse a otros clientes de GraphQL. Además, enfoques como SWR y Vulkane ofrecen alternativas interesantes para automatizar la obtención de datos sin la complejidad de GraphQL. Estos enfoques no basados en GraphQL tienen el potencial de optimizar la obtención de datos y hacerla más eficiente.

beneficio también. Pero estas son más o menos las dos perspectivas desde las cuales podemos pensar en la forma en que GraphQL está siendo adoptado, utilizado y amado por las personas cuando usan GraphQL. Y así, cuando pensamos en los desafíos en los próximos minutos, mantengamos en mente estos dos tipos de casos de uso. El primero es el de los clientes de GraphQL y los fragmentos, que es principalmente un caso de uso centrado en el cliente. Y aquí, el desafío es que cuando pensamos en ir más allá de la conveniencia de GraphQL y realmente optimizar y automatizar la obtención de datos de alto rendimiento, es realmente difícil hacerlo sin una buena herramienta basada en fragmentos.

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.

3. Desafíos en los clientes de GraphQL y herramientas

Short description:

Recientemente hice una charla en React Summit sobre relay y fragmentos, lo cual fue un viaje asombroso para mí. Los clientes nativos de GraphQL más allá de los frameworks de UI presentan un desafío, ya que GraphQL está actualmente optimizado para el uso en UI. La flexibilidad de las APIs de GraphQL puede dificultar su consumo e integración, especialmente en cuanto a la generación de código y la explosión de tipos. En el mundo de SQL, enfoques emocionantes como el generador de código de GraphQL y Juke ofrecen soluciones. Superar la brecha entre las herramientas de GraphQL y REST es otro desafío, ya que GraphQL devuelve errores en el cuerpo de la respuesta, no en los códigos de estado. El almacenamiento en caché en el lado del servidor y la asignación automatizada de GraphQL a REST son soluciones potenciales. Utilizar GraphQL como una representación intermedia y no como una API final también es un concepto atractivo.

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.

4. Explorando los beneficios y desafíos de GraphQL

Short description:

¿Existe alguna forma de obtener los beneficios de GraphQL sin cambiar los clientes de API? ¿Se puede utilizar GraphQL como un paso intermedio en el ciclo de vida de la API? La unión de múltiples servicios de GraphQL presenta desafíos. ¿Cómo pueden los servicios intercambiar información y manejar la manipulación de datos? Los esquemas basados en roles y los esquemas dinámicos basados en la identidad del usuario son atractivos. A medida que WebSockets y HTTP2/HTTP3 maduran, surgen oportunidades para la integración de GraphQL. El manejo de cargas de trabajo con estado y garantizar el equilibrio de carga, la escalabilidad y la seguridad son consideraciones importantes.

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.

5. Desafíos en la unión de gráficos y datos

Short description:

Gracias por recibirme. Los resultados de la encuesta fueron interesantes, con más personas votando por GraphQL para la integración y adopción de API. Sin embargo, todavía hay mucho trabajo por hacer para que GraphQL sea fácil y común. Unir gráficos y datos en diferentes casos de uso es un desafío, pero existen soluciones emergentes como crear un modelo común de GraphQL o una puerta de enlace de API programable. Es crucial establecer un puente entre GraphQL y los servicios y herramientas de API existentes para una integración exitosa. La emoción en torno a las capas de acceso de datos unificadas de GraphQL está creciendo.

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.

6. Precaución sobre la unificación de gráficos en grandes empresas

Short description:

La idea de unificar gráficos suena atractiva, pero es importante unificarlos por las razones correctas. En grandes empresas, puede que no sea necesario o práctico unificar todo el ecosistema de API. Enfocarse en puntos finales de API específicos y los datos que proporcionan puede ser más beneficioso.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

De GraphQL Zero a GraphQL Hero con RedwoodJS
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
De GraphQL Zero a GraphQL Hero con RedwoodJS
Top Content
Tom Pressenwurter introduces Redwood.js, a full stack app framework for building GraphQL APIs easily and maintainably. He demonstrates a Redwood.js application with a React-based front end and a Node.js API. Redwood.js offers a simplified folder structure and schema for organizing the application. It provides easy data manipulation and CRUD operations through GraphQL functions. Redwood.js allows for easy implementation of new queries and directives, including authentication and limiting access to data. It is a stable and production-ready framework that integrates well with other front-end technologies.
Estado Local y Caché del Servidor: Encontrando un Equilibrio
Vue.js London Live 2021Vue.js London Live 2021
24 min
Estado Local y Caché del Servidor: Encontrando un Equilibrio
Top Content
This Talk discusses handling local state in software development, particularly when dealing with asynchronous behavior and API requests. It explores the challenges of managing global state and the need for actions when handling server data. The Talk also highlights the issue of fetching data not in Vuex and the challenges of keeping data up-to-date in Vuex. It mentions alternative tools like Apollo Client and React Query for handling local state. The Talk concludes with a discussion on GitLab going public and the celebration that followed.
Baterías Incluidas Reimaginadas - El Resurgimiento de GraphQL Yoga
GraphQL Galaxy 2021GraphQL Galaxy 2021
33 min
Baterías Incluidas Reimaginadas - El Resurgimiento de GraphQL Yoga
Envelope is a powerful GraphQL plugin system that simplifies server development and allows for powerful plugin integration. It provides conformity for large corporations with multiple GraphQL servers and can be used with various frameworks. Envelope acts as the Babel of GraphQL, allowing the use of non-spec features. The Guild offers GraphQL Hive, a service similar to Apollo Studio, and encourages collaboration with other frameworks and languages.
Aplicaciones sólidas de React y GraphQL para personas con prisa
GraphQL Galaxy 2022GraphQL Galaxy 2022
29 min
Aplicaciones sólidas de React y GraphQL para personas con prisa
The Talk discusses the challenges and advancements in using GraphQL and React together. It introduces RedwoodJS, a framework that simplifies frontend-backend integration and provides features like code generation, scaffolding, and authentication. The Talk demonstrates how to set up a Redwood project, generate layouts and models, and perform CRUD operations. Redwood automates many GraphQL parts and provides an easy way for developers to get started with GraphQL. It also highlights the benefits of Redwood and suggests checking out RedwoodJS.com for more information.
Adoptando GraphQL en una Empresa
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
Adoptando GraphQL en una Empresa
Today's Talk is about adopting GraphQL in an enterprise. It discusses the challenges of using REST APIs and the benefits of GraphQL. The Talk explores different approaches to adopting GraphQL, including coexistence with REST APIs. It emphasizes the power of GraphQL and provides tips for successful adoption. Overall, the Talk highlights the advantages of GraphQL in terms of efficiency, collaboration, and control over APIs.
Deja paso a los resolvers: un nuevo enfoque para la ejecución de GraphQL
GraphQL Galaxy 2022GraphQL Galaxy 2022
16 min
Deja paso a los resolvers: un nuevo enfoque para la ejecución de GraphQL
GraphQL has made a huge impact in the way we build client applications, websites, and mobile apps. Despite the dominance of resolvers, the GraphQL specification does not mandate their use. Introducing Graphast, a new project that compiles GraphQL operations into execution and output plans, providing advanced optimizations. In GraphFast, instead of resolvers, we have plan resolvers that deal with future data. Graphfast plan resolvers are short and efficient, supporting all features of modern GraphQL.

Workshops on related topic

Construye una aplicación WordPress sin cabeza con Next.js y WPGraphQL
React Summit 2022React Summit 2022
173 min
Construye una aplicación WordPress sin cabeza con Next.js y WPGraphQL
Top Content
Workshop
Kellen Mace
Kellen Mace
En esta masterclass, aprenderás cómo construir una aplicación Next.js que utiliza Apollo Client para obtener datos de un backend de WordPress sin cabeza y usarlo para renderizar las páginas de tu aplicación. Aprenderás cuándo debes considerar una arquitectura de WordPress sin cabeza, cómo convertir un backend de WordPress en un servidor GraphQL, cómo componer consultas usando el IDE GraphiQL, cómo colocar fragmentos GraphQL con tus componentes, y más.
Construir con SvelteKit y GraphQL
GraphQL Galaxy 2021GraphQL Galaxy 2021
140 min
Construir con SvelteKit y GraphQL
Top Content
Workshop
Scott Spence
Scott Spence
¿Alguna vez has pensado en construir algo que no requiera mucho código de plantilla con un tamaño de paquete pequeño? En esta masterclass, Scott Spence irá desde el hola mundo hasta cubrir el enrutamiento y el uso de endpoints en SvelteKit. Configurarás una API de GraphQL en el backend y luego usarás consultas de GraphQL con SvelteKit para mostrar los datos de la API de GraphQL. Construirás un proyecto rápido y seguro que utiliza las características de SvelteKit, y luego lo desplegarás como un sitio completamente estático. Este curso es para los curiosos de Svelte que no han tenido una experiencia extensa con SvelteKit y quieren una comprensión más profunda de cómo usarlo en aplicaciones prácticas.

Tabla de contenidos:
- Inicio e introducción a Svelte
- Inicializar el proyecto frontend
- Recorrido por el proyecto esqueleto de SvelteKit
- Configurar el proyecto backend
- Consultar datos con GraphQL
- Recuperación de datos en el frontend con GraphQL
- Estilización
- Directivas de Svelte
- Enrutamiento en SvelteKit
- Endpoints en SvelteKit
- Despliegue en Netlify
- Navegación
- Mutaciones en GraphCMS
- Envío de mutaciones GraphQL a través de SvelteKit
- Preguntas y respuestas
Modelado de Bases de Datos Relacionales para GraphQL
GraphQL Galaxy 2020GraphQL Galaxy 2020
106 min
Modelado de Bases de Datos Relacionales para GraphQL
Top Content
Workshop
Adron Hall
Adron Hall
En esta masterclass profundizaremos en el modelado de datos. Comenzaremos con una discusión sobre varios tipos de bases de datos y cómo se mapean a GraphQL. Una vez que se haya establecido esa base, el enfoque se desplazará a tipos específicos de bases de datos y cómo construir modelos de datos que funcionen mejor para GraphQL en varios escenarios.
Índice de contenidosParte 1 - Hora 1      a. Modelado de Datos de Bases de Datos Relacionales      b. Comparando Bases de Datos Relacionales y NoSQL      c. GraphQL con la Base de Datos en menteParte 2 - Hora 2      a. Diseño de Modelos de Datos Relacionales      b. Relación, Construcción de Tablas Multijoin      c. Complejidades de Consulta de Modelado de Datos Relacionales y GraphQL
Prerrequisitos      a. Herramienta de modelado de datos. El formador utilizará dbdiagram      b. Postgres, aunque no es necesario instalar esto localmente, ya que estaré utilizando una imagen de Dicker de Postgres, de Docker Hub para todos los ejemplos      c. Hasura
Construir y Desplegar un Backend Con Fastify & Platformatic
JSNation 2023JSNation 2023
104 min
Construir y Desplegar un Backend Con Fastify & Platformatic
Top Content
WorkshopFree
Matteo Collina
Matteo Collina
Platformatic te permite desarrollar rápidamente GraphQL y REST APIs con un esfuerzo mínimo. La mejor parte es que también te permite desatar todo el potencial de Node.js y Fastify siempre que lo necesites. Puedes personalizar completamente una aplicación de Platformatic escribiendo tus propias características y plugins adicionales. En la masterclass, cubriremos tanto nuestros módulos de Open Source como nuestra oferta en la Nube:- Platformatic OSS (open-source software) — Herramientas y bibliotecas para construir rápidamente aplicaciones robustas con Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (actualmente en beta) — Nuestra plataforma de alojamiento que incluye características como aplicaciones de vista previa, métricas integradas e integración con tu flujo de Git (https://platformatic.dev/). 
En esta masterclass aprenderás cómo desarrollar APIs con Fastify y desplegarlas en la Platformatic Cloud.
Construyendo APIs GraphQL sobre Ethereum con The Graph
GraphQL Galaxy 2021GraphQL Galaxy 2021
48 min
Construyendo APIs GraphQL sobre Ethereum con The Graph
Workshop
Nader Dabit
Nader Dabit
The Graph es un protocolo de indexación para consultar redes como Ethereum, IPFS y otras blockchains. Cualquiera puede construir y publicar APIs abiertas, llamadas subgrafos, para hacer que los datos sean fácilmente accesibles.

En este masterclass aprenderás cómo construir un subgrafo que indexa datos de blockchain de NFT del contrato inteligente Foundation. Desplegaremos la API y aprenderemos cómo realizar consultas para recuperar datos utilizando diferentes tipos de patrones de acceso a datos, implementando filtros y ordenamiento.

Al final del masterclass, deberías entender cómo construir y desplegar APIs de alto rendimiento en The Graph para indexar datos de cualquier contrato inteligente desplegado en Ethereum.
Problemas difíciles de GraphQL en Shopify
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Problemas difíciles de GraphQL en Shopify
Workshop
Rebecca Friedman
Jonathan Baker
Alex Ackerman
Théo Ben Hassen
 Greg MacWilliam
5 authors
En Shopify a gran escala, resolvemos algunos problemas bastante difíciles. En este masterclass, cinco oradores diferentes describirán algunos de los desafíos que hemos enfrentado y cómo los hemos superado.

Tabla de contenidos:
1 - El infame problema "N+1": Jonathan Baker - Vamos a hablar sobre qué es, por qué es un problema y cómo Shopify lo maneja a gran escala en varios APIs de GraphQL.
2 - Contextualizando APIs de GraphQL: Alex Ackerman - Cómo y por qué decidimos usar directivas. Compartiré qué son las directivas, qué directivas están disponibles de forma predeterminada y cómo crear directivas personalizadas.
3 - Consultas de GraphQL más rápidas para clientes móviles: Theo Ben Hassen - A medida que tu aplicación móvil crece, también lo harán tus consultas de GraphQL. En esta charla, repasaré diversas estrategias para hacer que tus consultas sean más rápidas y efectivas.
4 - Construyendo el producto del futuro hoy: Greg MacWilliam - Cómo Shopify adopta las características futuras en el código actual.
5 - Gestión efectiva de APIs grandes: Rebecca Friedman - Tenemos miles de desarrolladores en Shopify. Veamos cómo estamos asegurando la calidad y consistencia de nuestras APIs de GraphQL con tantos colaboradores.