Hace poco tiempo escribí sobre el patrón backend for the frontend (BFF), sus usos frecuentes y su uso para fortalecer la seguridad. Ese análisis estuvo enfocado en su implementación con aplicaciones web para el navegador.

Si aún no lees ese artículo te invito a darte una pasada para que entres en mayor contexto.

¿Estás usando todo el potencial del patrón BFF?

¿Qué pasa cuando se trata de aplicaciones móviles? ¿La implementación es parecida?¿El patrón BFF sigue aportando el mismo valor? Trataré de llevar el análisis a fin de abordar estos puntos.

Con el auge de los dispositivos móviles: celulares, tabletas, wearables entre otros, el desarrollo de aplicaciones móviles creció exponencialmente, este tipo de aplicaciones se caracterizan por su diseño amigable y a la vez dinámico para brindar la mejor experiencia posible a los usuarios. Estas características destacan a las aplicaciones móviles como un tipo de frontend con amplias necesidades de datos para cubrir todos sus requerimientos de negocio. Adicionalmente las aplicaciones móviles tienen las siguientes particularidades que representan todo un desafío para los desarrolladores:

• Fragmentación de sistemas operativos. Los más populares obviamente Android e iOS, cada uno representa un ecosistema tanto para los usuarios como para los desarrolladores.
• Fragmentación de versiones en la misma aplicación. Muchos usuarios desactivan las actualizaciones automáticas y los desarrolladores deben contemplar ese escenario.
• Las aplicaciones móviles suelen necesitar notificaciones y actualización en tiempo real, por lo que suelen requerir mecanismos de integración para cubrir esa necesidad.
• Son aplicaciones que se consideran “públicas”, ya que están destinadas al uso masivo y los usuarios usan mayormente sus planes de datos cuando estas aplicaciones requieren acceso de internet.
• Muchas aplicaciones móviles tienen funcionalidades que necesitan la capacidad de trabajar en modo offline, para luego hacer sincronizaciones contra algún backend.

Veamos como el patrón BFF nos facilita atacar estas particularidades:

1. Para la fragmentación de sistema operativo el patrón BFF aporta flexibilidad para abordar cada SO como un frontend diferente. Cabe mencionar que esto depende del ámbito de la aplicación. Por ejemplo, una aplicación que tenga desarrollo nativo específico para Android e iOS por separado pero en el ámbito de negocio son lo mismo, pueden compartir el mismo BFF. Es claro que para aplicaciones basadas en un stack multiplataforma esta discusión pierde sentido.
2. Para la fragmentación de versiones de la misma aplicación, el patrón BFF aporta un valor notable. Para entender esto debemos reconocer la problemática que representa para una aplicación masiva, que sus usuarios no actualicen a las versiones más recientes. Imaginemos la “App A” que depende de una “API A”, con el desarrollo de la versión V2 de la App A, se requirió la modificación de muchos endpoints de la API A, los desarrolladores deben considerar mantener dos versiones de su API A, la versión V1 que mantiene el formato de los endpoints iniciales y la versión V2 que tiene los nuevos endpoints y los endpoints que cambiaron de formato. Hacer esto es crucial, sino los usuarios que no actualizan de versión de la App A no podrán utilizar la aplicación. Ahora imaginemos el caos con una aplicación móvil que le pega directamente a 10, 20 o 30 APIs. Con una API BFF solo se tiene un punto donde gestionar las versiones, lo cual facilita enormemente su manejo.
3. Para la implementación de actualizaciones en tiempo real y notificaciones push, se suelen utilizar servicios como Firebase o Visual Studio App Center que facilitan mucho esta labor. Ahora imaginemos un escenario donde se requiere ser más estricto por el manejo de datos sensibles y también soberanía, en este escenario el canal BFF puede servir como proxy entre la aplicación móvil y el servicio para implementar la capacidad real time.
4. Al ser las aplicaciones móviles, públicas, se debe poner atención en la forma como se gestiona la authenticación y como se obtienen los tokens de acceso para poder pegarle a las APIs. Si se está usando proveedores OpenID Connect y OAuth2 para la autenticación se sugiere utilizar el flujo de código de autorización con PKCE. Otra forma de reforzar la seguridad es implementar tokens opacados o tokens cifrados que solo pueden ser descifrados en el backend ya sea mediante el uso de la clave privada o mediante introspección. Todos estos mecanismos se facilitan enormemente con una sola API BFF. A diferencia de las aplicaciones de navegador las aplicaciones móviles tienen la ventaja de tener mecanismos de almacenamiento seguro como keychan para iOS y keyStore en Android, estos mecanismos pueden fortalecer el almacenamiento de valores sensibles.
5. Si la aplicación necesita capacidad offline puede cifrar sus datos y almacenarlos localmente en el dispositivo, descifrarlos antes de la sincronización con el API BFF. Toda sincronización de datos reforzado por una comunicación HTTPS.

Conclusión

Las aplicaciones móviles son un escenario totalmente diferente que las aplicaciones de navegador, sin embargo, el patrón BFF aporta notablemente a todos los desafíos y particularidades de este tipo de aplicaciones, facilitando enormemente su desarrollo.

---

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

Referencias

• Microsoft learn - BFF
• AWS - BFF