Herramientas y Arquitectura de Software: ¿Rails/React/BFF?

Danilo Barion. Cuando comenzamos a modernizar nuestro software web de contratación empresarial insignia, necesitábamos definir la arquitectura base que mantendría el código funcionando sin problemas como lo había hecho durante los últimos 20 años.

Al mismo tiempo, estas elecciones deben permitir el uso de las mejores tecnologías disponibles, considerando marcos, bibliotecas y lenguajes de programación, incluso para la implementación de un front-end altamente complejo e interactivo.

Después de varias investigaciones, tomamos algunas decisiones que nos permitieron trabajar con nuestro marco web principal, ya en uso en otras API de la empresa, Ruby on Rails, y para el front-end, se eligió la biblioteca React.

Ruby fue el lenguaje de programación elegido desde el comienzo de la migración del código heredado, escrito en asp.net, hace unos 6 años en ese momento. También ya usamos una buena cantidad de herramientas juntas, como MongoDB, Redis, RabbitMQ, PostgreSQL, etc., todas ellas con un gran soporte para Ruby.

En ese momento, en 2015, Rails acababa de lanzar su versión 5.1, sugiriendo el uso de Webpack como el compilador recomendado para JavaScript (que incluso se convertiría en el predeterminado en Rails 6), que permitía usar bibliotecas front-end con React, Vue, Angular, etc., incluso manteniendo la canalización de activos tradicional para CSS, imágenes y contenido estático.

Además, con el rápido crecimiento del equipo front-end, la separación de responsabilidades, tanto en el flujo de desarrollo en sí como en las bases de código y los lenguajes/marcos, nunca ha tenido más sentido.

De lo básico a la arquitectura

Con todo eso en mente, nuestra decisión final para las herramientas básicas no fue tan difícil.

Pero en cuanto a la arquitectura, no queríamos que la nueva app se convirtiera en un "monstruo" después de unos meses de migrar las principales características del proyecto a la nueva estructura.

Por lo tanto, pensamos: ¿cómo podemos estructurar estas nuevas herramientas y marcos, qué arquitectura encajaría mejor y satisfaría mejor nuestras necesidades?
Incluso pensamos en usar GraphQL, pero no queríamos tener que reescribir todas nuestras API principales para admitirlo, especialmente al comienzo del proyecto, ya que la migración desde el sistema heredado ya traería suficiente complejidad en términos de reglas de negocio y requisitos no funcionales.

Sin embargo, el uso de GraphQL estaba en una lista de posibles candidatos para futuras nuevas API.

Después de escuchar sobre un patrón arquitectónico emergente en ese momento, principalmente en el mundo de los microservicios, llamado "Backend For Frontends" (o BFF para abreviar), pensamos que habíamos encontrado lo que necesitábamos.

Decisión final: ¡BFF es la solución!

Esta opción apareció en uno de los Technology Radars, publicado por la empresa, y se pueden leer artículos detallados al respecto aquí y aquí.

El patrón BFF es un intento de brindar soporte de back-end para cada tipo de aplicación cliente (web, móvil, etc.) que consume sus servicios/API. Su objetivo principal es desacoplar las API o microservicios de sus consumidores.

Básicamente, lo que hicimos fue agregar una capa adicional (el BFF) entre nuestras API y el cliente front-end (inicialmente solo el cliente web), cumpliendo con sus requisitos específicos. Por ejemplo, digamos que nuestra aplicación móvil es más simple que nuestro cliente web, y que en la aplicación no es necesario que la lista de artículos de una empresa cliente muestre todos sus detalles al mismo tiempo o en la misma página.

Idealmente, estos nuevos backends BFF deben construirse en estrecha colaboración con cada frontend que lo consumirá, para garantizar que cada uno satisfaga adecuadamente las necesidades de sus clientes.

Si ambos clientes (Web y Móvil) solicitan información de la misma ruta API, el Móvil recibiría todos los datos, al igual que el cliente Web, pero no utilizaría la mayor parte de ellos, consumiendo recursos de red innecesariamente, y consecuentemente haciéndolos más lentos y pesados, aunque al final simplemente descartará la mayor parte de esta información.

Por lo tanto, la creación de dos BFF resolvería este problema, ya que ambos leerían de la misma ruta API, uno de ellos devolvería todo y el otro solo un subconjunto de la información que utilizará el cliente móvil.

Esto también reduce en gran medida el trabajo del front-end para recopilar toda la información de diferentes fuentes, ya que BFF ya lo ha hecho, incluso haciendo pequeños ajustes en los formatos de los datos devueltos.

Además, con el uso de BFFs es posible aplicar diferentes lógicas por cliente, como reglas de autenticación o autorización, reglas de negocio, comunicación de posibles errores al front-end, con solo la información mínima necesaria, o enlaces a otras funcionalidades que pueden cargarse a demanda, a medida que el usuario accede a otras páginas.

Consideraciones finales

Por supuesto, este fue un ejemplo ligeramente sesgado, pero cuando necesites realizar solicitudes a 2, 3 o más API diferentes, a veces llamando a más de una ruta en cada una de ellas para mostrar una página con toda su información, hazlo trayendo solo los datos estrictamente necesarios, lo que reducirá en gran medida la carga que tendrán que soportar los equipos de tus usuarios, ahorrando red al reducir el tráfico.

Como las posibilidades, cuando se trata de arquitectura de software, son siempre tan numerosas, recomiendo encarecidamente que leas los dos artículos citados anteriormente para comprender este patrón aún más profundamente y juzgar si se ajusta o puede adaptarse a las necesidades de tu empresa, proyecto o equipo.
¿Has utilizado ya la arquitectura BFF en alguno de tus proyectos? ¿Cuáles fueron los principales desafíos que encontraste? En tu opinión, ¿cuáles son las mejores y peores experiencias de trabajar con este patrón?