Adoptando GraphQL en una Empresa

Hola a todos. Gracias por venir a mi charla. Hoy voy a hablar sobre la adopción de GraphQL en una empresa. Antes de comenzar, esto es lo que vamos a tratar. Vamos a hablar sobre por qué GraphQL puede ser una buena tecnología para una empresa. Nuestra historia de adopción de GraphQL en PayPal y las lecciones que aprendimos, los desafíos que tuvimos, algunas mejores prácticas que adoptamos y si estás interesado en comenzar con GraphQL, cómo puedes empezar.

Antes de comenzar mi charla, me presentaré. Mi nombre es Shruti Kapoor. Soy una ingeniera de software senior en PayPal. Puedes encontrarme en Twitter en Shruti Kapoor08 o en Twitch en twitch.tv/ShrutiKapoor donde comparto sesiones de transmisión en vivo trabajando en algo como una presentación como esta. Así que te invito a venir y trabajar en tus proyectos personales conmigo.

Cuando comenzamos a adoptar GraphQL en PayPal, cuando comencé en PayPal, en realidad nunca había trabajado con GraphQL antes. Pensaba que GraphQL era una tecnología utilizada para obtener datos, pero pensaba que estaba relacionada de alguna manera con Facebook, así que no tenía idea de cómo trabajar con GraphQL. Pensaba que estaba relacionada con GraphCMS y eso era todo lo que sabía. Así que cuando comencé en PayPal, mi función en el equipo era trabajar en un proyecto interno que era completamente nuevo y debíamos consumir casi cinco APIs internas. Todas estas eran APIs REST. Nuestra aplicación frontend debía ser una aplicación NodeJS, pero lo que usamos en el frontend de esa aplicación NodeJS dependía de nosotros, así que decidimos usar GraphQL como la capa frontend de esa aplicación NodeJS.

Por qué decidimos usar GraphQL, lo explicaré en un momento, pero cuando comencé con GraphQL en PayPal, no había muchas personas ni muchos equipos que estuvieran usando GraphQL. El equipo principal que estaba usando GraphQL era la aplicación de Checkout, que tal vez hayas visto cuando realizas el pago en PayPal. Esa fue en realidad la pionera en la adopción de GraphQL en PayPal. Abogaron por GraphQL y los beneficios de adoptar GraphQL dentro de PayPal e inspiraron al resto de la empresa a comenzar a adoptar GraphQL. En ese momento, en 2018, no teníamos mucho apoyo central. Inicialmente, los equipos comenzaron a adoptar GraphQL de manera lenta, pero era algo muy independiente y dependía del equipo mismo superar los desafíos. Incluso la comunidad estaba en etapas muy tempranas, pero desde entonces, mucho ha cambiado fuera de la comunidad y en PayPal mismo. Dentro de PayPal, en los últimos tres años, ahora hay 50 aplicaciones que utilizan GraphQL en producción. También tenemos una API pública de GraphQL que funciona con BrainTree. Y en nuestra comunidad interna de Slack, tenemos casi 500 miembros. Todo esto es para decir que GraphQL está ganando mucho impulso en PayPal y lo estamos utilizando ampliamente. Hemos construido herramientas internas para admitir GraphQL, especialmente las bibliotecas que teníamos en PayPal. Ahora brindamos soporte de infraestructura y capacitación para adoptar GraphQL a los equipos que están adoptando GraphQL, especialmente brindándoles algunas aplicaciones frontend y backend de muestra para que puedan comenzar fácilmente con GraphQL.

Y para cualquier aplicación frontend que esté construyendo una interfaz de usuario, GraphQL se ha convertido en un patrón predeterminado para adoptar, para colocarlo como la capa frontend de la interfaz de usuario. Nuestras razones para adoptar GraphQL en ese momento podrían explicarse al comprender cuáles eran nuestros desafíos en ese momento. Así que cuando estábamos pensando en adoptar una nueva tecnología o cuando estábamos pensando en una solución en realidad, estos eran algunos de los problemas que teníamos en ese momento.

Nuestro principal problema era que, y esto se refiere específicamente a nuestra empresa, que es una empresa con una gran cantidad de API REST, por lo que teníamos muchas API REST y nuestra aplicación frontend con la que estábamos trabajando debía comunicarse con cinco API REST diferentes. Lo que sucedía era que nuestra interfaz de usuario podía necesitar un campo, pero para obtener ese campo, teníamos que llamar a un punto final REST y ese punto final REST también podía estar sirviendo a muchas otras aplicaciones de interfaz de usuario. Entonces, lo que sucedía era que llamábamos a la API REST y obteníamos muchos datos excesivos y esos datos teníamos que descartarlos en el lado del cliente y solo usar ese campo. Así que uno de los problemas más grandes que enfrentábamos en ese momento era que obteníamos demasiados datos de las API REST y no los utilizábamos todos.

Y debido a que teníamos tantas API REST diferentes, también teníamos que averiguar qué API llamar para obtener la información que necesitábamos. Y eso a menudo implicaba que primero teníamos que autenticarnos en una API, luego teníamos que usar ese token para llamar a otra API, tal vez obtuviéramos el ID del usuario de esa información, de esa API, y luego usaríamos ese ID para tal vez llamar a su API de perfil y obtener su nombre y otra información. Entonces, básicamente lo que sucedía era que hacíamos múltiples viajes de ida y vuelta, usábamos un campo de una API y lo enviábamos a otra API. Y eso generaba mucha frustración porque estábamos llamando a muchas API diferentes en nuestras aplicaciones frontend.

También, debido a que teníamos API REST con muchas versiones, lo que sucedía era que lanzábamos una nueva versión y si teníamos que actualizar un campo o cambiarle el nombre, cualquier persona que estuviera integrada con la versión anterior ahora quedaba obsoleta. Y nos resultaba muy difícil proporcionar actualizaciones a estos clientes. No siempre era factible que los clientes actualizaran a nuestras últimas versiones. Entonces, lo que sucedía era que la mayoría de nuestros clientes seguían utilizando la versión anterior mientras publicábamos nuevas versiones de la API. Otro problema era que, debido a que teníamos API REST en todos los ámbitos, lo que podía suceder era que un campo se llamara de una manera en una API, como `username`, pero de otra manera en otra API, como `user` o `name`. Por lo tanto, la experiencia de integración en sí también era muy inconsistente. Como desarrolladores frontend, teníamos que averiguar cómo dar formato en el lado del cliente, incluso para llamar a la API misma y dar formato a nuestros datos antes de enviarlos al lado del servidor. Por lo tanto, la experiencia de integración en sí era bastante inconsistente. El candidato adecuado que buscábamos nos proporcionaría la capacidad de tener una experiencia uniforme para todas las API que íbamos a obtener en todos los ámbitos. Y otra cosa importante era la facilidad de integración en todos los ámbitos. Queríamos asegurarnos de que la API, la tecnología que usaríamos, no requeriría que un cliente, especialmente nuestras empresas hermanas, tuviera información previa sobre nuestras propias API. Por ejemplo, si nuestra empresa hermana, como Braintree, tuviera que integrarse con PayPal, no queríamos que Braintree conociera los entresijos de llamar a una API REST o llamar a una API en el lado de PayPal. Queríamos que tuvieran una interfaz sencilla con la que pudieran integrarse, algo con lo que estuvieran familiarizados, sin tener que preocuparse por lo que sucede detrás de escena. Otra cosa que queríamos era, porque estábamos lanzando actualizaciones y queríamos degradar campos de manera inteligente, queríamos asegurarnos de tener análisis detallados sobre qué campo se estaba utilizando en los puntos finales de GraphQL, o en nuestros puntos finales REST, o en nuestros puntos finales de API. Queríamos asegurarnos de que si estábamos lanzando actualizaciones, las estábamos haciendo de manera inteligente y teníamos instrumentación detrás de ellas. Otra cosa que notamos que estaba sucediendo en nuestros equipos era que nuestros desarrolladores frontend y backend a menudo tenían esta conversación. Los desarrolladores frontend decían que necesitábamos agregar más datos. Y una de las preguntas que se hacía era: ¿Deberíamos obtener versiones de API? Pero el problema con las versiones de API es que si introduces cambios disruptivos, ¿cuál es la mejor práctica para introducir un cambio disruptivo? Y si pasas de la versión 1 a la versión 2, ¿qué sucede con todos los clientes que aún no están integrados con la versión 2? No obtienen las actualizaciones todavía. Entonces, ¿cuál es la mejor solución allí? Otra alternativa es si necesitas solicitar más datos.

Si necesitas solicitar más datos, el caso de uso que solíamos discutir era, si necesitas solicitar más datos, ¿deberíamos agregar un nuevo punto final? Entonces, si ya tienes usuarios, ¿deberíamos agregar, por ejemplo, el nombre de usuario? Agregar un nuevo punto final no siempre es un enfoque favorable, por lo que generalmente una alternativa que se puede utilizar es agregar parámetros de consulta. Pero uno o dos parámetros de consulta están bien, pero a medida que comenzamos a solicitar más y más datos, los parámetros de consulta también comienzan a contaminarse, por lo que no siempre es un enfoque ideal.

Otro enfoque es agregarlo a un punto final existente y solicitar más datos en el punto final existente, pero eso rompe la integración de las personas, especialmente si es un campo requerido que rompe la integración de las personas que ya están integradas. Estos son algunos de los desafíos comunes a los que nos enfrentábamos cuando buscábamos una tecnología alternativa. Y ahí es donde pensamos que GraphQL realmente podría ayudarnos, porque uno de los mayores problemas era que teníamos versiones, y con la ayuda de GraphQL, tenemos un punto final y no tenemos más API versionadas. Eso significaba que toda nuestra experiencia de integración estaba en un solo lugar y era uniforme. Pero también, cuando hacemos actualizaciones, se entregarían al cliente tan pronto como las publiquemos, y aquellos que deseen integrarse con los nuevos datos pueden hacerlo en su propio tiempo. Fue realmente increíble ver las análisis detallados que provenían de estos campos, y se volvió mucho más fácil agregar un nuevo campo o marcar campos como obsoletos para que los clientes sepan que estos campos desaparecerían, y así pudimos degradar campos de manera inteligente sin tener que eliminarlos a ciegas y tal vez romper la experiencia de integración de alguien. Otra cosa genial que viene con GraphQL es que, al solicitar solo los datos que necesitas, también se reducen las cargas y se desperdicia menos datos en el lado del frontend.

Como desarrollador, cuando mostramos GraphQL a nuestros equipos, estaban realmente emocionados, especialmente al ver las herramientas de desarrollo que existen en la comunidad, incluso en la actualidad y en 2018. Especialmente cuando mostramos GraphQL, todos estaban muy contentos de ver la explorabilidad de la documentación y el hecho de que se puede enviar una consulta de GraphQL de inmediato. Otra cosa genial que sucedió con la introducción de GraphQL fue que nuestros equipos de frontend y backend comenzaron a colaborar mucho más, porque teníamos que establecer un esquema desde el principio. Eso significaba que teníamos que establecer ese contrato entre el equipo de frontend y backend, por lo que aumentó la colaboración entre nuestros equipos, lo cual es un gran efecto secundario de adoptar GraphQL. Una cosa increíble de tener un esquema es que, debido a que es un contrato, eso significa que tu equipo de frontend puede ver ese contrato y desarrollar su aplicación frontend, mientras que el equipo de backend puede ver ese contrato y desarrollar el lado del backend, el lado de la API de GraphQL. Eso significa que una vez establecido el esquema, ayuda a que los equipos... Mientras se establece el esquema, ayuda a acercar a los equipos. Pero una vez establecido el esquema, también ayuda a que los equipos trabajen de forma independiente, lo cual pensamos que era genial.

Existen diferentes enfoques para adoptar GraphQL, y consideramos algunos de ellos. Aquí hay algunos de ellos. Creo que el más popular es adoptar GraphQL como una especie de capa de orquestación o un envoltorio sobre una API REST. Se ve algo así. Digamos que tienes una aplicación de interfaz de usuario que llama a diferentes API REST, llama a tres API diferentes. Una técnica muy común es introducir GraphQL como una especie de capa de orquestación o como una fachada entre tu capa de frontend y tu capa de backend. Donde coloques tu lógica de negocio realmente depende de tu aplicación, pero muchas personas colocarían su lógica de negocio pesada en la API REST, como llamar a la base de datos, cosas así, o decidir qué caso de uso empresarial está en las propias API REST, donde existe actualmente, pero pondrían la lógica de negocio más ligera en las API de GraphQL. Entonces, realmente depende de tu aplicación, pero básicamente la lógica de negocio puede vivir tanto en la capa de GraphQL como en la capa de API REST, como lo hace actualmente. Otra técnica para aquellos clientes que están muy ligados a REST es que puedes introducir un envoltorio REST sobre las API de GraphQL. De esta manera, aún puedes obtener los beneficios de la API de GraphQL como una capa de orquestación, pero esto también te brinda una ventaja adicional de que si tienes clientes que sabes que no migrarán a GraphQL, aún puedes ofrecer una API REST para ellos. Otra cosa es que si tienes aplicaciones que tal vez estén en un sistema heredado y no quieres modificarlas, también puedes hacer que GraphQL y REST coexistan juntos. Se ve algo así. Digamos que tienes una ruta que se comunica con GraphQL, y luego tienes otra ruta que se comunica con la API REST.

Entonces, tus API de GraphQL y las API REST coexisten. La API REST es simplemente tu sistema heredado, y luego la API de GraphQL es donde construyes todas tus nuevas tecnologías, tu nueva lógica empresarial. Así que ambas conviven juntas.

Para nosotros, al adoptar GraphQL, teníamos algunas opciones diferentes para integrar GraphQL, y aquí están algunas de ellas. Pensamos que podríamos comenzar convirtiendo nuestras API existentes en GraphQL y hacerlo paso a paso, un punto final a la vez. Otro enfoque que consideramos fue convertir todo lo nuevo que estábamos construyendo en API de GraphQL, por lo que construiríamos estas API como entidades independientes, lo cual fue especialmente útil para aplicaciones que alimentarían la interfaz de usuario, como las capas de interfaz de usuario. Algunas cosas que teníamos en mente antes de integrar GraphQL eran quién sería el cliente que utilizaría la API y si estarían dispuestos a llamar a GraphQL. Por ejemplo, si era un cliente externo o un cliente, y sabíamos que no estarían dispuestos a llamar a GraphQL, tal vez introduciríamos GraphQL en un lugar diferente. Pero si era una aplicación de frontend y la aplicación de frontend estaría dispuesta a llamar a GraphQL, entonces sería un buen candidato para introducir una API de GraphQL. Otra cosa que consideramos fue cuántas API aguas abajo estábamos llamando, y esto fue especialmente útil porque estábamos hablando de obtener cargas más pequeñas, tener una experiencia consistente y análisis detallados. Si tenemos múltiples API diferentes que vamos a llamar, entonces sería un buen candidato para crear una capa de GraphQL. Pero si solo hay una API REST que vamos a llamar, no es realmente una buena aplicación de GraphQL porque entonces estaríamos duplicando todo el trabajo que se está realizando en la capa REST y duplicando el esfuerzo. Otra cosa que teníamos en mente fue el impacto empresarial y el lado empresarial de la aplicación, es decir, a quién sirve esta aplicación, quiénes son las partes interesadas, cuál es el marco de tiempo, cuánto tiempo podemos tomar para convertir esta aplicación en una capa de GraphQL o en una aplicación de GraphQL. Pensamos que primero comenzaríamos con una primera aplicación y convertiríamos una primera aplicación, como esta aplicación de demostración, en una aplicación de GraphQL, por lo que comenzamos con la herramienta en la que estaba trabajando, que en realidad era una nueva herramienta interna que estábamos construyendo, nuestras partes interesadas eran clientes internos, equipos internos en realidad, representantes de servicio al cliente, estábamos llamando a cinco API diferentes aguas abajo y la aplicación de frontend, que era mi equipo, estaba muy dispuesta a integrarse con GraphQL, por lo que se convirtió en un buen candidato para experimentar con GraphQL. Nuestro objetivo para esta aplicación era que fuera rápida y liviana, y básicamente eso significaba que no deberíamos enviar ningún dato innecesario, por lo que GraphQL fue un buen candidato allí y no queríamos agregar bibliotecas que no necesitábamos, bibliotecas de terceros que no necesitábamos, por lo que cuando introdujimos GraphQL, notamos que realmente no necesitamos mucho manejo de estado, por lo que pudimos deshacernos de Redux y simplemente usar el estado de React con la ayuda de la caché de Apollo para deshacernos de nuestras soluciones de manejo de estado. Entonces, básicamente, terminamos enviando menos datos y usando menos bibliotecas con la ayuda de GraphQL. Y para esa lógica empresarial, nosotros, el equipo que poseía una de las API REST backend, terminamos poniendo toda nuestra lógica empresarial pesada en nuestra propia API REST backend. Teníamos nuestra capa de orquestación de GraphQL como una especie de capa de proxy simple entre la aplicación de frontend y nuestra capa de lógica empresarial que era la API REST. Para la autenticación, utilizamos las API REST existentes que existen en Paypal en sí, por lo que era nuestra infraestructura existente, y luego el resto de las API REST aguas abajo las mantuvimos en la API misma, no las tocamos. Entonces, básicamente, nuestra capa de orquestación de GraphQL era una capa de orquestación simple y delgada, fue realmente genial verlo porque aún podíamos aprovechar todos los beneficios de GraphQL y descubrimos que GraphQL funciona muy bien como una capa de orquestación.

Entonces, nuestra arquitectura se veía así. Teníamos la capa de GraphQL que era la primera capa con la que la interfaz de usuario hablaría, y esa era la única capa con la que la interfaz de usuario hablaría. Y luego, la capa de GraphQL se encargaría de determinar cuándo llamar a la capa de autenticación, cuándo llamar a análisis, cuándo llamar a la API REST. Entonces, GraphQL hacía este trabajo de actuar como una fachada entre todas las diferentes API REST que teníamos en nuestra aplicación con las que se suponía que la aplicación debía comunicarse. Básicamente, lo que aprendimos con nuestra primera aplicación es que es realmente genial envolver una API REST con la API de GraphQL y crear nuestra capa de GraphQL como una capa de orquestación. Y el cliente aún puede aprovechar los beneficios de GraphQL, incluso sin tener que cambiar nada aguas abajo. Y eso fue realmente increíble de ver. Y otra cosa fue que, como también poseíamos la API REST backend, nuestros desarrolladores backend no tuvieron que cambiar la forma en que estaban trabajando. Fue realmente genial porque eran independientes y podían trabajar de la manera que querían, lo cual fue increíble. Y acercó a nuestros desarrolladores de frontend y backend porque establecimos un esquema y teníamos un contrato para seguir. Todos estaban hablando entre sí y todos estaban muy contentos porque teníamos colaboración en equipo. Terminamos creando una interfaz de GraphQL para orquestar esa nueva API REST, y pudimos entregar solo los datos que necesitábamos y facilitar la evolución de la API REST con el tiempo.

Otro enfoque para adoptar GraphQL y considerar otro tipo de aplicación es algo como esto, donde colocas toda la lógica empresarial en la capa de GraphQL misma. Entonces, la capa de GraphQL es la capa principal en la que construyes, por lo que es donde colocas toda la lógica empresarial, y la capa de GraphQL se encargará de llamar a las APIs REST que necesite. Pero aquí no estás trabajando en ninguna API REST, solo estás trabajando en la capa de GraphQL. Así que todo va dentro de la capa de GraphQL.

El estado actual de la adopción de GraphQL en PayPal es que la mayoría de nuestras aplicaciones ahora están utilizando GraphQL, especialmente si es una aplicación de frontend, especialmente si es una aplicación que necesita alimentar una capa de interfaz de usuario. Todas están adoptando una, todas están utilizando una capa de GraphQL como la primera fachada, como la primera capa. También estamos logrando que nuestras aplicaciones de material se muevan a GraphQL, lo cual es realmente genial de ver. Nuestros equipos de backend aún están un poco indecisos, especialmente aquellos que están muy cerca de la base de datos. Y está bien. Todavía están en APIs REST y está bien. Así que tenemos una buena combinación de APIs REST también. La mayoría de nuestras aplicaciones se ejecutan de forma independiente en GraphQL. Tenemos un montón de puntos finales de GraphQL diferentes en la empresa, pero estamos tratando de avanzar hacia un enfoque de gráfico unificado federado. Aún no hemos llegado allí.

Creo que una cosa que ayudó mucho a convencer a las personas fue la productividad de desarrollo. Nos dimos cuenta de que cuando mostrábamos GraphQL a nuestra gente, la gente se emocionaba mucho al ver GraphQL. Fue realmente genial, especialmente porque teníamos muchas APIs diferentes en general, y tener todo eso en un solo lugar y poder pasar de una documentación a otra y poder enviar cualquier consulta que quisiéramos, eso fue realmente impresionante. Creo que ahí es donde vimos los mayores beneficios de adoptar GraphQL. Otra cosa realmente genial fue que, como sabíamos qué campos se estaban utilizando y con qué frecuencia se estaban utilizando, fue realmente genial ver la instrumentación detrás de eso porque sabíamos qué tan lento sería un campo, qué tan lenta sería una mutación o una consulta. Fue realmente genial verlo porque teníamos un control a nivel granular sobre nuestras APIs y un conocimiento a nivel granular de nuestras APIs. Y fue realmente genial para nosotros evolucionar hacia GraphQL con el tiempo porque una vez que establecimos un contrato de esquema, nuestros desarrolladores de API pudieron trabajar de forma independiente y no tuvimos que frenar a un equipo por otro. Y nuestra interfaz de usuario era la que ahora impulsaba el esquema. Ya no construíamos APIs esperando a ciegas que se utilizaran estos campos, sino que teníamos una interfaz de usuario que impulsaba qué campo se insertaría en el esquema y ese sería el campo que se desarrollaría. De esta manera, estábamos construyendo inteligentemente nuestras APIs. Otra cosa genial de adoptar GraphQL es el rendimiento que conlleva y el rendimiento en el sentido de que al enviar menos datos, los clientes tienen que hacer menos trabajo para descartarlos o los clientes no tienen que hacer el trabajo de descartar datos. Eso significa que ya estamos enviando cargas más pequeñas, pero también porque ya no tenemos que formatear los datos porque los datos están en el formato que el cliente solicitó, no tenemos que escribir muchas bibliotecas de terceros, incorporar muchas bibliotecas de terceros o desarrollar lógica en la capa de frontend para formatear los datos en la forma que necesitamos. Después de adoptar GraphQL, aquí hay algunas lecciones que aprendimos. La primera lección es elegir una primera aplicación y eso realmente ayuda porque esa aplicación puede servir como una aplicación que puede enseñarte lecciones sobre la adopción de GraphQL dentro de tu propia empresa. Comienza con una aplicación que tenga un bajo impacto empresarial y las partes interesadas sean tus equipos internos y orquesta tus APIs REST en APIs de GraphQL para que no tengas que

Otra cosa realmente genial de construir GraphQL que vimos en nuestro equipo fue que unió a nuestros equipos. Así que construye esquemas junto con los equipos de frontend y backend y utiliza las características incorporadas de GraphQL. Por ejemplo, la seguridad de tipos o directivas, y eso ayuda mucho, especialmente cosas como Deprecator. Las usamos todo el tiempo. Pero debo dar una palabra de precaución, que es que mucha gente piensa que adoptar GraphQL hará que la aplicación sea realmente rápida. Pero no es cierto. GraphQL solo será tan rápido como tu punto final más lento. Hay un pequeño impulso de rendimiento que viene con GraphQL porque enviarás menos datos y pedirás menos datos. Pero si una de tus APIs REST es realmente lenta, eso es lo primero que tendrás que solucionar en lugar de adoptarla, en lugar de agregar una capa de GraphQL en ella, porque de lo contrario no verás muchos beneficios. Otra cosa es que si eres una aplicación que no sabe cuál será el esquema de antemano, es un poco difícil construir ese esquema porque el esquema debe construirse de antemano, tendrás que establecer un contrato desde el principio. Así que tendrás que pensar en cómo deben llamarse tus campos, qué consultas y mutaciones quieres habilitar. Entonces, si eres una aplicación que no sabe eso, piensa si GraphQL es adecuado para ti. En general, creo que todavía hay desafíos de GraphQL en la comunidad misma. Por ejemplo, el almacenamiento en caché y el mapeo de errores aún se están desarrollando. Necesitas conocer el esquema de antemano y a veces es realmente difícil hacer un solo gráfico, especialmente lo estamos viendo en nuestra empresa, especialmente cuando tenemos diferentes repositorios. Hay algunos desafíos de GraphQL. Piensa si GraphQL aún sería adecuado para ti. Ahora, si crees que GraphQL sería adecuado para ti, aquí hay algunos próximos pasos que puedes seguir. Haz un ejercicio similar en tu equipo y evalúa si GraphQL es adecuado para tu arquitectura en tu empresa. Algunas de las preguntas que puedes hacerte son cuáles son los desafíos a los que se enfrentan tus equipos y quiénes son tus interesados y desarrolladores de clientes. ¿Quién tendría la propiedad de las capas de GraphQL y las APIs REST? ¿Y dónde quieres colocar tu lógica empresarial? ¿Viviría en las capas de GraphQL o en las APIs existentes que tienes? Otra cosa en la que debes pensar es qué infraestructura específica de la empresa necesitas adoptar. Por ejemplo, puedes tener autorización, experimentación, análisis, monitoreo. ¿Dónde vas a colocar todo eso en tu arquitectura de GraphQL? Otra cosa, como decía, es si estarías ahorrando algún dato al convertirlo a GraphQL. Especialmente si necesitas usar todo lo que tu API REST te proporciona en tu capa de GraphQL. ¿Estarías ahorrando algún dato al convertirlo a GraphQL en ese caso? Y si dependes mucho del almacenamiento en caché, el mapeo y manejo de errores, ¿cómo resolverás esos problemas con GraphQL? Otra cosa es cuando estás escalando GraphQL dentro de tu empresa, ¿cómo incorporarás nuevos equipos? Y necesitarás configurar un equipo que haga cumplir los estándares como los nombres de las mutaciones de las API de GraphQL. Y cómo lidiarías con el cambio de esquema. Entonces, si necesitas cambiar el nombre de los campos en tu esquema, ¿cómo lo harías? En general, creo que si quieres estar preparado para adoptar GraphQL, aquí tienes un ejercicio que puedes hacer. Puedes hacer un ejercicio interno con tu empresa y tratar de convertir una de tus aplicaciones en una aplicación de GraphQL y anotar todos los desafíos a los que te enfrentas. Configura un equipo de estándares que te ayude a resolver esos problemas dentro de tu propia empresa. Por ejemplo, la unificación de esquemas, especialmente si eres una empresa que tiene microservicios en todo el equipo y quieres convertir una API a la vez. Así que establece un esquema estándar que te ayude a resolver esos problemas juntos. Y explora las bibliotecas de código abierto.

Básicamente, si quieres convencer a tu equipo de adoptar GraphQL, tengo algunos consejos en los que debes enfocarte, enfócate en su productividad y enfócate en el hecho de que puedes adoptar GraphQL de manera incremental y no tienes que convertir todo a GraphQL al mismo tiempo, enfócate en el hecho de que aumenta la colaboración entre los equipos de frontend y backend y en el hecho de que hay muchas herramientas en la comunidad, herramientas de código abierto en la comunidad que puedes aprovechar. No hay versiones, por lo que todos recibirán las mismas actualizaciones y las mismas obsolescencias. Y el hecho de que sea similar a JSON significa que es más fácil de entender para aquellos que ya trabajan con datos JSON. Y si quieres hablar de GraphQL, aquí está mi recomendación de cómo incorporar GraphQL en tu aplicación. Creo que puedes utilizar GraphQL como una especie de capa de orquestación entre tus capas actuales, tu lógica empresarial actual, tu infraestructura actual y tu capa de interfaz de usuario. De esta manera, la interfaz de usuario solo puede comunicarse con la capa de GraphQL y eso es todo de lo que la interfaz de usuario tiene que preocuparse. La capa de GraphQL se encargará de determinar qué API llamar. Toda tu lógica empresarial, cualquier cosa pesada que tengas actualmente, puede permanecer en la capa de API REST. Pero cualquier cosa más liviana puede permanecer en tus capas de GraphQL. De esta manera, podrás adoptar GraphQL, insertar GraphQL fácilmente en tu aplicación sin tener que cambiar demasiado de lo que tienes ahora. Así que básicamente, comienza con una aplicación pequeña, convierte una API a la vez, y establece equipos que te ayudarán a adoptar GraphQL dentro de la propia empresa.

Ahora, para concluir, me gustaría decir que ninguna tecnología es perfecta. GraphQL tiene sus beneficios, pero también tiene sus desafíos. Así que evalúa si GraphQL sería adecuado para ti antes de adoptarlo. Pero me gustaría decir que GraphQL está aquí para quedarse, y es un buen momento para comenzar con GraphQL, especialmente en una empresa. El poder de GraphQL proviene de la comunidad. Así que involúcrate en la comunidad, y utiliza las bibliotecas de código abierto que están disponibles. Hemos escrito una publicación de blog sobre el éxito de la aplicación Trailblazer, que es el proceso de pago de PayPal, y Max Stewart escribió este artículo. Así que aquí está el enlace de ese artículo si estás interesado en las decisiones técnicas que tomamos, especialmente para la aplicación Trailblazer. Aquí hay algunos artículos diferentes que son realmente interesantes. El artículo de Expedia es realmente interesante. Y el libro de Mark Andre sobre GraphQL listo para producción es increíble, si quieres adoptar GraphQL dentro de tu empresa. Eso es todo lo que tengo para ti. Nuevamente, puedes contactarme en Twitter en shruthigapoor08 si tienes alguna pregunta, o puedes contactarme en Twitch. También enviaré un fragmento de esto en mi boletín de noticias en hindlinader.com si estás interesado en un resumen. Puedes encontrar todas las diapositivas aquí. Y encontrarás un fragmento aquí. Antes de irme, quiero dejarles con un último chiste de desarrollador. Muchas gracias a todos.