De Cero a Construir Aplicaciones GraphQL Multi-Región

Hola a todos, gracias por unirse, mi nombre es Nikhil Chandrappa, soy un ingeniero de software en UgerbyteDB, somos una empresa de SQL distribuida. Trabajo en el equipo de controladores y ecosistema de UgerbyteDB, donde construimos integraciones con herramientas populares para desarrolladores. Últimamente estamos viendo mucho interés en nuestra comunidad y también de nuestros usuarios para construir soporte de primera clase para GraphQL. Si haces una búsqueda rápida en Google Trends, verás que GraphQL está ganando una rápida adopción. Para los desarrolladores de UX, GraphQL brinda autonomía para crear los datos, pueden recuperar solo los datos que necesitan. Para nosotros, como empresa de base de datos, y también en nuestro trabajo diario con los desarrolladores de backend y los desarrolladores de API, tenía sentido para nosotros entender los conceptos del lado del servidor de la arquitectura de GraphQL. El servidor de GraphQL proporciona una abstracción sobre la base de datos para crear y mutar los datos y también algunas otras características avanzadas como paginación, filtrado, eventos. Queríamos ver cómo todas estas cosas encajan con el desarrollo general de API REST que generalmente vemos. Entonces, un desarrollador de API entendería el dominio comercial. Él crea los objetos de dominio. Implementa todos los patrones de acceso a su alrededor. Queríamos ver cómo se ve todo esto en el servidor de graphQL. Para eso, queríamos usar un caso de uso del mundo real. Consideramos el dominio del comercio electrónico, que es bien conocido. Y también presenta desafíos tanto para los desarrolladores de UX, donde tenían que construir una experiencia inmersiva y atractiva como para los desarrolladores de API, donde tenían que manejar o implementar las API para la aleatoriedad del tráfico. Porque no siempre es constante. Escala en función del tráfico de usuarios, tienes que escalar tus API hacia arriba o hacia abajo y también las API deben estar disponibles todo el tiempo. Esta es una arquitectura general de microservicios que verás en aplicaciones de comercio electrónico. Tendrás un montón de microservicios expuestos como una API REST, y esta API REST será consumida por las aplicaciones de UI o los desarrolladores de UX para implementar aplicaciones de UX. Entonces, probablemente sea una venta rápida para ellos pasar a GraphQL en lugar de pasar por toda la documentación. Para nosotros, durante nuestra evaluación, queríamos ver qué tan bien el servidor de GraphQL puede utilizar las capacidades nativas de la base de datos. ¿Es eficiente o no? ¿Y qué tan fácil es llegar a producción, verdad? Para eso, primero queríamos usar una de nuestras tablas simples, el catálogo de productos. No tiene un patrón de acceso complejo. Obtienes el ID del producto en la solicitud y envías los detalles del producto de vuelta, ¿verdad? Fue una victoria rápida para nosotros. Si ves este objeto JSON complejo que se enviaba en la respuesta. Ahora, los clientes de Graphql son las aplicaciones de UX que solo pueden recuperar los datos que necesitan. Una vez que nos sumergimos en el agua y nos sentimos cómodos con las aplicaciones de Graphql. Entonces queríamos tener una tabla o conjunto de datos mucho más complejo que entrara en escena. Tomamos la clasificación de productos que tiene algunas cosas en marcha. Tienes que filtrar los datos según la categoría

y también ordenarlos según la clasificación. Entonces, parte de esto ocurre en la base de datos y algunas de estas filtraciones también ocurren en la capa de la API. Una cosa que entendimos rápidamente fue que cualquier operación CRUD en estas tablas es súper fácil y rápida. Esto conduce a una prototipación más rápida donde el desarrollador de UX no necesita estar en constante comunicación. A medida que agregamos más tablas, nos dimos cuenta de que construir todos estos mapeos de dominio y resolutores es una tarea compleja. No es algo que se pueda hacer rápidamente y tener un servidorGraphQL sólido. Pero ahí es donde queríamos cambiar y usar algunas de las implementaciones de servidor de código abierto populares de GraphQL que existen. Así que cambiamos a usar herramientas de código abierto. En nuestra investigación, descubrimos que todas estas herramientas tienen soporte de primera clase para suscripciones, ¿verdad? Soporte de primera clase incluso para sistemas basados en eventos utilizando suscripciones de GraphQL, queríamos usar eso. En nuestra segunda iteración, queríamos usar suscripciones de GraphQL. Las usamos en un sistema de gestión de pedidos donde queríamos rastrear todos los pedidos de los usuarios y su estado. Esto resuelve muchos problemas, ¿verdad? No tienes que consultar losdata constantemente, cada vez que haya una actualización de estado, recibirás una notificación. El siguiente paso para nosotros fue determinar si podía manejar la escala y los requisitos de nivel de servicio (SLA) que existían en la API. Para eso, realizamos pruebas de rendimiento de las suscripciones de GraphQL y pudimos escalar según los requisitos de SLA que necesitábamos, y estamos muy satisfechos con eso. Lo siguiente en una aplicación nativa de la nube es la resiliencia de las aplicaciones. ¿Puede funcionar sin problemas cuando se migra a la nube? Es esencial para nosotros, para ti y para todos nosotros construir una aplicación que no se caiga en caso de un corte de servicio o una interrupción en una región. Entonces, lo que hicimos a continuación fue implementar los servidores de GraphQL en un clúster de bases de datos que obtuvimos, donde pudimos realizar pruebas de resiliencia al eliminar una región o algunas máquinas en una región. Eso nos dio suficiente confianza para llevarlo a producción. Creemos que junto con GraphQL, que simplifica el ciclo de retroalimentación entre el desarrollador de la API y los desarrolladores de UX, se vuelve muy poderoso cuando puede aprovechar las capacidades de las aplicaciones nativas modernas de la nube. Eso es todo, amigos. Esa es toda la charla que tenía hoy. Si tienen alguna pregunta, no duden en hacerla en la sesión de preguntas y respuestas en vivo. Gracias.