Header Ads Widget

Ticker

6/recent/ticker-posts

¿Estás listo para adoptar GraphQL?

 En este artículo, exploremos GraphQL . Primero entendamos qué es GraphQL. GraphQL es una especificación de Facebook. GraphQL es un lenguaje de consulta para API y un tiempo de ejecución para completar esas consultas con sus datos existentes. GraphQL brinda a los clientes el poder de pedir exactamente lo que necesitan y nada más al evitar la captura excesiva o insuficiente de datos . Lo entenderemos más cuando veamos la implementación de GraphQL en acción. Hasta entonces mantén tu curiosidad. 

Espere, espere ... Hasta ahora estamos usando REST ( Representation State Transfer ) para exponer nuestros servicios como API. Hagamos algunas preguntas nosotros mismos antes de profundizar en GraphQL.

GraphQL

¿Por qué necesito adoptar GraphQL?
¿Qué problemas tengo con las API REST? ¿Cómo GraphQL los resuelve?
Para responder a las consultas anteriores, tomemos un caso de uso para crear una aplicación de comercio electrónico para clientes nativos, móviles y web. Decidimos exponer API para varias funcionalidades de comercio electrónico. Por ejemplo, tengo una API REST de detalles de producto que proporciona información específica del producto como JSON que incluye atributos de datos de productos, datos de especificaciones, datos de reseñas, etc. Como tenemos muchos atributos en JSON de productos, el tamaño es mayor. Cada cliente (web y clientes ligeros (móviles y tabletas)) tiene sus propios requisitos de interfaz para mostrar los datos del producto, ya que tienen diferentes tamaños de pantalla, memoria, ancho de banda de red, etc. Ahora mis clientes comenzaron a consumir API de detalles del producto. Aunque las interfaces para dispositivos móviles y tabletas no requieren JSON del producto completo como web, la API de detalles del producto proporciona datos completos del producto. Es evidente que los clientes no tienen control sobre los datos que quieren del servidor. Se llamamás de buscar . La representación gráfica de REST sobre el problema de recuperación se muestra a continuación.       

Podemos resolver el problema de la búsqueda excesiva con varios enfoques. El enfoque sencillo es mantener diferentes API para clientes pesados ​​y ligeros. Aunque este diseño resuelve el problema de la búsqueda excesiva, tiene otros problemas como el mantenimiento del código, la implementación de mejoras en diferentes API, la implementación de API de cliente ligero y grueso, más computación, más mano de obra, etc., lo que aumenta el costo del proyecto. El otro enfoque es tener middleware para interceptar la solicitud del cliente. Según la solicitud del cliente, filtre la respuesta a devolver. Esto agrega una capa adicional a la aplicación que tiene los mismos problemas que el enfoque anterior.

GraphQL

Ahora discutamos el segundo problema con REST llamado bajo búsqueda . Para evitar la búsqueda excesiva, decidimos crear API granulares para que los clientes realicen llamadas a la API para los datos que requieran. Tomemos la página de detalles del producto para la web. Tiene información de productos, especificaciones y reseñas para mostrar. Ahora, para representar la página de detalles del producto, el cliente no obtendrá datos en una sola llamada a la API. Por lo tanto, el cliente debe realizar varias llamadas a la API (como API de producto básico, API de especificación, API de reseñas) para satisfacer sus requisitos de datos. Este diseño tiene problemas de rendimiento con un mayor número de viajes de ida y vuelta al servidor backend y APIGateway. El otro problema es que requiere más potencia de cómputo y red a medida que aumenta el número de solicitudes para atender. A continuación se muestra una representación pictórica de la búsqueda inferior .                 

Veamos el tercer problema con REST, es decir, API en evolución con versiones. Cualquier API evolucionará a medida que las necesidades comerciales cambien con el tiempo. Según las necesidades de nuestros clientes, es posible que debamos agregar atributos de datos (en la mayoría de los casos, no eliminaremos los atributos de datos ya que necesitamos tener compatibilidad con versiones anteriores) a las API existentes. Cuando hacemos cambios en las API existentes, necesitamos un mayor cuidado, ya que los cambios podrían dañar a los clientes. Para evitarlo, haremos versiones de las API cuando planeemos lanzar cambios en las API existentes. Cuando presentamos nuevas versiones, lo que supone la carga de administrar más API (es decir, más capacidad de cómputo, más mano de obra), planeando desaprobar versiones anteriores. Se necesita disciplina y comunicación cuando tenemos más versiones de una API. Con REST no podemos hacer lanzamientos silenciosos.

GraphQL

Los problemas anteriores nos llevan a buscar otra solución llamada GraphQL. Veremos cómo GraphQL aborda los problemas mencionados anteriormente implementando una API en el próximo artículo. Mientras tanto, veamos el paradigma de solicitud y respuesta con GraphQL y cómo GraphQL hace felices a los clientes sirviendo lo que quieren. Estos son algunos de los adoptantes de GraphQL https://graphql.org/users/ .

En el próximo artículo veremos la implementación de una API con GraphQL. ¡Hasta entonces difunda el amor por las API!

Publicar un comentario

0 Comentarios