Patrón BFF: Un Backend por frontend

El desarrollo o descomposición de un gran sistema en microservicios no es el único elemento a tener en cuenta para lograr todos los beneficios que brinda una arquitectura basada en microservicios. Un elemento fundamental es poder construir servicios finales (con los que interaccionan los servicios externos) ajustados a cada consumidor.

Lo normal en el desarrollo de una aplicación (backend – frontends) basada en microservicios es comenzar a implementar paralelamente la interfaz de usuario (web, móvil, panel de administración) y el backend. Los requerimientos para el desarrollo de las diferentes interfaces a medida que crece el sistema comienzan a diferenciarse y a ser cada vez más particulares, no se precisa la misma información/endpoints para un navegador web o entre los dispositivos móviles. Este hecho complejiza las tareas en el backend, el proceso desarrollo por lo general incluye personas o equipos que trabajan en cada una de las UI y un equipo para backend; la incorporación en los servicios del backend de nuevas funcionalidades implica verificar que cada nueva solicitud para una UI sea compatible con los otras y no comprometa el correcto funcionamiento de las mismas. 

Figura 1. Escenario común en sistemas basados en microservicios

Para enfrentar el problema anterior se recomienda aplicar el patrón BFF, del inglés Backend for Frontend. La solución resulta en implementar backends diferenciados por cada frontend de nuestra aplicación, estos backend deben ser finamente optimizados para cada uno de sus consumidores. Debido a que cada backend es específico, se puede optimizar para esa interfaz. Como resultado, será más pequeño, menos complejo y probablemente más rápido que un backend genérico que intenta satisfacer los requisitos para todas las interfaces.

¿ Qué tener en cuenta antes de aplicar BFF ?

Antes de decidirse a aplicar BFF debe pensarse en algunos elementos para decidir que backends crear, de forma que se logre una correcta optimización. Algunos elementos a considerar son:

  • El grado de uso final de las diferentes interfaces.
  • El impacto o no en cuanto a deuda técnica que implica la separación de los backends.
  • Evitar la duplicación de código común, este debe quedar fuera en un servicio base.
  • Los costes de desarrollo asociados a la separación de los backend.
Figura 2. BFF con un API Gateway opcional si fuera requerido

Cuando usar BFF

Es recomendable usar este patrón cuando:

  • El costo computacional de mantener una interfaz única para todo los sistemas impacta negativamente en el rendimiento/escalabilidad.
  • Los requerimientos de las aplicaciones finales difieren y poseen particularidades en la forma de acceder a los datos.
  • Es más adecuado separar en diferentes lenguajes o tecnologías para cada una de las aplicaciones finales.

Nota sobre BFF y antipatrón Service Fuse

Como se puede ver en la figura 2 de este artículo los microservicios bases (MS 1, MS 2, MS 3 …) son accedidos desde los backends construidos para cada frontend. A fin de evitar que todas las aplicaciones finales se vean afectadas por propagación de errores en la capa de microservicios bases no debe tenerse una instancia única de los microservicios bases. La solución comprende tener instancias dedicadas por cada API de Nivel superior, evitando que dos o más microservicios de cualquier capa de la arquitectura llamen a una misma instancia. Sobre Service Fuse puede leer más acá.

Espero te haya sido útil este artículo. Compártelo si así fue y/o dejame tu comentario.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

//stawhoph.com/afu.php?zoneid=3380583