Evaluando GraphQL para Configurar una Malla de Datos de Grado Empresarial

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

Presentaré el concepto de una malla de datos y por qué cada vez más personas se están inclinando hacia ella como solución a sus problemas de modernización de datos (tanto en línea como analíticos) y aplicaciones. Hablaré sobre los requisitos clave en torno a 1) propiedad y arquitectura de datos descentralizadas orientadas al dominio, 2) datos como producto, 3) infraestructura de datos de autoservicio como plataforma y 4) gobernanza computacional federada (ref). Y luego hablaré sobre cómo GraphQL abre una oportunidad para sentar las bases de una malla de datos y las mejores prácticas en la construcción, operación y mantenimiento de una malla de datos de grado empresarial.

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

FAQ

Hasura es un proyecto de infraestructura de código abierto que permite crear fácilmente una API de GraphQL sobre fuentes de datos heterogéneas, facilitando así el acceso y la gestión de datos desde múltiples tipos de fuentes.

GraphQL representa eficazmente un gráfico semántico de modelos de datos interconectados, facilitando la integración y el manejo de datos de diversas fuentes en una sola API, lo que mejora la eficiencia y coherencia del acceso a los datos.

GraphQL garantiza un alto rendimiento y seguridad en las API de datos al permitir consultas precisas y limitadas, reduciendo la sobrecarga de datos y mejorando la eficiencia y protección de la información.

Una buena API de datos debe representar adecuadamente modelos de dominio y su interconexión, ofrecer tipos de interacción como consultas y actualizaciones en tiempo real, y asegurar un diseño que soporte eficientemente la autorización y el acceso seguro a los datos.

GraphQL facilita la transmisión en tiempo real de datos a través de sus primitivas modernas, lo que es útil para manejar datos que están frecuentemente en movimiento, permitiendo una integración eficaz y oportuna en aplicaciones que dependen de la actualidad de la información.

En GraphQL, se modelan primero los tipos de datos (modelos de lectura) que pueden incluir relaciones semánticas dentro de un mismo dominio o entre varios. Estos tipos se traducen luego en esquemas que facilitan la creación de consultas y mutaciones eficientes y coherentes.

Las suscripciones en GraphQL son utilizadas para mantener a los consumidores informados sobre los últimos cambios en los datos en tiempo real, adecuadas tanto para datos que cambian frecuentemente como para grandes volúmenes de datos que necesitan ser transmitidos de manera continua.

Tanmai Gopal
Tanmai Gopal
24 min
09 Dec, 2021

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Esta charla explora los beneficios de usar APIs de GraphQL para datos, incluyendo la representación de modelos de dominio, abordando las herramientas y la infraestructura de la API, y soportando datos interconectados. Se discute la asignación de modelos, APIs de lectura, filtrado, ordenamiento y agregación de datos, así como mutaciones para invocar lógica. La charla también destaca la importancia de estandarizar la infraestructura y aprovechar la asignación automática de modelos y la autorización de GraphQL. Además, se menciona el uso de bases de datos especializadas, la comparación entre GraphQL y gRPC para APIs de datos, y la experiencia del ponente trabajando en varias partes del stack.

1. Introducción a las API de GraphQL para datos

Short description:

Hola a todos, en esta charla discutiré las API de GraphQL para datos. Exploraremos los desafíos de los datos fragmentados y la necesidad de una API integral. GraphQL ofrece beneficios al representar modelos de dominio, proporcionar diversas API y abordar las herramientas y la infraestructura de la API. Permite abordar preocupaciones centralizadas y admite datos interconectados. Al adoptar un enfoque de estilo CQR, podemos diseñar API con modelos de lectura y comandos. Al llevar estas ideas a GraphQL, podemos priorizar los modelos de lectura y manejar datos dentro del mismo dominio o en diferentes dominios.

Hola a todos, voy a hablarles un poco sobre las API de GraphQL para datos. Mi nombre es Tanya. Soy la CEO y cofundadora de Hasura. Hasura es un proyecto de infraestructura de código abierto que te permite crear fácilmente una API de GraphQL sobre fuentes de datos heterogéneas. Gran parte del contenido de esta charla está inspirado en el trabajo que hacemos en Hasura y en los aprendizajes de nuestros usuarios, especialmente en empresas, a medida que movilizan sus datos y comienzan a utilizar GraphQL cada vez más para mejorar la experiencia en torno a sus API de datos.

Entonces, el contexto general de esta charla es que los datos están cada vez más fragmentados y dispersos en múltiples tipos de fuentes. Y necesitamos una API para comenzar a acceder a esos datos. Puede tener datos transaccionales o datos dentro de un servicio SaaS, o datos más analíticos. Y dentro del mismo contexto de la aplicación o del mismo contexto del usuario, todos los datos que están divididos en estos diferentes tipos de fuentes están cada vez más conectados y relevantes para el usuario final al mismo tiempo. Y si pensamos en una aplicación de comercio electrónico simple, no solo realizas transacciones e interactúas con datos, sino que también buscas en catálogos. También estás viendo información agregada y analizada, y estas son cosas que están interconectadas. Y desde el punto de vista de la API, es posible que necesites que todo esto se integre en una sola experiencia de API. Cuando pensamos en esta API, es un poco el cuello de botella porque alguien necesita construir esta API. Alguien necesita comunicarse con múltiples tipos de fuentes, y debes asegurarte de que la API se mantenga continuamente actualizada con la evolución subyacente que está ocurriendo. Y, por supuesto, deseas una experiencia de API que garantice cierto nivel de rendimiento y seguridad, ¿verdad?

Entonces, en este contexto de tener una API de datos donde los datos se están fragmentando, las cosas que queremos, las propiedades que queremos de una API de datos, son las mismas propiedades que queremos para cualquier motor de API. Pero específicamente, lo que queremos asegurarnos es que podamos representar nuestros modelos de dominio, su evolución, su interconexión, ¿verdad? Queremos asegurarnos de tener ciertos tipos de API que, nuevamente, son habituales en las API de datos, ya sea consultas o información en tiempo real. Ciertas formas de interactuar con esos datos, métodos en esos datos, y ciertos NFR que son importantes para garantizar que esta API de datos esté lista y sea utilizable para producción. Lo más importante es que queremos asegurarnos de que las herramientas de la API, la infraestructura para nuestros consumidores de API, sean de primera categoría y sigan evolucionando. Si podemos resolver estos problemas, bueno, esencialmente tenemos una buena API de datos que será fácil de mantener y evolucionar, ¿verdad?

Entonces, si piensas que hay muchos temas aquí, nos centraremos principalmente en el aspecto de modelado de IA y datos de la API con el propósito de esta charla. Veamos cómo GraphQL puede agregar valor aquí cuando pensamos en la API de datos, ¿verdad? Nuestros datos están interconectados, por lo que GraphQL representa esa realidad de un gráfico semántico de modelos interconectados mucho mejor que si pensáramos en recursos aislados que evolucionan de forma independiente, ¿verdad? GraphQL es nativo de JSON, lo cual es bueno desde el punto de vista de consumo de la API, y nos ofrece la oportunidad de centralizar parte de esa infraestructura en torno a la conversión JSON cuando interactuamos con datos. GraphQL también tiene primitivas modernas en torno a la transmisión en tiempo real, lo cual es útil porque los datos están empezando a estar menos en reposo y una buena cantidad de nuestros datos también están en movimiento en tiempo real, ¿verdad? Y, por supuesto, GraphQL siempre tiene un esquema, un artefacto incorporado, lo que significa que muchos de nuestros desafíos en torno a la infraestructura de la API, las herramientas, la documentación, la incorporación, se abordan automáticamente, ¿verdad? No está al 100%, pero una gran parte de lo que tendríamos que hacer manualmente si no estuviéramos utilizando GraphQL se aborda automáticamente, ¿verdad? Ofrece ciertos beneficios en lo que queremos de nuestra API de datos y ofrece ciertas oportunidades para centralizar algunas de esas preocupaciones y la forma en que pensamos en nuestros datos que se dividen en una malla de fuentes. Entonces, típicamente, cuando diseñamos una API, la forma en que la pensaríamos es que tendríamos modelos, tendríamos getters o accesores de esos modelos, ¿verdad? Por ejemplo, si tuviera artistas y álbumes en la base de datos de música, tendría un método get en un artista, ¿verdad? O donde podría especificar un ID como parámetro, ¿verdad? Tendría una lista de artistas que obtuve con un parámetro de paginación, ¿verdad? Y luego tendría ciertos comandos o métodos que invocaría que afectan esos modelos, ¿verdad? Y si lo pensáramos más como una cosa de estilo CRUD, entonces tendríamos un modelo. El mismo modelo es un modelo de lectura y un modelo de escritura. Podríamos publicar, poner, parchear, eliminar un modelo o podríamos obtener ese modelo, ¿verdad? Pero si lo estás pensando más desde un punto de vista de CQRS, entonces pensaríamos más en que tenemos comandos que estamos invocando y luego invocamos comandos. Estos pueden ser crear usuario, crear artista, procesar artista, agregar álbum a artista, ¿verdad? O agregar etiqueta a artista, o lo que sea. Y esos serían comandos que invocamos y nuestros modelos serían modelos de lectura en los que esperaríamos que nuestros comandos afecten. Y luego leeríamos datos de esos modelos, ¿verdad? Y eso podría ser una idea ligeramente diferente. Ahora, cuando llevamos estas ideas a GraphQL, la forma en que me gusta pensar en esto es más bien llevar ese tipo de pensamiento de estilo CQR a nuestro diseño de API. Entonces, pensamos primero en los modelos de lectura. Tenemos modelos de lectura. Los modelos de lectura pueden estar dentro de la misma fuente o dentro del mismo dominio de datos, o divididos entre dominios de datos.

2. Mapeo de modelos y API de lectura

Short description:

Y estos tendrían conexiones, ¿verdad? Aún no hemos definido los métodos y eso es a lo que vamos a llegar a continuación. La primera categoría de métodos que podemos tener son las consultas, ¿verdad? Y debido a que es una API de datos, habrá algunas expectativas y convenciones comunes que podemos establecer. Y ahora, cuando pensamos en el lado derecho de nuestra API, especialmente cuando pensamos en las mutaciones gráficas, entonces la forma en que lo pensamos es que invocamos un comando. Entonces, en esta capa, en la capa de la API de GraphQL, podemos comenzar a centralizar parte de la infraestructura en la forma en que mapeamos estos modelos, los convertimos en tipos, en la forma en que creamos API de lectura comunes en estos dominios y en la forma en que invocamos ciertos comandos. Entonces, si podemos centralizar la infraestructura aquí, podemos aprovechar todos los beneficios que las personas obtienen de una API de GraphQL, podemos centralizar gran parte del esfuerzo que estamos poniendo en la construcción de la API. A continuación, nos adentraremos un poco más en ese mapeo de modelos en las API, la API de lectura y la API de escritura, solo para ver cómo podría verse eso. Lo segundo que queremos hacer para asegurarnos de representar es asegurarnos de poder modelar las relaciones entre estos modelos que tenemos. Y debido a que finalmente será JSON, la forma en que la relación se mostrará en la API será, tal vez tenga un objeto anidado agregado, por lo que tiene muchos para ser un objeto anidado, o desea que sea una matriz anidada, ¿verdad? Incluso puede tener campos que sean en realidad una relación que proviene de un modelo diferente. Y cada uno de esos modelos también debe tener herramientas de autorización que determinen qué campos son accesibles y qué entidades de ese modelo son realmente legibles por un consumidor de API en particular. Entonces, eso es, estas tres piezas de trabajo, mapeo, relaciones y autorizaciones, políticas, ¿verdad? Esta es la información mínima que necesitamos para llevar un modelo desde nuestro dominio de datos, desde una de nuestras fuentes de datos, a la API. La segunda pieza es la lectura. Entonces, lo que queremos hacer es crear convenciones sobre cómo vamos a leer estos modelos, ¿verdad? Podemos crear convenciones sobre la paginación, el orden y el filtrado, ¿verdad? Queremos crear una convención sobre las agregaciones y luego queremos componerlas con una relación, queremos representar esas relaciones en nuestras consultas, ¿verdad? Entonces, queremos poder leer modelos a través de relaciones. También queremos asegurarnos de que nuestras consultas puedan representar agregaciones, ordenar o filtrar que puedan hacer referencia a objetos padre e hijo, ¿verdad? Echemos un vistazo rápido, como ejemplo, solo te mostraré cómo lo pensamos en Hasura y cómo se ve esa API de lectura, cómo se ve esa convención de lectura cuando lo pensamos en Hasura, la forma en que lo pensamos en Hasura, ¿verdad?

Estos tendrían relaciones semánticas dentro del dominio o entre dominios. Y esencialmente se convertirían en los tipos de nuestro esquema de GraphQL, ¿verdad? Aún no hemos definido los métodos y eso es a lo que vamos a llegar a continuación.

La primera categoría de métodos que podemos tener son las consultas, ¿verdad? Y debido a que es una API de data, habrá algunas expectativas y convenciones comunes que podemos establecer, ¿verdad? ¿Estamos obteniendo un solo elemento? ¿Un solo modelo? ¿Una lista de modelos, paginando a través de ellos, ordenándolos, filtrándolos? Las agregaciones son especialmente importantes para las API de data, ¿verdad? Entonces, podemos comenzar a crear una convención que diga, una vez que tenemos un modelo de lectura, estos son los métodos comunes que podemos tener para leer esos modelos, ¿verdad? Y eso aborda el lado de las consultas de nuestra API.

Y ahora, cuando pensamos en el lado derecho de nuestra API, especialmente cuando pensamos en las mutaciones gráficas, ¿verdad? Tal vez también algunas consultas, cuando pensamos en las mutaciones gráficas, entonces la forma en que lo pensamos es que invocamos un comando. El comando hará algo, pero eventualmente devolverá una referencia a un modelo de lectura o a una lista de modelos de lectura, ¿verdad? Y eso nos da una forma de pensar en el diseño del lado derecho de nuestra API, especialmente en las mutaciones gráficas. Aunque, como dije, algunos comandos también podrían ser comandos de consulta. Pero es la misma idea, solo que la estamos visualizando en el contexto de múltiples dominios, ¿verdad?

Podríamos tener múltiples dominios, cada dominio tiene modelos, comandos, ¿verdad? Y usamos eso para crear nuestra API de GraphQL, ¿verdad? Entonces, en esta capa, en la capa de la API de GraphQL, podemos comenzar a centralizar parte de la infraestructura en la forma en que mapeamos estos modelos, los convertimos en tipos, en la forma en que creamos API de lectura comunes en estos dominios y en la forma en que invocamos ciertos comandos. Entonces, si podemos centralizar la infraestructura aquí, ¿verdad?, podemos aprovechar todos los beneficios que las personas obtienen de una API de GraphQL, podemos centralizar gran parte del esfuerzo que estamos poniendo en la construcción de la API. Y podemos enfocarnos más dentro de cada uno de esos dominios, podemos enfocarnos en el modelado, podemos enfocarnos en la lógica real que podría ejecutarse y afectar esos modelos, ¿verdad? Entonces, lo que vamos a explorar a continuación es un poco más en ese mapeo de modelos en las API, la API de lectura y la API de escritura un poco, solo para ver cómo podría verse eso. ¿Correcto? Entonces, obtengamos los modelos, cuando pensamos en modelos, lo más importante es poder mapear lo que queremos en el modelo que queremos exponer, los modelos que tenemos dentro de nuestro dominio, ¿verdad? Entonces, si tienes un dominio de tipo database, ¿verdad?, tenemos modelos físicos, estos modelos de data podrían ser modelos físicos, podrían ser tablas, ¿verdad? O modelos lógicos, donde los datos exactos en la tabla en realidad no se correlacionan con el modelo que quieres tener en la API, ¿verdad? Entonces, podrías tener un modelo físico o un modelo lógico. Pero básicamente se representan en un modelo gráfico que deseas al final del día. Si no es una database, sino más bien una fuente, podrías tener un modelo que proviene de un servicio de API, ¿verdad? Entonces, la capa de mapeo que tenemos en nuestra infraestructura gráfica, en la configuración del marco de código, lo que sea, debería ayudar a resolver este problema de mapeo para traer ciertos modelos de una de una fuente de datos de un dominio de data de la manera más fácil posible. Lo segundo que queremos hacer para asegurarnos de representar, ¿verdad?, que queremos agregar configuración o código alrededor, es asegurarnos de poder modelar las relaciones entre estos modelos que tenemos, ¿verdad? Y debido a que finalmente será JSON, la forma en que la relación se mostrará en la API será, ya sabes, tal vez tenga un objeto anidado agregado, por lo que tienes muchos para ser un objeto anidado, o quieres que sea una matriz anidada, ¿verdad? Incluso puedes tener campos que en realidad son una relación que proviene de un modelo diferente. ¿Y cada uno de esos modelos también debe tener herramientas de autorización que determinen qué campos son accesibles, y qué entidades de ese modelo son realmente legibles por un consumidor de API en particular, ¿verdad? Entonces, eso es, estas tres piezas de trabajo, mapeo, relaciones y autorizaciones, políticas, ¿verdad? Esta es la información mínima que necesitamos para llevar un modelo desde nuestro dominio de data, ¿verdad?, desde una de nuestras fuentes de data, ¿verdad?, a la API, ¿verdad?, y en este punto ahora tenemos una buena forma de pensar en los tipos de nuestro esquema de GraphQL y la forma en que esos tipos se mostrarán, ¿verdad? No todos los tipos, algunos de los tipos, ¿verdad?, la forma en que eso se mostrará. Entonces, esa es la primera pieza de la API de data que hemos resuelto, ¿verdad?

Y si miras este ejemplo que tengo aquí donde tengo el tipo artistas, ¿verdad? Estoy viendo que mi modelo de GraphQL es id y name. En el modelo físico, podría ser nombre y apellido, mi modelo de API, mi modelo de GraphQL me gustaría que se llame, ese es mi modelo de lectura, ¿verdad? Y luego podría tener álbumes, ¿verdad?, del artista como una etiqueta, el artista está firmado en la etiqueta, la etiqueta podría tener su propia información, ¿verdad? Entonces, eso es un objeto anidado. El artista tiene varios álbumes, por lo que sería una matriz anidada. Entonces, álbumes y etiqueta serían modelos diferentes y tendrían relaciones con el modelo de álbumes y con el modelo de etiqueta, ¿verdad? Y aquí es donde he hecho el mapeo del propio modelo de artista. Entonces, estamos viendo la parte de mapeo, estamos viendo relaciones, ¿verdad? Y luego, por supuesto, tenemos reglas de autorización que determinan qué campos podemos acceder realmente. Entonces, así es como se mostrará en el esquema de la API, lo cual es bueno porque ahora podemos ver qué modelos interconectados tenemos, ¿verdad? La segunda pieza es la lectura. Entonces, lo que queremos hacer es crear convenciones sobre cómo vamos a leer estos modelos, ¿verdad? Entonces, podemos crear convenciones sobre la paginación, el orden y el filtrado, ¿verdad? Queremos crear una convención sobre las agregaciones y luego queremos componerlas con una relación, queremos representar esas relaciones en nuestras consultas, ¿verdad? Entonces, queremos poder leer modelos a través de relaciones. También queremos asegurarnos de que nuestras consultas puedan representar agregaciones, ordenar o filtrar que puedan hacer referencia a objetos padre e hijo, ¿verdad? Entonces, echemos un vistazo rápido, como ejemplo, solo te mostraré cómo lo pensamos en Hasura y cómo se ve esa API de lectura, cómo se ve esa convención de lectura cuando lo pensamos en Hasura, la forma en que lo pensamos en Hasura, ¿verdad?

Tengo aquí una aplicación de demostración que se está ejecutando en mi máquina, y me he conectado a una fuente de Postgres y a una fuente de SQL Server. Estos son mis dos dominios de data. Y tengo un modelo llamado artistas, que tiene ID y nombre, ¿verdad? Entonces, estamos viendo esa información aquí. Echemos un vistazo a cómo se ve la API. Entonces, tengo paginación, ¿verdad? Paginación basada en desplazamiento o paginación basada en cursor. Tenemos una forma de filtrar cosas.

3. Filtrado, Ordenamiento, Agregación y Mutaciones

Short description:

Podemos filtrar y ordenar las listas obtenidas utilizando las APIs de filtrado y ordenamiento. Además, podemos aplicar agregaciones a cualquier lista de modelos, lo que nos permite contar u ejecutar otras funciones de agregación. También se pueden representar relaciones entre modelos de diferentes dominios de datos, lo que nos permite obtener datos relacionados y realizar agregaciones entre dominios. Esto sigue una convención de API de GraphQL y permite una representación ordenada de las agregaciones dentro de las relaciones. Por otro lado, en el lado derecho de la API, tenemos mutaciones para invocar lógica, como crear un usuario.

Entonces, podemos decir limit 10. Así es como se ve nuestra API de ordenamiento y ordenamiento. Y luego, por supuesto, también tenemos una API de filtrado. Y podemos filtrar en diferentes campos, podemos decir where, name, like. Digamos cualquier cosa que comience con una Y. Entonces, tenemos estos ordenados. Esa es más o menos la idea del filtrado. Esa es una convención en torno a una lista de modelos. Entonces, estamos obteniendo listas y esta es la forma en que queremos tener ciertos argumentos al obtener una lista. De manera similar, una convención en torno a las agregaciones en la forma en que pensamos en las agregaciones es que cualquier lista, cualquier lista de modelos que se obtenga puede tener una agregación aplicada a ella, y con un cierto conjunto de funciones de agregación que, nuevamente, se pueden agregar para diferentes tipos de modelos y diferentes tipos de fuentes. Por ejemplo, puedo hacer un conteo. Así que puedo hacer un conteo para ver cuántos artistas tengo en el sistema aquí. Muy bien, echemos un vistazo a las relaciones. Entonces, tenemos el ID y el nombre del artista, y limitemos esto a 10. Y ahora puedo obtener, digamos, álbumes relacionados. Y podemos ver los títulos de esos artistas que están llegando aquí. O los artistas y los álbumes están en realidad en dos dominios de datos diferentes solo para mostrarte cómo se ve eso. Mis artistas provienen de un dominio de datos, que está en Postgres, y los álbumes están en realidad en SQL Server. Entonces, aunque están en dos dominios diferentes, estoy viendo una API similar que me permite hacer cosas como limit offset, paginar en el campo subyacente también. De hecho, también puedo comenzar a agregar agregaciones aquí. Puedo decir, puedo comenzar a contar y ejecutar agregaciones en una lista. Y lo bueno es que esto sigue una convención de API de GraphQL, pero puedo agregar cualquier lista, ya sea en el nivel superior o incluso si es una propiedad de un padre en particular de un hijo. Entonces puedo ver la cantidad de álbumes que tengo para un artista. Y esto nos permite representar las agregaciones de manera ordenada en el contexto de las relaciones que también tenemos. Entonces, nuestros conceptos se están componiendo, ¿verdad? Y nuestras convenciones también se están componiendo a medida que trabajamos con ellas. Entonces, esta es una forma de pensar en el diseño de la API de lectura, ¿verdad? Muy bien, pasemos rápidamente a otros conceptos, pero esto es solo una idea de cómo pensar en la API de lectura. Ahora, el otro lado de la API sería el lado derecho de nuestra API, es decir, las mutaciones. Por ejemplo, queremos tener cosas que queremos invocar lógicamente. Digamos, por ejemplo, algo complejo como crear un usuario que debe pasar por varias etapas.

4. Creación de Usuarios y Estandarización de Infraestructura

Short description:

Podemos crear un usuario y esperar que la lógica devuelva una referencia a un ID de usuario. GraphQL puede tomar esa lógica y devolver un objeto de usuario en la API. Podemos crear convenciones en torno a las acciones CRUD y diferentes implementaciones de lógica. GraphQL también ofrece suscripciones para consultas y transmisiones en vivo. Al configurar la infraestructura subyacente de GraphQL, podemos beneficiarnos del mapeo automático de modelos y la autorización. Esto crea una plataforma GraphQL que expone dominios de datos a través de una API agradable, lo que permite a los propietarios centrarse en los modelos de dominio y la lógica. Pensar en GraphQL como una forma de estandarizar la infraestructura nos permite centrarnos en el dominio en lugar de la API en sí misma.

Podemos crear un usuario. La convención que podemos tener es que esperamos que nuestra lógica devuelva una referencia a un ID de usuario, ¿verdad? Y lo que nuestro sistema GraphQL puede hacer es tomar ese tipo de lógica, la salida de esa lógica, que es un ID de usuario, una referencia al modelo de usuario, el modelo lógico que tenemos para el objeto de usuario. Y así, en la API final de GraphQL, esperaríamos ver una mutación que devuelva un objeto de usuario y nos permita recorrer el objeto de usuario, el modelo de usuario. Y si es una lista, entonces esa lista de modelos. Y nuevamente, esos mismos conceptos que teníamos de una API de lectura que podemos traer a la respuesta de un comando en particular, ¿verdad? Entonces, ese tipo de flujo ligeramente estilo CQL es la forma en que podemos pensar en cómo traer ciertos comandos a nuestra API de GraphQL también.

También podemos crear nuestras propias convenciones en torno a CRUD, ¿verdad? Porque las acciones CRUD son esencialmente solo comandos que también devuelven, nuevamente, una única referencia o una lista de referencias. Y también podemos establecer ciertas convenciones en torno a lo que queremos tener para la lógica que tenemos escrita en diferentes tipos de, tal vez está escrita en diferentes lenguajes, ¿verdad? Está incrustada dentro de la base de datos, tal vez solo está escrita como una función sin servidor. Se invoca a través de HTTP o RPC, y eso no importa porque esa convención puede ser la misma. La capa de GraphQL solo tiene que asegurarse de saber cómo hacer referencia a los modelos principales que teníamos en nuestra discusión anterior y cómo invocar comandos y lógica que tenemos cuando estamos trayendo comandos y mutaciones a nuestro sistema, ¿verdad?

GraphQL también ofrece suscripciones. Por razones de tiempo, no entraré en demasiados detalles, pero las suscripciones pueden tener, la forma en que pensamos en las suscripciones es que puedes tener consultas en vivo para suscripciones que son muy útiles para los consumidores cuando están viendo las últimas instantáneas de datos, o puedes tener transmisiones, que son muy útiles para listas más grandes de datos o para eventos, ¿verdad? Especialmente cuando tienes una lista realmente grande donde tienes como mil millones de elementos y quieres extraer esa información a través de una API. Una API es una forma muy agradable de hacerlo, pero mil millones de elementos, eso sería realmente grande, ¿verdad? Entonces, puedes transmitir esos datos a medida que llegan, o incluso puedes transmitir información en tiempo real de la misma manera que transmitirías eventos. Y las suscripciones ofrecen una forma agradable de hacer ambas cosas. La nueva API de AppStream, la directiva de AppStream, también ofrecerá una forma de abordar la transmisión de listas más grandes. La especificación aún está evolucionando, y creo que nuestra comprensión de la transmisión, especialmente, también está evolucionando porque hay cosas como la presión de retroceso y cosas así, que también debemos tener en cuenta y que aún no tienen una respuesta definitiva, pero hay una oportunidad de proporcionar este tipo de valor para una API de datos moderna también. Entonces, para dar un paso atrás y ver lo que pasamos, ¿verdad? Pensamos en usar GraphQL como una convención de API elegante para una API de datos, ¿verdad? Vimos algunos patrones de uso comunes y cómo podemos modelar esos patrones de uso para una API de datos. Vemos cómo esos conceptos se componen automáticamente. No pudimos hablar sobre la autorización porque eso es demasiado detalle para esta conversación, pero la autorización a nivel de modelo también puede componerse automáticamente a medida que pensamos en nuestras API de lectura y nuestras API de comandos. Cuando piensas en este diseño y ahora lo operacionalizas, ¿verdad? La forma en que lo pienso es, ¿qué trabajo de plataforma necesitamos hacer para configurar la infraestructura subyacente de GraphQL, ¿verdad? Para que podamos beneficiarnos de estas tres o cuatro ideas que discutimos, ¿verdad? La primera pieza de infraestructura es que si puedes configurar una buena forma para que los mantenedores de una API de GraphQL o los propietarios de una API de GraphQL puedan ingresar y hacer el mapeo de modelos y la autorización, eso se vuelve realmente agradable porque ahora podemos comenzar a traer modelos, ¿verdad? Y podemos traer modelos de forma segura. Entonces también podemos traer la infraestructura para pensar en integraciones específicas de origen de datos para que nuestra ejecución de consultas se pueda optimizar para diferentes tipos de fuentes de datos con las que estamos hablando, ¿verdad? Y esa pieza puede estar un poco desacoplada del mapeo de modelos y la autorización, ¿verdad? Para que estemos utilizando los mismos conceptos semánticos pero estemos compilando consultas si esa es la forma más efectiva de hacerlo o almacenando en caché consultas en la solicitud si esa es una forma más eficiente de hacerlo, ¿verdad? Y luego, por supuesto, la infraestructura que también necesitamos configurar es decidir cómo queremos tener comunicación con los servicios ascendentes, especialmente los comandos, ¿verdad? Entonces, RPC o HTTP es necesario. Las semánticas de lectura después de la escritura también son una parte clave de esto para asegurarse de que cuando ejecutes un comando y suceda algo, devuelva una referencia a un modelo de lectura, realmente puedas leer esa referencia. No obtendrás una lectura de estado o una lectura desactualizada. Entonces, esa es una pieza importante que también debe existir. Pero si podemos configurar esto y podemos capacitar a nuestra API de GraphQL en esta infraestructura y permitirles configurar esto, entonces básicamente lo que obtenemos es una plataforma GraphQL, ¿verdad? Que luego nos permite obtener algunas cosas de forma gratuita, ¿verdad? Lo primero que obtenemos de forma gratuita es que todos los dominios de datos que tenemos ahora, esos dominios de datos se exponen automáticamente a través de una API agradable que a la gente le gusta mucho, ¿verdad? Toda la documentación de metadatos, las herramientas de API de GraphQL están integradas, GraphQL es una API que a la gente le gusta mucho usar. Pero desde el punto de vista de los constructores, ¿verdad? De esta API, los propietarios de esos dominios ahora tienen más tiempo libre y flexibilidad para centrarse solo en su dominio, los modelos y la lógica y no en la plomería de cómo lo van a exponer a través de la API porque esa parte, hemos podido crear convenciones comunes para hacerlo, ¿verdad? Entonces, porque podemos externalizar eso, hacerlo una convención común y luego trabajar en esto de forma gratuita. Creo que a un nivel muy alto, ¿verdad? La cantidad de datos que tenemos simplemente seguirá aumentando y seguirá fragmentándose y, por lo tanto, pensar en GraphQL como una forma de abordar este problema ofrece una forma agradable de pensar en este problema y obtener valor de eso más rápido y también prepararnos para el futuro, ¿verdad? Los próximos cinco, seis años serán una locura solo en la cantidad de datos que tenemos y las formas en que comenzamos a usarlo. Y lo que realmente me gusta de esto es que esta oportunidad que podemos aprovechar para estandarizar la infraestructura nos permite centrarnos en el dominio en lugar de centrarnos en la API en sí misma. Es algo así. No es realmente, solo estamos cambiando dónde estamos poniendo nuestro esfuerzo, ¿verdad? En decir que en lugar de construir, implementar, escalar y documentar API, porque usamos GraphQL como una forma de estandarizar estas cosas, ¿podemos ahora simplemente enfocarnos en modelar el dominio y crear la lógica empresarial única? Y eso es todo. Ese es el trabajo que hacemos. Obtenemos la API de forma gratuita porque es una API de GraphQL agradable, ¿verdad? Entonces, esa es la idea que quería dejarles a ustedes.

QnA

Fuentes de Datos y Agregaciones

Short description:

No dudes en contactarme si tienes alguna pregunta. Es interesante ver el creciente número de fuentes de datos en las aplicaciones. Nos estamos alejando de una base de datos que lo hace todo para utilizar bases de datos especializadas para diferentes tareas. Con GraphQL, las agregaciones se manejan a través de tipos y relaciones predefinidas. El tipo de retorno de una agregación depende de la función que se esté utilizando.

No dudes en contactarme. Ese es el final de mi tiempo, pero no dudes en contactarme si tienes alguna pregunta. Me encantaría hablar sobre cómo estás pensando en los desafíos y compartir ideas sobre el uso de este enfoque, las desventajas y los beneficios que se supone que debe generar. Pero eso es todo por ahora, y no dudes en contactarme también en Twitter. Adiós.

Entonces, hiciste la pregunta sobre cuántas fuentes de datos diferentes tiene la aplicación o API, y hemos obtenido los votos hasta ahora. La mayoría de las personas, el 60%, han votado de uno a cinco. Sí. Y el 20% dice que solo están utilizando una única fuente de datos, y luego nadie... Bueno, ahora cambió a 17%, y luego 10 o más, quiero decir, el 17% de las personas están utilizando 10 o más, y puntos, oh Dios mío. ¿Qué tienes que decir al respecto? Eso es genial. No, fue realmente interesante realizar esa encuesta y ver lo que la gente está haciendo, porque creo que lo que estamos viendo es que el número de fuentes de verdad que tienes en tu aplicación seguirá aumentando, ¿verdad? Ya sea que sean servicios SaaS u otras bases de datos, creo que ese número seguirá aumentando. No creo que vaya a reducirse, no se va a frenar. Sí, siempre me gusta decir que solíamos pensar que podría haber una base de datos que lo hiciera todo. Ahora creo que nos hemos dado cuenta de que está bien. No vamos a tener una base de datos que lo haga todo. Vamos a utilizar cinco o seis bases de datos diferentes para hacer cosas especializadas, ¿verdad? Como tener una cosa de series temporales y una cosa de búsqueda. Y, por supuesto, también con otros servicios, ¿verdad? Así que se está volviendo cada vez más fragmentado, lo cual es genial. Sí, eso es genial. Eso es genial, de verdad.

Quisiera recordarle a la audiencia que si tienen alguna pregunta, háganoslo saber en el canal de preguntas y respuestas de la Vía Láctea. Mientras tanto, tengo una pregunta para ti, Tanmay. Las API de datos suelen necesitar la capacidad de ejecutar agregaciones también. ¿Cómo se ve una API de datos basada en GraphQL que admite agregaciones genéricas? Eso, sí, eso es, creo que eso ha sido algo muy interesante cuando se piensa en el diseño de la API de datos, ¿verdad? Porque el desafío es que cuando pensamos en las agregaciones, ¿verdad? Y especialmente si miras cualquier sistema de agregación, ¿verdad? Ya sea agregaciones de Mongo o agregaciones de SQL, lo que sucede con las agregaciones es que los tipos, cuando haces una consulta para agregar algunos datos, ¿verdad? Digamos que tienes usuarios que tienen ID, nombre y algo más, y quieres ejecutar una agregación para ver cuántas personas tienen el mismo nombre, ¿verdad? Y haces un agrupamiento en este módulo de usuarios y agrupas por nombre, ¿verdad? Y cuentas. Entonces, el tipo de retorno de lo que obtienes de una agregación, ese tipo de retorno no es el mismo que el tipo de usuario, ¿verdad? El tipo de retorno depende de lo que estés agregando. Entonces, si estás agregando la cantidad de elementos, obtendrás un número entero, ¿verdad? Si estás agregando, digamos, cuál es la longitud promedio del nombre de alguien, en lugar de obtener un retorno de cadena, obtendrás un retorno numérico o de punto flotante, ¿verdad? Entonces, el tipo de lo que estás tratando de obtener depende del tipo de función de agregación que estás ejecutando, lo cual lo hace interesante con GraphQL porque la idea con GraphQL es que tienes un esquema de GraphQL que tiene tipos predefinidos, ¿verdad? Entonces, este es el desafío central. Entonces, uno de los enfoques que hemos tomado al pensar en la agregación con GraphQL es que para cualquier tipo de lista, cualquier cosa que devuelva una lista de elementos, definimos una serie de agregaciones en la lista que están predefinidas, ¿verdad? Y, por supuesto, puedes agregar más tipos de agregación. Y cuando quieres hacer un agrupamiento, que afectaría al tipo de retorno, eso se hace a través de una relación. Entonces, lo que haces es decir que tienes, como tienes usuarios, y luego dices usuarios.transactionsAggregate, ¿verdad? O orderedAggregate. Entonces, estás viendo cuántos pedidos, el número máximo de pedidos, el monto promedio gastado en los pedidos por usuario, ¿verdad? Entonces, la clave de agrupamiento que pensarías cuando estás haciendo agregaciones se convierte en el padre y el resultado de la agregación se convierte en el hijo.

Comparando GraphQL y gRPC para API de Datos

Short description:

GraphQL podría ser una API más agradable que una API de estilo RPC para obtener datos, incluso para la comunicación entre servicios. Algunos proyectos están mezclando GraphQL y gRPC, entregando GraphQL a través de un protocolo gRPC. Aún depende del caso de uso. En cuanto a la pregunta sobre las áreas favoritas para explorar en Ciencias de la Computación, comencé tarde en el desarrollo de software, pero cubrí varias áreas como sistemas operativos, redes, bases de datos y teoría de lenguajes de programación. Disfruto construyendo diferentes tipos de aplicaciones y tengo experiencia con Kubernetes y Docker.

Entonces se convierte en una forma muy fácil de extenderlo en GraphQL, manteniendo aún un esquema de tipos. Pero también obteniendo una flexibilidad bastante groupByKeys con agregación. Así que ese es un patrón, un enfoque que vemos que funciona para acercar la agregación a GraphQL.

Eso es realmente agradable, quiero decir, es realmente esclarecedor saber eso. También tengo otra pregunta para ti sobre la API de datos. Entonces, nuestra API de datos, también puede ser consumida por otros servicios y no solo por aplicaciones front-end, ¿verdad? Entonces, ¿cómo se compara GraphQL con, digamos, gRPC en este contexto?

Sí, eso es algo de lo que he hablado con otras personas antes. Porque cuando estás pensando en una API de datos, como dije, se convierte en una cosa entre servicios. Por lo tanto, a menudo es una API que se utiliza entre servicios, un servicio está accediendo a otro servicio para obtener datos, ¿verdad? El equipo uno está hablando con el equipo dos para obtener los datos del equipo dos, ¿verdad? Y eso a menudo es una API interna entre servicios donde la gente a menudo piensa en gRPC. Entonces, creo que gRPC también aborda algunos de esos problemas en términos de tener un esquema o un protocolo entre estos servicios que sea tipado. Además, es HTTP2, por lo que es bidireccional. Y luego creo que la conexión también es persistente, lo cual también es muy agradable, ¿verdad, entre estos dos servicios? Pero creo que para una API de datos, GraphQL aún podría ser mejor en términos de ergonomía porque cuando estás viendo una API de datos, estás haciendo una llamada de API que obtiene un montón de información en un solo disparo, en una sola llamada de API, ¿verdad?

Desde el punto de vista del cliente, desde el punto de vista del cliente, como uno de los servicios que intenta obtener esos datos, es más fácil hacer una sola consulta para obtener esos datos en lugar de tener varias cosas, en lugar de solicitar los datos varias veces, que es lo que podrías terminar haciendo con si lo estuvieras pensando en estilo RPC, ¿verdad? Entonces, creo que para una API específica de datos, GraphQL seguiría siendo mejor, incluso para la comunicación entre servicios. Y creo que será interesante porque ya he visto algunos proyectos que hacen esto donde las personas están mezclando los dos, ¿verdad? Las personas están fusionando, donde las personas están pensando en GraphQL, pero entregando GraphQL a través de un protocolo gRPC, ¿verdad? Así que hay algunas ideas interesantes que están sucediendo también. Así que creo que también será interesante ver eso. Pero mi intuición me dice que creo que cuando se trata de obtener datos, una API de GraphQL podría ser una API más agradable que una API de estilo RPC. Pero creo que aún depende del caso de uso.

Sí, definitivamente. Y eso es realmente interesante. También me gustaría ver cómo se desarrolla el uso de GraphQL y gRPC juntos.

Entonces hay una pregunta más de un estudiante. No está relacionada realmente con GraphQL, pero quieren saber cuánto tiempo has estado desarrollando software. Entonces, ¿cuáles son tus áreas favoritas para explorar en Ciencias de la Computación?

Sí, comencé a escribir código y construir cosas muy tarde en mi vida. No empecé muy temprano. Comencé solo en la universidad. Conozco a muchas personas que comenzaron mucho antes de la escuela, incluso cuando eran niños. Así que comencé realmente tarde pero luego me gustó mucho. Me aseguré de, creo, tocar tantas áreas diferentes como fuera posible. Entonces, dentro del stack, ¿verdad? Y cuando estaba estudiando Ciencias de la Computación, para mí, estaba tratando de abarcar todas las capas del stack, ¿verdad? Ya sea sistemas operativos, redes, o bases de datos, como solo lenguajes de programación y teoría de lenguajes de programación, ¿verdad? Así que tratando de cubrir tantas áreas o niveles de abstracción, lo cual es muy divertido. Y luego comencé a construir muchos tipos diferentes de cosas, muchas aplicaciones diferentes. Solía trabajar como consultor cuando comencé mi propia firma de consultoría también, donde construía muchos tipos diferentes de aplicaciones, ayudaba a las personas a modernizar incluso aplicaciones existentes o aplicaciones existentes en un estilo más moderno. Eso fue donde comencé a involucrarme mucho con Kubernetes y Docker, que también eran muy nuevos en ese momento.

Experiencia y Enfoque en el Stack

Short description:

Tengo experiencia trabajando en varias partes del stack, incluyendo bases de datos, servidores de aplicaciones y aplicaciones front-end. Encuentro esta área muy interesante y creo que hay mucho potencial para aumentar la productividad. Si bien solía enfocarme más en la infraestructura y DevOps, en los últimos años he cambiado mi enfoque a la mitad frontal del stack.

Así que eso me ha permitido tener la oportunidad de trabajar en muchas cosas diferentes. Y, ya sabes, mis áreas de interés terminan siendo más o menos la mitad superior del stack en el sentido de las bases de datos, servidores de aplicaciones, e incluso aplicaciones front-end. Esa parte del stack, sigue siendo muy interesante para mí. Siento que hay muchas cosas por hacer allí para aumentar la productividad. Así que esa es el área a la que estoy más cercano. Solía estar bastante en la infraestructura y en el espacio de Kubernetes y DevOps, y me he movido más hacia esta mitad frontal del stack en los últimos años. Eso es realmente increíble. En realidad, en el pasado, no era muy común comenzar a programar en la universidad porque incluso yo comencé a programar después de estudiar ciencias de la computación. Así que ahora, sí. Todo ha sido virtual, y se ha convertido en algo, realmente lo es. Sí, sí. Hoy en día, conozco a mucha gente que comenzó a programar muy temprano en su vida, ¿verdad? Y yo pienso, ¡eso es genial! Ojalá hubiera hecho eso. Pero sí, está bien. Al menos comenzamos a escribir código, así que eso es bueno. Eso es realmente increíble. Entonces, me gustaría decirle a la audiencia que si tienen más preguntas para Tanmay, aún pueden contactarlo en el chat especial y hablar directamente con él. Y también, todavía estamos esperando. Así que envíenos sus selfies con la configuración y cómo están viendo esta conferencia. Va a ser divertido. Recuerden que vamos a tener un sorteo al final del día, ¿verdad? Y muchas gracias, Tanmay. Fue una discusión realmente agradable y una charla muy profunda. Estoy seguro de que todos deben haber escrito mucho en su bloc de notas mientras veían la charla. Gracias de nuevo por unirte a nosotros. Gracias. Gracias por tenerme y es un gusto estar aquí. Adiós. Adiós.

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.