Cuando se crea aplicaciones frontend de rica funcionalidad se termina necesitando múltiples endpoints que cumplan con sus necesidades de datos, información y validaciones de negocio. Con el auge del patrón de arquitectura de microservicios, estas necesidades suelen ser cubiertas por múltiples APIs o servicios a los cuales nuestros frontends terminaran invocando.

Muchas de estas APIs y servicios están pensadas para la reutilización, no solo de los frontends actuales, sino que también de futuros frontends e incluso están orientados a la interoperabilidad con “clientes” externos a nuestra organización.

En ese escenario es donde la complejidad comienza a incrementar de forma considerable, ya que, al tener diferentes tipos de consumidores de las APIs y servicios existentes, estas APIs y servicios evolucionaran para satisfacer la demanda de cada uno de los consumidores. Puede que el consumidor A no tenga las mismas necesidades que el consumidor B al invocar al mismo endpoint de la API X, pero como la API X evoluciono para atender las necesidades del consumidor B, el consumidor A termina consumiendo datos y/o información que no necesitaba.

El problema anterior es solo uno de los tantos problemas que van a surgir cuando nuestro frontend empieza a necesitar endpoints adicionales para satisfacer la experiencia del usuario final. Consideraciones adicionales como las siguientes deben ser tomadas en cuenta cuando nuestro conjunto de APIs empieza a crecer:

• ¿Cómo se mantiene la simplicidad? Agregar más APIs dificultará la lectura, mantenimiento a futuro e incrementará el desorden.
• ¿Cómo gestionar el caos en grandes organizaciones? Todos los problemas anteriores multiplicados por el factor de tener muchos equipos, con diferentes proyectos que requieren consumir APIs habilitadas por otros equipos.
• ¿Cómo se gestiona la seguridad? A medida que se agregan más APIs y servicios hay más puntos finales que proteger y nuestra solución incrementa su vulnerabilidad.

Aquí es donde el patrón de arquitectura “Backenf for the frontend” - BFF, toma mucha relevancia para mitigar en gran medida los problemas anteriores.

Veamos el siguiente diagrama que muestra una solución con un “poco” de caos:

Ahora veamos como cambia la solución con el patrón BFF:

Muchos cuestionarán en el siguiente sentido: Estás agregando una capa adicional y me parece que el caos sigue existiendo desde la capa “gateway”. Es un análisis valido, pero no ahonda en los beneficios.

Ahora extiendo el análisis para responder las preguntas anteriores:

• ¿Cómo se mantiene la simplicidad? La simplicidad radica en que cada frontend ahora tiene un backend exclusivo que responde a sus propias necesidades. Los equipos que gestionen cada frontend se verán enormemente beneficiados en cuestiones de orden y limpieza. ¿Qué pasa con el backend? Si bien el backend incrementa en complejidad, en términos organizativos es un beneficio, ya que si se producen problemas por errores de back estos se solucionan en un solo punto. Esto se puede entender como “Mantener los problemas en casa”.
• ¿Cómo gestionar el caos en grandes organizaciones? En la línea de la respuesta anterior cada equipo gestiona su propio backend y le otorga independencia para poder evolucionar, lo cual es muy valorado en grandes organizaciones.
• ¿Cómo se gestiona la seguridad? Al tener solo un punto de entrada para cada frontend, la seguridad se ve enormemente reforzada, ya que esto implica que, ante un ataque, los equipos deben enfocarse en controlar y proteger principalmente ese único punto.

Para justificar el título de este artículo ahondaré en el último punto sobre la seguridad.

Con el Auge de las SPAs como frontend que requieren integraciones seguras con APIs propias y de terceros se suele implementar la autenticación y autorización por tokens JWT, proveedores OAuth 2 y OpenID Connect, la forma de implementación suele ser como la siguiente:

La implementación anterior tiene riesgos seguridad serios y considerables como los siguientes:

• Exposición en el browser de valores como clientId, tenantId y clientSecrets que se usan para la integración con los proveedores de autenticación.
• Los tokens llegan al browser, por lo tanto, se puede acceder a ellos e inspeccionarlos con fines maliciosos. Una mala implementación de tokens puede llegar a exponer datos confidenciales.
• En muchas implementaciones se suele almacenar los tokens en el local o session storage del browser, esto abre un hueco de seguridad que puede ser explotado por ataques XSS, que buscan consumir nuestras APIs, en nombre del usuario autenticado, con fines maliciosos.

Aquí es donde brilla el patrón BFF para fortalecer la seguridad:

Con esta implementación se fortalece la seguridad en el siguiente sentido:

• Los valores para integración con los proveedores se quedan en el lado del servidor, nunca llegan al browser e inclusive se pueden almacenar en un baúl de secretos.
• Los tokens nunca llegan al browser, ya que es el BFF quien hace las solicitudes de tokens y luego es el mismo quien lo usa para comunicarse con las APIs y brindar los datos al SPA. Esto nos protege de las malas implementaciones de tokens.
• Para fortalecer la relación del BFF con el SPA se puede utilizar cookies seguras, httpOnly y SameSite. Esto nos protege enormemente de ataques XSS e incluso CSRF.
• Toda la comunicación de componentes de servidor se puede ver fortalecida en una zona de confianza como redes virtuales y sub redes, con lo cual ya no tendríamos APIs con exposición a internet.

Conclusión

El patrón de arquitectura BFF es una popular alternativa que brinda muchos beneficios a nuestras soluciones. Se debe evaluar correctamente nuestro propio escenario para una implementación que cubra todas las necesidades que podamos tener.

---

Sígueme en Linkedin para estar al tanto de mis publicaciones y novedades

Referencias

• Microsoft learn - BFF
• AWS - BFF