¿Qué pasaría si tuviéramos un cliente que nos pide implementar la solución tecnológica
para desarrollar un home banking? Para este ejemplo, imaginemos que el cliente nos
propone un MVP, que consta del manejo de los datos del cliente, cuentas, tarjetas,
inversiones, y un dashboard en el que pueda ver la información resumida de sus productos.
Distintos enfoques de arquitectura para un MVP
Podemos plantear la solución desde distintos puntos de vista:
- Desde el punto de vista de la arquitectura de la solución.
A primera vista, se nos viene la idea de plantear una arquitectura de microservicios,
escenario en el que cada servicio tomaría la responsabilidad de manejar los datos y
procesamiento de cada uno de estos “módulos”. - Desde el enfoque de frontend.
Mayormente iríamos hacia una solución monolítica con cualquier tecnología
conocida (Angular, vue.js, React, etc.).
- Desde el punto de vista de los equipos.
Es probable que tengamos un equipo para el desarrollo del frontend y, gracias al diseño de la arquitectura del backend, podríamos tener diferentes equipos para cada módulo de negocio.
Con este enfoque, tendríamos equipos desarrollando el backend de forma modularizada, con un foco orientado a cada funcionalidad de negocio y un equipo desarrollando el front de dicha aplicación. El inconveniente de esta perspectiva es que, el equipo de backend va a estar desarrollando funcionalidad que todavía el frontend no puede implementar.
- Cada equipo de backend (orientada por módulo) con desarrolladores de frontend que desarrollen el front de dicho módulo.
Esta alternativa genera un cuello de botella en el código del front, ya que es un solo repositorio, y un gran monolito. Esto generará inconvenientes a la hora de mergear o commitear el código. Por otro lado, esta alternativa, a la larga, termina generando en el código del frontend un bloque muy grande, poco mantenible y poco escalable.
Entonces, si ninguno de los enfoques anteriores resulta el ideal, ¿qué podemos hacer en estos casos?
Microfrontend como alternativa de enfoque de arquitectura.
Existen varias alternativas para solucionar este tipo de problemas de negocios. Entre ellas se encuentra el enfoque de microfrontend, que te contamos en detalle a continuación.
Lo que propone la arquitectura de microfrontend, es que el frontend se divida en módulos independientes y que un contenedor se encargue de dibujar dichos módulos, dependiendo de la url, en el segmento de pantalla que tiene asignada a cada microfrontend.
Con este concepto, podríamos tener un contenedor que tenga un header y un menú, y también un espacio asignado para renderizar los módulos
De esta manera, cuando la url es www.hombanking.prueba.com/home, muestra el dashboard y cuando es www.hombanking.prueba.com/inversiones renderiza en ese espacio el módulo de inversiones. También www.hombanking.prueba.com/tarjetas muestra las tarjetas, y así por cada modulo.
Beneficios y tecnologías de la arquitectura de microfrontend
Con esta arquitectura de microfrontend podemos resaltar varios beneficios. En principio, que cada microfrontend podría estar desarrollado en stacks tecnológicos distintos. Pero aparte:
- Cada módulo tendría repositorios de código separados.
- Cada módulo tendría también CI/CD independientes.
- Implicaría un menor tiempo de building del frontend.
- Como resultado, obtenemos,bundles o compilados más livianos.
- La plataforma tendrá mayor disponibilidad ya que, si un módulo sufre un desperfecto, el resto del sitio sigue funcionando.
Ahora, ¿cómo implementamos este tipo de arquitectura? Existen varias tecnologías para implementar arquitecturas de microfrontend, cada una de ellas orientada a diferentes usos y necesidades. Entre ellas se encuentran: bit, single-spa, module federation y luigi.
Veamos entonces un poco más sobre single-spa.
Single-spa, nuestra elección de tecnología para arquitecturas de microfrontend.
¿Por qué elegimos single-spa? Por varias razones:
- El módulo js
Una de las consideraciones del enfoque de microfrontend, es la independencia de los módulos.
A la hora de diseñar los módulos de los microfrontend, debemos aplicar un concepto similar al de los microservicios: los módulos que identifiquemos como microfrontend deberían ser lo más independientes posible para no tener problemas de dependencias.
Suele pasar que hay ciertos puntos en los que tendremos que compartir información entre diferentes microfrontends. Por ejemplo, lo que sucede con el jwt token, o al tratar de centralizar las llamadas https. Para esto, single-spa nos provee la posibilidad de crear un módulo js, en el cual publicaremos las funciones de acceso a la parte compartida
- La estética y los componentes
Otro tema importante a la hora de desarrollar los microfrontends está vinculado a la estética, y los componentes de nuestro sitio. Si tenemos muchos microfrontends, ¿cómo hacemos para no estar reescribiendo los mismo componentes, para no duplicar los css y para mantener toda la estética igual dentro de todos los microfrontends?
Para lidiar con este inconveniente lo recomendable es desarrollar, o utilizar una librería de componentes, que puede ser instalada mediante npm. Pero esto conlleva la siguiente pregunta: ¿cómo manejamos la coherencia de versiones de dicha librería entre nuestros microfrontends?
La ventaja que nos provee single-spa es la de crear una librería de componentes como módulo, el cual pueda ser interpretado como un módulo compartido que pueda ser importado por cada microfrontend en tiempo de ejecución. Eeste módulo es similar al que utilizamos para compartir los llamados https, pero lo que expone son los componentes que tenemos desarrollados.
De esta manera, los desarrolladores no se deberían preocupar por el versionado de la librería, ya que el microfrontend tomará el componente de la versión que esté desplegada.
Arquitectura de microfrontend: ventajas por donde lo mires
En conclusión, con una arquitectura de microfrontend nosotros podríamos tener pensado nuestro home banking con módulos separados, como clientes, cuentas, tarjetas, inversiones y un dashboard en el que cada módulo es independiente.
Todos estos módulos van a estar gestionados por un contenedor, que tendría el menú y el header y sería el encargado de, ante cualquier cambio de url, renderizar cada módulo en el espacio que tenga asignado.
También tendríamos una librería de componentes con el design system del banco, que alojaría todos los componentes que van a ser utilizados por nuestra app, permitiendo, de esta manera, que cada microfrontend tenga la misma estética y los mismos componentes.
Por último, cada equipo sería owner, tanto del front como del back, y hasta podría tener su propio modelo de datos. Cada proyecto, ya sea un microfrontend, librería de componentes o microservicio tendrá sus propios CI/CD independientes.
Así podríamos tener equipos independientes punta a punta, que entreguen valor a nuestro home banking de manera funcional, independiente y sin bloqueantes. Por todo esto, en redbee elegimos usar una arquitectura de microfrontend, sobre todo cuando el proyecto requiere celeridad en el desarrollo y posibilidad de escalar rápidamente.
Si querés saber más sobre arquitectura cloud, podés ver este video en el que te explico más, o seguir leyendo nuestro blog.
