APIs
6
min de lectura
2 de enero de 2019

Usando GraphQL como patrón de implementación de BFF

Rafael Rocha
Head de Soluciones y Preventa
Tecnólogo en Tecnología de la Información de la UNESP y postgrado en MBA Business Management de la UNIMEP.
Más sobre el autor

Estamos en la era de las APIs RESTful, podría decir que este tipo de estilo arquitectónico de las APIs están en la meseta de la productividad. Muchas plataformas soportan el estilo REST, también la comunidad y la mayoría de los desarrolladores están familiarizados con los conceptos y herramientas.

Entonces, ¿por qué una parte de la comunidad se pasa a otro estilo o patrón arquitectónico? En mi opinión, todos los estilos arquitectónicos tienen algunas desventajas, ¡no hay almuerzo gratis! Creo que el estilo arquitectónico REST se organiza en torno al modelo de negocio con el fin de proporcionar una fuerte reutilización. Parece ser maravilloso, pero alguien tiene que pagar el almuerzo!

Como podemos adivinar, la capa de front-end es aún más dinámica y ágil en términos de requerimientos de negocio, la capa de back-end donde viven las APIs es más burocrática y orientada a procesos. Entonces, ¿quién tiene que ser más adaptable? El front-end, por supuesto.

En términos técnicos, el front-end necesita entender las APIs y normalmente hace demasiadas peticiones y oculta o transforma campos para ofrecer un buen rendimiento (por supuesto me refiero a una mejor experiencia de usuario). Los desarrolladores de front-end sufren con este escenario, por lo que es normal que busquen otras alternativas. Aquí es donde GraphQL realmente encaja bien!

Patrón Backend For Front End (BFF)

¿Y qué hay de BFF? Para solucionar el problema anterior ya existe el patrón BFF (Backend For Front End) que podría utilizarse para solucionar esta situación. En la mayoría de los casos, el estilo arquitectónico REST se utilizó ampliamente. Sin embargo, tiene sentido, si mis APIs de empresa (de propósito general) son REST, ¿por qué no pueden serlo mis APIs de front-end?

Una cosa importante a tener en cuenta es que las APIs del Front End deben soportar otros protocolos en lugar de sólo HTTP. Otros protocolos asíncronos como WebSocket o protocolos de mensajería son muy utilizados en aplicaciones web y móviles y GraphQL puede ser utilizado con esos protocolos.

Pero volvamos a la definición del patrón BFF, según Sam Newman y Phil Calçado [1], El BFF está estrechamente acoplado a una experiencia de usuario específica, y normalmente será mantenido por el mismo equipo que la interfaz de usuario, facilitando así la definición y adaptación de la API según lo requiera el UI , a la vez que simplifica el proceso de alineación de la liberación de los componentes del cliente y del servidor.

GraphQL

El poder de GraphQL [2] proviene de una idea simple: en lugar de definir la estructura de las respuestas en el servidor, la flexibilidad se le da al cliente. Cada solicitud especifica qué campos y relaciones quiere obtener, y GraphQL construirá una respuesta a medida para esta solicitud en particular. La ventaja: sólo se necesita un viaje de ida y vuelta para obtener todos los datos complejos que, de otro modo, podrían abarcar varios puntos finales REST, y al mismo tiempo sólo se devuelven los datos que realmente se necesitan y nada más.

La solución propuesta

La solución que proponemos aquí es unir el patrón BFF existente utilizando GraphQL como tecnología principal de la API. Veamos cómo debería ser una arquitectura de alto nivel a gran escala:

Como podemos ver en la imagen de arriba, las aplicaciones frontales consumen las APIs frontales utilizando la tecnología GraphQL. Para implementar la traducción de REST a GraphQL, se utiliza un motor GraphQL como componente clave.

Todas las APIs de la empresa están disponibles en estilo arquitectónico REST y pueden ser reutilizadas por otras aplicaciones cliente.

Pero el componente principal de este gran cuadro es la Plataforma API, que puede utilizarse aquí para:

  • Gestionar y exponer las API de la empresa (REST)
  • Gestionar y exponer las APIs del Front-End (GraphQL)
  • Implementar y ejecutar el motor GraphQL

Conclusión

La solución que proponemos aquí es el uso de GraphQL como Front-End API, pero ¿por qué?

  1. Funciona con múltiples protocolos de comunicación, como WebSocket.
  2. Oculta la complejidad para manejar las API empresariales RESTful

¿Y qué hay del patrón BFF, por qué utilizarlo?

  1. Crear APIs de experiencia para cada canal de comunicación.
  2. El equipo de desarrollo trabaja en el front-end y en el back-end. La complejidad para manejar las APIs de la empresa puede aplicarse en la capa de back-end y también puede ser reutilizada.

Pero los inconvenientes siempre existen. Así que, ¿qué consideraría usted?

  • GraphQL tiene problemas que manejar, como el hecho de no tener un mecanismo de caché incorporado. En las APIs RESTful, el protocolo HTTP lo maneja de forma nativa.
  • Al utilizar BFF su código base podría aumentar exponencialmente, una vez que usted puede crear un comportamiento personalizado para cada dispositivo.

Por último, si quieres utilizar este tipo de arquitectura, te recomendamos encarecidamente que utilices un Plataforma API [3] que puede ayudarte a manejar tanto el estilo de arquitectura GraphQL como el REST.

Referencias y lecturas adicionales

1] Definición del patrón del backend para el front-end - http://samnewman.io/patterns/architectural/bff/

2] GraphQL en la era de las APIs REST - https://medium.com/chute-engineering/graphql-in-the-age-of-rest-apis-b10f2bf09bba

3] Plataforma APIde Sensedia


¿Desea saber más? Hable con uno de nuestros especialistas, basta colocar los datos en el formulario abajo y luego entraremos en contacto ;)

¡Gracias por leer!