GraphQL en todas partes

Antes de entrar en eso, quiero contarles quién soy. Soy parte del equipo de Relaciones con Desarrolladores en Hasura. Hasura es una empresa de GraphQL. Lo explicaré en un momento. Llevo aproximadamente cinco años trabajando en Relaciones con Desarrolladores para GraphQL, y vengo de un trasfondo en productos y design. Algunas de mis observaciones serán, como describí en el título, una perspectiva desde el punto de vista de un constructor sobre lo que ha sido GraphQL, hacia dónde se dirige y principalmente desde la mentalidad de un constructor.

Mi nombre es Jesse Martin. Soy padre de cuatro hijos. Eso significa que soltaré varios chistes de papá durante esta charla. Me disculpo, pero en este momento no puedo evitarlo. También pueden encontrarme en MotleyDev. Verán ese nombre de usuario de Twitter en la parte inferior de la mayoría de mis diapositivas. Quién sabe cuánto tiempo eso seguirá siendo válido. Así que definitivamente únanse antes de que eso desaparezca. Pero quiero darles una breve descripción de quién es Hasura, la empresa para la que trabajo, porque eso dará un poco de contexto sobre de dónde vienen estas observaciones y este patrón.

En primer lugar, Hasura es básicamente una herramienta de código abierto. Y lo que hace es brindarte GraphQL en tus fuentes de datos. Puede ser una database u otras fuentes de data en este momento, y en realidad generaremos los puntos finales para ti, los resolvers y cosas así. Por supuesto, puedes personalizarlos y todo ese tipo de comportamiento. Pero en el nivel básico, hay una idea de un motor que interpreta un esquema y lo transforma en otro. Eso será realmente importante para que lo veamos más adelante. Piensen nuevamente en Hasura Engine y también en Hasura de código abierto. Me gusta decir, págamelo si quieres. Y lo que hace es brindarte controles de acceso muy robustos, y tenemos un modelo de empuje de predicados muy poderoso. Básicamente, la autorización se realiza al momento de la obtención de datos, por lo que no estás obteniendo datos de más de tu database. Puedes decir específicamente que queremos tener un conjunto de selección muy eficiente y conciso de nuestras fuentes de data subyacentes.

Y sí, también admite lógica empresarial personalizada, desencadenadores de eventos, acciones y todos esos tipos de comportamientos que esperarías de una herramienta de capa de datos. Pero el último punto que realmente quiero destacar, especialmente en momentos como estos, es que estamos contratando. Entonces, si realmente estás en el mercado, incluso si eres dev rel, quiero hablar contigo. Pero en realidad tenemos muchas vacantes en nuestro negocio. Y sí, estamos contratando, definitivamente contáctanos si es algo de tu interés.

Entonces, ¿dónde se sitúa esto en el panorama general? Bueno, verás que se encuentra en una capa donde la autorización y la autenticación ocurren externamente. Por lo general, se obtiene un JWT como el patrón más común. Y luego esos roles se aplican en el momento de la obtención de datos. Entonces, lo que realmente sucede es que haces una consulta, una consulta de GraphQL, y nuestro motor la mapea a lo que la fuente de datos subyacente entiende. En este caso, SQL, ¿verdad? Así es como nuestro motor opera a un nivel fundamental para permitirte hacer esto. Esto es un widget que tenemos en nuestra página de inicio. Puedes probarlo de forma interactiva si tienes curiosidad, y hay mucha más información disponible allí. Dije que es de código abierto, pero esto no es un proyecto secundario. Es una herramienta realmente grande. Tenemos versiones en la nube, versiones empresariales, y muchas empresas importantes que nos utilizan. Entonces, si estás buscando adoptar GraphQL a escala empresarial, contáctanos. Tenemos muchas herramientas interesantes que podrían ser de tu interés, y contamos con un equipo muy poderoso de go-to-market que está ahí para responder preguntas y ayudarte a comenzar. Así que echa un vistazo. Bueno, eso es todo por ahora sobre Hasura. Ahora quiero hablar de algunas suposiciones que son realmente importantes para tener en cuenta en esta charla. Lo siento, beneficios de grabar desde un estudio en casa, ¿verdad? Estas son algunas suposiciones que quiero que tengas en cuenta durante esta charla, y eso es básicamente que asumo que sabes un poco sobre GraphQL y para qué se ha utilizado hasta ahora. Realmente espero que sí, porque esto es una conferencia de GraphQL. Y la otra parte es que algunas personas en Internet se enojan por cosas realmente tontas. Esos son los dos puntos principales que debes entender para poder seguir adelante, y verás a qué me refiero más adelante. Pero primero, opiniones fuertes pero flexibles. Vuelvo a esta perspectiva de practicante. Estas son cosas que he visto en el mercado en varias empresas de GraphQL, tanto como proveedor de GraphQL como consumidor. Y eso es que las API REST siguen siendo muy preferidas por los proveedores de servicios individuales, personas que realmente van a lanzar una API para consumo general en el mercado.

Pero GraphQL es preferido por múltiples consumidores de servicios. Y vamos a analizar por qué es así. Pero quiero decir, en este punto, estás pensando, bueno, esa es tu opinión, hombre. Pero hay una razón por la que he visto esto. Y hay una razón por la que creo que esto es cierto. Y eso es, mira el ecosistema actual en torno a la construcción con APIs o la construcción con diferentes fuentes de datos. Y el desafío de acceso a datos se vuelve realmente complejo.

Tenemos varias fuentes de datos, varios microservicios, varias plataformas y otras herramientas que estamos tratando de unir. Y cada uno trae su propio SDK o ORM o algún otro concepto de API a la fiesta. Es agradable cuando tenemos una especificación de API abierta que muchas personas pueden adoptar. Pero a veces puede ser realmente irregular, como cualquiera que haya construido con APIs de aplicaciones sabe. Y así tenemos una situación en la que el desafío de acceso a datos es realmente problemático porque está disperso por todas partes. Y cuando miramos específicamente nuestros microservicios, esto se convierte en un problema muy pronunciado. Pero lo veremos más adelante, porque no quiero adelantarme aquí.

Y así, cuando lo pensamos, lo que sería realmente genial desde una perspectiva de acceso a datos es si pudiéramos simplemente usar estas APIs de datos y estos servicios y simplemente fusionarlos todos en una sola malla donde este servicio puede usar la misma API de la que es miembro para acceder a otras partes de los datos. Y así es un concepto del que estamos tratando de hablar, sobre esta idea de una sola API, donde GraphQL nos brinda esta capacidad de decir que tenemos una, una sola API que se federiza en todas estas piezas diferentes. Por lo tanto, este es un concepto realmente importante sobre por qué múltiples consumidores de datos son consumidores de múltiples datos realmente necesitan tener acceso a todo eso en una sola API porque es solo un punto final y un tipo de forma de consultar esos datos que les permite acceder a su contenido. Así que quiero profundizar un poco más aquí. Y la razón es que cuando miramos por qué REST se ha desarrollado de la manera en que lo ha hecho, o por qué la gente presume que REST cuando se trata de entregar una API, es porque es realmente fácil modelar en torno a los entregables, ¿verdad? Porque tienes un alcance bastante bien definido de qué datos estás enviando y tienes un alcance bastante bien definido en torno a cómo quieres que las personas accedan a esos datos. Pero tan pronto como tienes que modelar en torno a diferentes tipos de patrones de consumo, ves que GraphQL rápidamente se convierte en una herramienta favorita porque es realmente fácil modelar en torno a los consumibles, en torno a qué producto estoy tratando de construir y cuáles serán sus requisitos de datos. Y de repente, estoy con un gráfico y tengo que averiguar cómo obtener todas estas diferentes fuentes de datos de una manera fluida y amigable con los recursos. Ahora, usé la palabra modelar a propósito, porque cuando digo que es fácil modelar, es fácil modelar, pero no siempre es fácil implementar. Así que quiero hablar de eso también un poco más adelante. Echemos un vistazo nuevamente a cuál es el beneficio de GraphQL aquí. Esto es lo que me gusta llamar la Ley de Metcalfe para GraphQL. Y si no estás familiarizado con la Ley de Metcalfe, cuanto más nodos tiene un gráfico, más valor tiene, ¿verdad? Esta es la teoría de las redes sociales. Y así es muy similar con GraphQL, en el momento en que agregas más y más fuentes de datos, obtienes mucho valor de ello. Echemos un vistazo a algunos modelos abstractos aquí. ¿Cómo se desarrolla esto? Bueno, si miras algo como un montón de modelos de datos diversos, tenemos una scooter, un café y un usuario. Esto suena como un día realmente malo en Nueva York. Pero si tomas todos estos nodos diferentes y si los desarrollamos un poco más en piezas adicionales de contenido, ahora queremos incluir cosas como el clima y tal vez como estaciones de carga y ubicaciones y estado de la batería y otros tipos de piezas de estos datos, bueno, de repente estamos realmente mirando un motor de recomendación para, hey, estás cerca de esta cafetería y necesitas cargar, ¿por qué no pasas, cargas tu scooter y tomas un café? O cualquier otro comportamiento.

El valor que podemos construir y extraer de conjuntos diversos de datos se vuelve realmente poderoso. Y la razón por la que GraphQL nos resulta tan útil es que para orquestar esto, hay menos sobrecarga, porque simplemente he fusionado todas las piezas en una sola API, tengo un plano de control más pequeño, no tengo que preocuparme por enviar mis variables de entorno y todo lo demás. Tengo patrones reutilizables que puedo usar una y otra vez en diferentes herramientas. Y es totalmente agnóstico a la aplicación consumidora, ya sea que esté desarrollando una aplicación para Android, iOS o cualquier otra plataforma, eso no importa. Y esa parte agnóstica es realmente crítica, porque estoy argumentando que esa API tiene valor para nosotros en diferentes contextos, no solo para consumidores de la interfaz de usuario.

Bien, profundicemos un poco más en los modelos teóricos aquí. Lo que tenemos aquí es una estructura de servicio GraphQL común, ¿verdad? Tienes tus operaciones de lectura, como ordenar productos, y luego las mutaciones, como iniciar sesión, cerrar sesión, realizar una compra y editar pedidos. Y luego tienes servicios SQL o servicios REST identificados para los datos que necesitas en un lado, y en el otro lado, tienes microservicios para iniciar sesión, cerrar sesión y restablecer contraseñas. Así es como se combinan estos datos. Verás que las dependencias de datos de algo como un modelo de compra requieren acceso a todos estos datos. Pero algo como un modelo de compra podría estar protegido, ¿verdad? Porque estamos hablando de modificar una base de datos o insertar contenido, o queremos tener datos que potencialmente interactúen con nuestra base de datos, por lo que queremos tener estas dependencias federadas de datos en el contexto en el que se ejecute nuestro servicio. Entonces, si ese servicio es una compra, aún necesitamos los datos del usuario, el pedido y el producto, pero ¿por qué no podemos acceder a esos datos en el momento de la ejecución? Hablaremos de algunas de las razones por las que dicen que no se puede, pero vamos a desglosarlo en un modelo menos abstracto.

¿Qué sucede si decimos que el modelo de datos con el que estamos trabajando es mucho más complejo? Tenemos, por ejemplo, el promedio de crédito de red, compras pendientes, ingresos históricos, historial de devoluciones de los usuarios, etc. Tenemos aquí un modelo de evaluación de riesgos. Estos son datos altamente protegidos. Nos gustaría poder obtener información de ellos como retroalimentación para determinar si una persona tiene una evaluación de riesgos para un puntaje crediticio o cualquier otra cosa. Necesitamos todos estos otros datos, que se encuentran en silos muy diferentes, para poder unirlos y realizar este cálculo ponderado. Lo que estoy argumentando aquí es que la consulta que proviene del cliente, desde el cliente de la interfaz de usuario, intentando obtener información sobre si está aprobado o no, lo que sea, ese mismo entorno protegido puede realizar una consulta en sí mismo con la misma API de datos que pude llamar desde mi cliente de interfaz de usuario, con el mismo punto final de API desde el servicio de evaluación de riesgos real hasta mi misma API GraphQL y obtener la imagen completa de datos que estoy buscando para poder realizar ese cálculo. ¿Por qué de repente necesito crear un entorno completamente nuevo para todos estos datos? Quiero poder acceder a estos datos en el lugar donde los necesito. Y si puedo hacer ese cálculo, puedo trabajar con todos los datos que necesito para mi cálculo, reduciendo la cantidad de viajes y todo lo demás que pueda necesitar. Bueno, esto no es solo teoría, ¿verdad? Esto es algo que vemos implementado todos los días, específicamente en Hasura, en el ámbito de la atención médica, en métricas DORA, en empresas de entrega de alimentos y en muchos otros servicios que tienen que lidiar con estos datos.

Ahora quiero presentar algunas opiniones disidentes y, como digo, todos tienen derecho a estar equivocados, pero uno de los argumentos es que no es para lo que se creó GraphQL. Yo argumento que, en realidad, es exactamente para lo que fue diseñado, para definir las dependencias de datos para una ejecución. Sí, no se creó en el contexto de la interfaz de usuario para reducir los datos a través de la red, pero se trataba de obtener los datos que necesitas en el contexto en el que los necesitas. ¿Y qué pasa con la latencia? Bueno, marginalmente más alta que potencialmente una API REST diseñada de manera óptima, pero eso también es un problema solucionable, así que quiero cubrir nuestro enfoque para eso. Cuando avanzamos aquí y hablamos de nuestras soluciones para eso, queremos mencionar los problemas, y no hay ninguno, así que podemos seguir adelante. Cuando hablamos de latencia, en realidad hay problemas solucionables para esto, pero esto es algo que debes tener en cuenta con el modelo de datos. Esto es cierto para cualquier API, pero en general, el usuario puede esperar, ¿verdad? Estaría dispuesto a esperar uno o dos segundos adicionales si el servicio funcionara correctamente la primera vez y no tuviera problemas en el lado de la API. La segunda parte es que las nuevas API, nuevos problemas. Potencialmente, estamos simplemente trasladando todos los errores o problemas que teníamos con los patrones de consumo de nuestros microservicios a un contexto completamente nuevo donde tenemos que construir toda esta nueva infraestructura para admitir el consumo de microservicios a través de GraphQL. Y aquí es donde realmente quiero hacer hincapié. Tenemos una nueva API, pero tenemos un héroe emergente.

Y así, Hasura se basa en esta experiencia que hemos tenido ayudando a los clientes a implementar estos patrones. Y ahora estamos presentando una nueva herramienta que nos gustaría que eches un vistazo. Y esa es precisamente la especificación de datos de GraphQL.

La especificación de datos de GraphQL, específicamente, es una descripción o DL que describe cómo podrían ser las fuentes de datos subyacentes. ¿Cómo podemos conectar estas fuentes de datos a través de diferentes puntos de entrada? ¿Cómo se ven los bordes? ¿Cómo se resuelve? Estamos abstrayendo la fuente de datos subyacente en este momento. Usamos un esquema de base de datos. Lo estamos abstrayendo en decir, vamos a tener una DL real que podemos alimentar a un motor. Y ese motor nos permitirá leer o crear las APIs que necesitamos desde GraphQL para admitir esto.

Entonces, esta especificación dice que la ejecución de microservicios es genial, la ejecución en el front-end es genial. Pero la imagen más grande aquí es definir cuáles son tus necesidades de datos. Así que usa una herramienta como esta, usa una herramienta donde puedas definir toda tu capa de datos dentro de una DL, y luego alimenta eso en un motor y realmente poder interpretar y crear el contenido que necesitas. Es una forma realmente poderosa de trabajar.

Esto es una solicitud muy, muy alfa para recibir comentarios, involúcrate, es algo impulsado por la comunidad que estamos lanzando aquí. Nos encantaría que te involucraras y nos hicieras saber cuál es tu opinión. Puedes probar este playground aquí. Dejaremos los enlaces en el chat donde puedes encontrarlo y probarlo por ti mismo. Así que es la especificación de datos de GraphQL. Por ahora, está en el repositorio de GitHub de Hasura. Puedes encontrarlo allí. Pero nos encantaría que le echaras un vistazo.

Dicho esto, esta es mi última diapositiva. Quiero agradecerte mucho por venir hoy. Si tienes alguna pregunta, no dudes en hacerla en el chat y trataré de responder. Pero nuevamente, muchas gracias por ver esta charla. Sé que fue rápido. Sé que hubo algunas ideas interesantes. Pero si tienes alguna pregunta, encuéntranos en Discord. Encuéntranos en nuestra comunidad, en los problemas de GitHub y en todo lo demás. Prueba Hasura. Usa Hasura cloud. Es la forma más rápida de comenzar con Hasura. Hay un nivel gratuito disponible. Pero creemos que te encantará. Y estamos ansiosos por escucharte y verte en la comunidad. Que tengas un excelente resto de conferencia.