Evaluando GraphQL para Configurar una Malla de Datos de Grado Empresarial

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.

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.

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.

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.

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.

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.

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.