1. Introducción a GraphQL y Servicios Existentes
Hola, bienvenidos a todos. Hoy presentaré casos de uso para GraphQL con servicios existentes y código heredado. Exploraremos cómo hablar GraphQL con servicios existentes, específicamente en el contexto de una plataforma de comercio electrónico. La plataforma utiliza JavaScript, React, una API REST y una base de datos. Discutiremos los desafíos de usar REST y los beneficios de usar GraphQL para conectar todos los componentes juntos.
¿De qué trata esta charla? Durante hoy, les presentaré algunos casos de uso para
GraphQL también con servicios existentes. Veamos cómo se ve el código heredado. ¿Parece algo así, verdad? ¿O es esto realmente PASTA? No estoy seguro si saben, pero ¿cuándo fue la última vez que intentaron hablar con PASTA? Para mí, nunca. Así que supongamos que vamos a estar viendo servicios existentes como código heredado. Un poco sobre mí. Mi nombre es Roy. Pueden encontrarme en Twitter con el equipo de Github. Actualmente trabajo para una empresa de energía renovable llamada Vanderbrand, anteriormente trabajé para muchas compañías diferentes, incluyendo la ciudad de Ámsterdam, más recientemente, donde creamos proyectos de código abierto para la ciudad. Y también pueden encontrarme en línea en YouTube con videos de conferencias anteriores o algunos de mis libros sobre
React o
React Native. Y en el tema de hoy, mi libro más reciente sobre
Fullstack GraphQL. Este es un libro sobre cómo construir servidores y clientes
GraphQL con
React,
Node.js y
TypeScript. Así que si tienen alguna pregunta después, asegúrense de hacerla.
Para hoy, vamos a ver cómo pueden hablar GraphQL con servicios existentes. Así que supongamos que comienzan a trabajar en este gran proyecto, acaban de ser contratados en un nuevo trabajo, o tal vez un nuevo proyecto comienza en su empresa actual. Y este se llama la plataforma de comercio electrónico del futuro. Probablemente hayan sido abordados por reclutadores que tenían algo similar a esto, como `oye, vamos a construir la plataforma de comercio electrónico del futuro, queremos que formes parte de ella`. Bueno, supongamos que cayeron en esta trampa y comenzaron a trabajar en una empresa que va a construir esta plataforma. Esta podría ser la pila de tecnología, ¿verdad? Tenemos, a la izquierda, un ejemplo de interfaz de usuario y a la derecha, las tecnologías. Así que está utilizando JavaScript y React, lo cual parece bien. Y luego utiliza una API REST con una base de datos y una base de datos como backend. Entonces, tal vez después de ver esto, están pensando que es una plataforma de comercio electrónico, pero podría no ser la plataforma de comercio electrónico del futuro. Si piensan eso hasta ahora, está bien. Si piensan que todavía es la plataforma de comercio electrónico del futuro, también está bien, porque podríamos encontrar otra forma de utilizar esta plataforma y hacerla a prueba de futuro. O también podrían pensar que la API REST y la base de datos juntas son como el plato de espagueti que vimos antes, que es el código heredado con el que vamos a interactuar. Aún así, tenemos algo de código heredado en el backend, tenemos JavaScript y React, y de alguna manera queremos conectar todo esto con GraphQL, porque si se utiliza REST, va a generar varios problemas, ¿verdad? Porque esta podría ser la API REST, tienen tres solicitudes diferentes, o tal vez incluso más, y todas estas solicitudes serán llamadas por su interfaz de usuario. Cada parte de nuestra interfaz de usuario utiliza una llamada separada a la API REST, lo cual al final será problemático para las personas que utilizan internet móvil. Y esto a menudo está directamente relacionado con una base de datos.
2. Usando GraphQL con Servicios Existentes
Entonces, cada tabla en tu base de datos tendrá una llamada de API separada que devuelve JSON. Queremos evitar solicitudes separadas, análisis y normalización en la interfaz de usuario. Encontremos una forma de usar GraphQL con el backend sin modificar el código heredado. Una opción es utilizar bibliotecas existentes como GraphQL Mesh. Otro enfoque es crear nuestra propia capa de datos, proporcionando un acceso simplificado al código heredado mediante GraphQL. Esto ayuda con el almacenamiento en caché, el monitoreo y evita errores en los cambios del código heredado.
Así que tenemos una API REST y tenemos
database, y están estrechamente vinculados. Entonces, cada tabla en tu
database tendrá una llamada de API separada que funcionará así en la interfaz de usuario. Y todas estas llamadas de API también devolverán JSON, que podría ser mucho JSON, y en realidad estás utilizando pequeñas partes de este JSON. Entonces, una vez que hayas visto esto, probablemente estés pensando que deberíamos comenzar a usar
GraphQL para esto, y eso es exactamente lo que vamos a ver hoy. No queremos hacer esto, tener todas estas solicitudes separadas que devuelven mucho JSON, todo eso debe ir a nuestra interfaz de usuario, debe ser analizado, debe ser normalizado. Eso es algo que definitivamente quieres evitar.
Esto se puede hacer de manera más eficiente, como ya vimos, y esto, por supuesto, es con GraphQL. Pero el servicio aún no está utilizando GraphQL. Entonces, intentemos encontrar una forma de hacer que este servicio backend interactúe utilizando GraphQL con nuestra interfaz de usuario frontend. Y hagámoslo de tal manera que no tengamos que modificar el código heredado o la PASTA o el Espagueti o cualquier otra cosa que esté allí en el backend. Entonces, lo que queremos evitar es tener que modificar cualquier cosa que haya sido construida por desarrolladores anteriores. Tienes varias opciones para hacer esto. Y creo que una de las mejores opciones es utilizar bibliotecas existentes, porque va a eliminar muchas cosas. Va a evitar que cometas errores, va a evitar que tengas que mantener otro servicio. Y para esto, definitivamente te recomendaría usar GraphQL Mesh. Creo que Uri Goldstein también es un orador hoy, o tal vez ya presentó. No estoy seguro. Al menos Uri probablemente hablará un poco sobre GraphQL Mesh y cómo puedes usarlo. Y si quieres evitar escribir código personalizado, definitivamente es una opción a considerar. Pero hoy vamos a ver un enfoque diferente. Y esto es creando tu propia capa de datos o capa de acceso a datos. Y utilizando esta capa, podrás usar GraphQL para tus servicios backend sin tener que cambiar esos servicios. Es similar a lo que hace GraphQL Mesh, excepto que vamos a ser dueños de todo el flujo de datos. Vamos a ser dueños de toda la lógica allí. Y en caso de que no estés familiarizado, una capa de acceso a datos o capa de datos es una capa de un programa informático que proporciona un acceso simplificado a los datos de esa superficie.
Entonces, lo que haremos es construir una capa de datos que proporcione un acceso simplificado utilizando GraphQL sobre nuestro código heredado. Esto nos ayudará a hacer muchas cosas diferentes, como el almacenamiento en caché, el monitoreo, pero también evitará que cometamos errores al realizar cambios en el código heredado que se ejecuta, pero de alguna manera nadie sabe cómo se ejecuta, lo cual a menudo es el caso con el código heredado por supuesto. Esta es la pregunta que te puedes hacer, ¿por qué debería crear una capa encima de una superficie que ya existe y funciona perfectamente bien? ¿Por qué deberíamos hacer eso? Porque mi API ya es una capa de datos? Porque probablemente tu código heredado ya proporciona una API con una interfaz que te dará todos los datos que necesitas. Pero vamos a crear una capa de datos encima de una capa de datos. Puede que te sientas como en una película de Inception ahora mismo porque de alguna manera estamos creando algo encima de algo, o tal vez ya está dentro de algo. Así que algo a tener en cuenta
3. Implementando la Conversión de Documentos GraphQL a Datos
Para usar GraphQL con servicios existentes, necesitamos enviar un documento GraphQL al servidor, que lo convertirá en un árbol de sintaxis abstracta (AST). Luego, el AST se compara con el esquema de GraphQL y los resolvers recuperan los datos. El servidor responde con una salida JSON que contiene los datos solicitados. Si bien las bibliotecas existentes como GraphQL Mesh pueden manejar este proceso, también es posible construir una capa de datos de código personalizado. Sin embargo, es importante considerar el potencial de aumento del código heredado. La construcción de la capa de datos comienza con los propios datos, que se utilizan para crear los resolvers y el esquema. En última instancia, necesitamos un servidor para enviar el documento GraphQL y recibir los datos. Hay varios enfoques para construir la capa de datos.
Piensa en esto durante el resto de esta charla. Entonces, ¿cómo pasamos de un documento
GraphQL a datos? Porque eso es lo que queremos, ¿verdad? Queremos enviar el documento
GraphQL a nuestro servidor y queremos que el servidor devuelva los datos de nuestro código heredado. Y podría verse así, ¿verdad? Así que vimos anteriormente las tres llamadas separadas a la API REST, y lo que realmente queremos hacer en lugar de enviar esas llamadas a la API REST, es enviar la consulta y queremos que se devuelvan estos datos de una manera en que los hayamos formateado, porque eso es lo que hace
GraphQL. Entonces, de alguna manera queremos pasar de un documento, que ves a la derecha, a los datos que tenemos a la izquierda. Y esto está perfectamente bien porque esto es lo que hace
GraphQL y así es como
GraphQL lo hará por nosotros. Entonces veamos cómo podemos implementarlo realmente. Es haciendo esto. Entonces, el primer paso es enviar un documento
GraphQL, que ya puedes ver tachado. Y este documento
GraphQL se convertirá en un árbol de sintaxis abstracta. Entonces, básicamente, ¿qué es esto? Es una representación de cualquier documento que estés enviando. Entonces, estamos enviando un documento que contiene una operación, que es una consulta. Contiene campos como campos de nivel superior que son productos, pero también campos de nivel inferior como título, relaciones o categorías. Todo esto se analizará en un árbol de sintaxis abstracta que puede ser utilizado por el esquema de
GraphQL y el servidor de
GraphQL para averiguar cómo se relacionan estas cosas. Entonces, tu servidor estará en tu esquema. Tendrá un papel vital aquí porque habrá información sobre resolvers, conexiones, todas estas cosas. Esto se describirá en tu esquema y también en el servidor en general. Y luego, lo último que sucederá es que los resolvers recuperarán los datos. Entonces, en función del documento que envíes, se convertirá en un ASD, y ese ASD se comparará con tu esquema. Y finalmente, terminará en tus resolvers que recuperarán los datos. Entonces, el documento que inicialmente enviaste al servidor será respondido con una salida JSON con exactamente esos datos. Esto es brevemente cómo debería funcionar y cómo funcionará con
GraphQL. Y si usas bibliotecas existentes como la cosa de
GraphQL Mesh, ya lo hará por ti sin ningún problema. Pero hoy vamos a ver cómo podemos construir esto nosotros mismos con código personalizado, que al final, creo, es la mejor opción. Porque las capas de abstracción son geniales, pero también te dan el riesgo de terminar con aún más código heredado. Es algo en lo que siempre debes pensar. ¿Lo voy a hacer yo mismo, o voy a usar una biblioteca existente que ya haga parte del trabajo pesado por mí? Y la construcción de la capa de datos alrededor de los datos funciona al revés, ¿verdad? Porque ahora nuestro punto de partida fue el documento, pasó al árbol de sintaxis abstracta, pasó al esquema y al servidor, y al final, los resolvers obtuvieron los datos. Pero si quieres tener una capa de datos, en realidad tus datos son el punto de partida, porque necesitamos tener los datos para construir los resolvers y el esquema, para que realmente tengas un servidor al que enviar el documento. Porque necesitaremos este servidor, de lo contrario no podremos usar operaciones de
GraphQL como la consulta que vimos antes para obtener nuestros datos. Y construir la capa de datos, como te dije, es exactamente al revés. Entonces, tenemos nuestros datos como punto de partida y terminaremos con un servidor que puede aceptar documentos y que recibirá nuestros datos al final. Y para esto, hay varias formas en las que puedes ir.
4. Code First, Resolver First, or Schema First
Code first o resolver first significa no construir un esquema como punto de partida. Schema first es otra opción. La discusión entre code/resolver first y schema first es importante para que los equipos de proyecto determinen cómo manejar los datos y los flujos de datos.
Es posible que hayas oído hablar de code first o resolver first. Por lo general, son las mismas dos cosas. Básicamente, significa que no construyes realmente un esquema como punto de partida, sino que pensarás en el código existente, los resolvers existentes, cómo manejar o recuperar tus datos. Otra forma de hacerlo es schema first. Entonces, ambas podrían ser opciones, como la opción de code o resolver first, o schema first. Y todo depende de lo que quieras ver como punto de partida. Más sobre esto más adelante. Pero creo que la discusión de code y resolver first es algo bueno tener, o schema first, cuando tomes un proyecto de este tipo con tu equipo, porque necesitas saber cómo manejar los datos, cómo manejar los flujos de datos, y si trabajarás con una solución de code o resolver first, o tal vez un esquema.
5. Mapping Data Specification to GraphQL Schema
El punto de partida siempre debe ser la fuente de verdad para tus datos. Si tienes una API REST existente o una API heredada, esa será la fuente de verdad. Puedes usar definiciones de Swagger u otras definiciones de API abiertas para tu API, o un esquema JSON para tu base de datos. Si no tienes una fuente de verdad, se recomienda ir primero con el esquema. Mapea la especificación de datos a un esquema de GraphQL utilizando la fuente de verdad. Puedes usar paquetes como GraphQL Mesh o crear el esquema tú mismo. Al construir sobre una API REST o una base de datos, considera la correspondencia uno a uno y las normalizaciones para determinar la fuente de verdad.
La solución primero. Y el punto de partida siempre debe ser la fuente de verdad para tus datos. Entonces, si tus datos existentes son una API REST o una API heredada, esa será la fuente de verdad. Entonces, tu API podría tener definiciones de Swagger que puedes usar u otras definiciones de API abiertas. Podría devolver algún tipo de esquema en forma de JSON, tal vez con el esquema JSON. Si es una base de datos, podrías tener documentos de migración, tal vez con MongoDB, podrías tener modelos de Mongoose, lo mismo para cualquier otro tipo de base de datos. Entonces, el punto de partida al hacer esto debe ser cualquier fuente de verdad para tus datos. Y si no tienes una, eso será un poco más difícil. Y si no tienes una fuente de verdad para tus datos, siempre recomendaría ir primero con el esquema, porque entonces tu esquema será la fuente de verdad para tus datos. Y si ya tienes una fuente de verdad, puedes usar Swagger, OpenAPI o modelos de Mongoose para crear los resolvers en código primero.
Entonces, lo que necesitamos hacer es mapear la especificación de datos a un esquema de GraphQL. Y esto es más fácil de lo que piensas. Porque hay paquetes para hacer esto, como el maestro de GraphQL antes mencionado. Pero si no los hay, y de hecho encontré un caso de uso yo mismo, porque hace poco comenzamos a trabajar en una implementación de Salesforce. Y si conoces Salesforce, tienen APIs REST, pero no vienen con Swagger. Así que vienen con su propio punto de descripción, que sigue el esquema de la API JSON. Así que necesitábamos crear todo nosotros mismos, pero teníamos una fuente de verdad. Esa es la parte importante. Sin una fuente de verdad, será muy difícil hacer esto. Y siempre debes optar por un enfoque de esquema primero. Pero si no lo haces, simplemente puedes optar por un enfoque de código o resolver primero. Pero lo que debes hacer es usar la fuente de verdad, ya sea que la tengas o no, para especificar un esquema de GraphQL, ya sea a través del código primero, donde definimos los resolvers primero que crean nuestro esquema, o creando directamente el esquema.
Y esto podría verse así, ¿verdad? Porque anteriormente vimos que tenemos una API REST, que es nuestro proyecto heredado. Y queremos poder tener una capa de datos en la parte superior de esta API REST para obtener nuestros datos en GraphQL. Y en la vanguardia de esta base de datos, de esta API REST, también hay una base de datos. Entonces, hay dos formas en las que puedes proceder aquí. O bien vas a construir sobre tu API REST, o vas a construir sobre tu base de datos. Y cuál debes seleccionar realmente depende de muchas cosas. Pero puedes imaginar que si tu API REST es una correspondencia uno a uno de la base de datos sin ninguna normalización, debes usar la base de datos como tu fuente de verdad. Pero si tu API REST tiene efectos secundarios, es decir, en lugar de simplemente obtener datos de la base de datos, también realizará normalizaciones, tal vez llamar a otras APIs, entonces definitivamente debemos tomar la API REST como fuente de verdad. Y si tienes suerte, esta API REST tendrá un Swagger
6. Mapeando Endpoints al Esquema y Creando Resolvers
Para usar GraphQL con servicios existentes, debes mapear los endpoints a un esquema. Esto se puede hacer manualmente o utilizando bibliotecas como GraphQL JS. Si no tienes una fuente de verdad para la API, deberás encontrar una forma de mapearla a un tipo de objeto GraphQL. Un ejemplo es utilizar los endpoints descritos de Salesforce y un esquema JSON para crear el esquema de GraphQL. Una vez creado el esquema, puedes crear resolvers para obtener datos de la fuente original, ya sea una API REST, una base de datos como MongoDB o Salesforce. Los resolvers se pueden crear utilizando tipos de objeto GraphQL y pueden acceder a información del objeto padre, argumentos, contexto y objeto de información. El objeto de información proporciona información detallada sobre el Árbol de Sintaxis Abstracta (AST). Hay varias formas de abordar la creación de resolvers, incluyendo un enfoque de código primero o resolver primero.
o esquema adyacente. Y si no lo tiene, deberá verificar todos los endpoints que desea utilizar y crear un esquema a partir de estos endpoints. Podría verse algo así porque tenemos una API REST con alguna definición, y es posible que desee trasladar esto a un esquema o a algún tipo de definición de esquema. Para esto, en realidad opté por el enfoque de
GraphQL JS utilizando tipos de objeto
GraphQL para definir mi esquema de esta manera. Y aquí también puedo definir resolvers o variables que deseo aceptar. Pero es solo como el mapeo básico. Y este mapeo se realiza con el conocimiento de que es posible que no tengamos una fuente de verdad para esta API, porque una fuente de verdad podría estar desactualizada, algo que a menudo se ve en proyectos que utilizan Swagger. Es mucho trabajo manual si no utilizas las bibliotecas adecuadas. Así que supongamos que lo único que tenemos es la solicitud y tal vez alguna documentación menor en nuestro lado. Entonces tendrías que encontrar una forma de mapear esto a un tipo de objeto
GraphQL, por lo tanto, a un esquema o a cualquier biblioteca que utilice un enfoque de código primero. Pero por esta vez, lo creamos manualmente de esta manera. Entonces, un ejemplo de mi proyecto, utilizamos los endpoints descritos de Salesforce con un esquema JSON para crear el esquema de
GraphQL a partir de eso. Básicamente se ve así. Entonces, el mapeo es uno a uno y solo insertas los campos que deseas utilizar. Y una vez que hayas hecho esto, podrás crear resolvers para obtener los datos de nuestra fuente original. Entonces, en esta solución, será una API REST o mi solución podría ser Salesforce. Pero incluso si estás utilizando una
database, tal vez
Mongo para ser un Mongoose, entonces los resolvers estarán obteniendo los datos de una
database. Entonces, tus resolvers deberían poder obtener los datos que coincidan con el esquema. Y básicamente se ve así. Así que opté por un enfoque antiguo y agradable con tipos de objeto gráficos para crear el esquema y este esquema también puede incluir resolvers. Entonces, aquí puedes ver que he creado uno para producto que se relaciona con mis endpoints de la API REST de producto. Y ahí, hay un resolver que llamará a alguna clase, método o función para obtener el producto basado en una idea que obtengo del resolver. Entonces, el resolver está obteniendo cierta información que obtiene el objeto padre, los argumentos, el contexto y también el objeto de información. Y el objeto de información puede ser bastante útil para explorar más en detalle si optas por este enfoque, porque el objeto de información siempre conocerá toda la información que tienes sobre el AST, el Árbol de Sintaxis Abstracta. Así que es interesante echarle un vistazo más adelante. Sí, lamentablemente, no tenemos tiempo para esto hoy, pero creo que hay muchas más cosas que investigar al respecto. Y creé otro para categoría, y puedes ver que utiliza el objeto padre para obtener la categoría de un determinado producto. Así que esto es sobre el resolver. Entonces, una vez que tienes el esquema y tienes una fuente de verdad que has creado utilizando el esquema, también puedes usar este esquema para crear resolvers de una vez. Y si estás utilizando diferentes soluciones, por ejemplo, si estás utilizando
TypeScript, es posible que desees optar por el enfoque de código o resolver primero, y luego el esquema se generará automáticamente una vez que crees los resolvers. Así que hay varias
7. Elegir la Solución Correcta para Servicios Existentes
Entonces, al decidir qué solución elegir para utilizar servicios existentes con GraphQL, considera las opciones disponibles. La biblioteca GraphQL Mesh es una excelente opción si tienes una fuente de verdad existente y no requieres personalizaciones extensas. Sin embargo, si deseas construir una capa de datos sobre tu código heredado sin crear más código heredado, es importante tener discusiones con tu equipo. Puedes utilizar una fuente de verdad para crear una capa GraphQL y conectar servicios utilizando el esquema stitching o federaciones.
formas de abordar esto. Entonces, creo que una pregunta importante que debes hacerte es, ¿qué solución debería elegir? Creo que te brindé una visión general muy amplia sobre cómo puedes utilizar servicios existentes y hacer que hablen con
GraphQL. Por supuesto, mencioné una biblioteca llamada
GraphQL Mesh, que Yuri probablemente también mencionará hoy, o tal vez ya la haya mencionado. Y esto es genial si tienes una fuente de verdad existente y estás bastante seguro de que no quieres hacer muchas personalizaciones en ella. Aunque hay opciones para agregar resolvers personalizados. Pero en general, creo que mi enfoque fue que deberías utilizar tu código heredado existente, tomar una fuente de verdad y luego tratar de descubrir qué quieres usar o no quieres reutilizar, y luego cómo puedes crear un esquema a partir de ello. Porque al final, tu esquema o tu resolver debería definir el modelo de datos para un servidor
GraphQL. Y no todos los servidores realmente les gusta este enfoque, porque es posible que estés utilizando cosas más antiguas como SOAP. O si estás utilizando REST y no tienes una definición de Swagger, entonces deberías hacer todo esto por ti mismo, lo cual creo que también se puede hacer manualmente. Puede automatizarse si utilizas la respuesta de cada punto final. Pero es una discusión muy importante que debes tener con tu equipo cada vez que comiences a trabajar en un proyecto como este. Entonces, deseas construir una capa de datos sobre tu código heredado, pero no quieres crear más código heredado. Entonces, si lo haces todo personalizado, entonces podrías crear mucho código heredado. Pero si inviertes en una biblioteca existente, entonces tienes menos personalizaciones que puedes hacer. Y también, si deseas tener efectos secundarios en tu biblioteca, entonces, por supuesto, necesitas construir uno personalizado tú mismo. Entonces, estas son cosas muy importantes para discutir de antemano. Pero espero que obtengas algún tipo de idea de cómo puedes utilizar una fuente de verdad para crear una capa
GraphQL sobre ella. Y para mí personalmente, el enfoque para Salesforce requirió muchas personalizaciones, pero al final, creo que también es un buen enfoque para usar y poder utilizarlo para todos nuestros servicios. Y al final, tan pronto como construyas un gráfico sobre un tipo de código heredado, por supuesto, puedes utilizar el esquema stitching o federaciones para conectar los servicios con todos los demás servicios también.
Q&A y Desafíos de la Pila Heredada
Si quieres saber más sobre esto, tenemos tiempo para preguntas y respuestas. Puedes encontrarme en Twitter y YouTube. Echa un vistazo a mi libro en línea para obtener contenido interesante y el primer capítulo gratis. Gracias por tu tiempo. ¡Hola, Rai! Usé Notepad+++ y me encantó su integración FTP. Tiempos más simples cuando podías escribir directamente en producción. Incorporar GraphQL en una pila heredada está inspirado en trabajar con código heredado. Es un caso de uso común cuando el backend no quiere cambiar. Conectar sistemas dispares con diferentes métodos de autenticación es un problema clásico. La lucha de agregar una capa de datos sobre servicios existentes es un desafío común al implementarlo.
Entonces, si quieres saber más sobre esto, creo que tenemos tiempo para preguntas y respuestas, o simplemente puedes ir a mi página de Twitter y hacerme una pregunta allí. Y asegúrate de encontrarme también en YouTube. Y por supuesto, si quieres saber más sobre GraphQL, asegúrate de encontrar mi libro en línea, porque hay mucho contenido interesante allí y puedes obtener el primer capítulo gratis para ver si te gusta o no. O nuevamente, simplemente encuéntrame en línea y haz las preguntas allí. Así que sí, muchas gracias por tu tiempo. Hola. Hola, Rai! Hola. Entonces, mi primera idea también fue Notepad+++. Oh, solo tienes tres signos más en ese. Sí, solo estaba pensando. Creo que el tercer más fue cuando descubrí que también podías vincular FTP a él. Podías enviar tu código directamente al servidor. Sí, suena bastante bien. Sí. Cuando podías escribir en producción, eso era genial. En muchos sentidos, una época más simple. Sí, esos eran los tiempos. Solo actualizabas producción. Sí, ahora es de un proyecto a otro. ¿Cómo entraste a la sala del servidor? Entonces, sí, ¿qué te inspiró a hacer esta charla sobre la incorporación de GraphQL en una pila heredada? Trabajar con código heredado. Creo que todos lo hicieron. Sí, en mi caso, el último proyecto que hice fue principalmente en el frontend, y queríamos cambiar cosas en el backend, pero el backend todavía no quiere cambiar nada. Así que terminamos construyendo algo a su alrededor. Sí, creo que es un caso de uso muy común. No fue hasta hace poco, de hecho, que hice un sistema GraphQL desde cero, que escribía directamente en una base de datos. Siempre ha sido un caso de, como, mira, tenemos siete sistemas dispares diferentes, ¿no sería genial si hubiera un gráfico para conectarlos? Además, todos tienen diferentes métodos de autenticación. Sí, suena interesante. Son problemas clásicos. Sí. Entonces, ¿cuáles crees que son las luchas más comunes que tienen las personas cuando intentan agregar una capa de datos sobre servicios existentes? En tu experiencia, ¿cuál ha sido la principal causa de problemas? ¿Al implementarlo o las razones para implementarlo? Ah, al implementarlo.
Authentication, Caching, and Normalizations
La autenticación y el almacenamiento en caché son factores importantes al trabajar con sistemas heredados. Puede ser desafiante asegurar que los datos se mantengan actualizados sin una fuente confiable. Existen herramientas como GraphQL Mesh y servicios como Azure que automatizan este proceso, pero construirlo uno mismo puede ser gratificante. Si bien el uso de GraphQL no siempre resulta en mejoras de rendimiento, el enfoque se centra en la experiencia del desarrollador y las herramientas disponibles. La decisión de agregar una sección intermedia depende de las normalizaciones requeridas y la complejidad de fusionar datos de múltiples APIs.
Creo que una de las cosas más importantes es la autenticación y el almacenamiento en caché. La autenticación, probablemente porque el servidor que estás envolviendo, por supuesto, debes entenderlo, y el almacenamiento en caché porque quieres asegurarte de que no se desincronice. Por lo tanto, quieres hacer algún tipo de almacenamiento en caché, pero tampoco quieres que tus datos estén desactualizados. Si estás trabajando con un sistema heredado y no proporcionan un texto electrónico o algo así, será bastante difícil asegurarte de tener datos recientes. Excelente. ¿Crees que hay alguna nueva herramienta técnica que saldrá y que crees que facilitará este proceso? Sí, hay muchas cosas. Creo que Jiri Goldstein también dio una charla y creó algo llamado GraphQL Mesh, que es genial para esto. Y, por supuesto, también podrías usar Azure y creo que hay otros servicios que también lo hacen. Y todos lo automatizan por ti, pero nuevamente es algo por lo que podrías tener que pagar y también es divertido construirlo tú mismo. Genial. Bueno, vamos a tomar una pregunta de Juan. En el ejemplo que nos mostraste, seguiríamos recibiendo todo el conjunto de datos de la llamada RESTful. ¿La diferencia sería que todo el conjunto de datos se recibiría en un lugar intermedio, que solo devolvería lo que se solicitó desde la interfaz de usuario a través de GraphQL? Sí, eso es correcto. En cuanto al rendimiento, puede que no sea la mejor mejora. Pero creo que lo que quería mostrar es que puedes utilizar la experiencia del desarrollador y las herramientas disponibles alrededor de GraphQL en lugar de hacer el servidor más eficiente, porque sí, para hacerlo más eficiente, por supuesto, debes cambiar el código heredado, lo cual es algo que generalmente no puedes hacer. Y hay una pregunta de seguimiento a esta pregunta, que es en este caso, ¿cuándo agregarías esta sección intermedia y cuándo no lo harías? ¿Cuándo lo agregarías? Creo que depende del tipo de normalizaciones que necesites hacer. Anteriormente hicimos un proyecto de código abierto para la ciudad de Ámsterdam. Y todas las APIs que consumimos también eran de código abierto. Por lo tanto, estaban disponibles para una amplia gama de cosas. Algunas personas las estaban utilizando para comunicación entre máquinas. Otras personas estaban utilizando algunas partes de ellas. Y la reconstrucción de la plataforma tomó alrededor de 20 de estas APIs con alrededor de 80 llamadas diferentes y las normalizamos, las fusionamos todas juntas. Estas son cosas que no queríamos hacer en el backend, pero también son cosas que no quieres hacer en el frontend. Porque no sé, si tienes que analizar como 20 llamadas diferentes a la API, fusionar los datos juntos, es realmente
Selling GraphQL and Conclusion
Cuando se vende GraphQL como enfoque para gestionar servicios, es importante considerar sus beneficios para aplicaciones orientadas al cliente. El uso de GraphQL en lugar de forzar una API REST puede proporcionar una mejor experiencia. Gracias por sus preguntas. No hay más preguntas del público. Si viste mi charla, espero que comiences a usar GraphQL desde cero y conectes tu base de datos a él. Intentemos todos GraphQL hoy. ¡Gracias y saludos!
algo que quieras evitar que haga. Por lo tanto, realmente depende de- Perdón, tuve una llamada telefónica que tuve que silenciar. Lo siento mucho. De acuerdo. Bueno, gracias por esa pregunta. Y perdón por mi rudeza. Oh, debería haber puesto eso en silencio hace mucho tiempo. En realidad, fue mi iPad que sonó porque puse mi teléfono en silencio. Pero aparentemente, si tienes un iPhone, también suena tu iPad. Sí, es realmente molesto. Y tarda mucho en detenerse. Así que cuando mi teléfono suena y al final de mi configuración de AirPods, todavía suenan las MacBooks y los iPods, el iPad y luego el teléfono. Sí. Voy a apagar esto rápidamente. Entonces, sí. Cuando vendes esta idea, supongo que debería reformular esto. ¿Tienes algún consejo para vender este enfoque, esta tecnología frente a otras formas de gestionar tus servicios si estás tratando de interesar a un cliente en esta pila tecnológica? Sí, esa es una pregunta con muchas respuestas, creo. Pero generalmente creo que usar
GraphQL para aplicaciones orientadas al cliente es algo que debes hacer. Porque si intentas forzar una API REST en una aplicación orientada al cliente, creo que es algo... Bueno, no creo que tenga beneficios para todos. De acuerdo. Maravilloso. Gracias por estas respuestas. He agotado mi montón de preguntas. Y no tenemos más preguntas del público. Así que este es tu turno al final. ¿Hay algo que te gustaría promocionar, mencionar, decirle a la audiencia? No, en realidad no. Creo que si viste mi charla, entonces espero que comiences a usar
GraphQL. Y espero que comiences a usarlo desde cero, y simplemente conectes tu base de datos a él. Así obtendrás la experiencia óptima. Espero que sí. Todos deberíamos probar
GraphQL hoy. Muy bien. Muchas gracias. Dejen sus aplausos en el chat para Roy. Y gracias nuevamente por venir. Saludos. ¡Adiós!
