1. Introducción a GraphQL y Evaluación
Soy un ingeniero de software en UgerbyteDB, una empresa de SQL distribuida. GraphQL está ganando una rápida adopción, brindando autonomía a los desarrolladores de UX para recuperar solo los datos que necesitan. Queríamos entender los conceptos del lado del servidor de la arquitectura de GraphQL y su compatibilidad con el desarrollo de API REST. Evaluamos su rendimiento y facilidad de producción utilizando casos de uso del mundo real como el comercio electrónico. Probamos el uso de las capacidades nativas de la base de datos del servidor GraphQL y su capacidad para manejar el tráfico variable. Comenzamos con una tabla simple, el catálogo de productos, y luego pasamos a un conjunto de datos más complejo, la clasificación de productos.
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
2. Usando Suscripciones de GraphQL para Actualizaciones en Tiempo Real
GraphQL simplifica el ciclo de retroalimentación entre el desarrollador de la API y los desarrolladores de UX. Proporciona soporte de primera clase para suscripciones, permitiendo actualizaciones en tiempo real sin la necesidad de una consulta constante de datos. Utilizamos suscripciones de GraphQL en nuestro sistema de gestión de pedidos para rastrear los pedidos de los usuarios y su estado, eliminando la necesidad de recuperar los datos manualmente.
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.
