Arquitectura de aplicaciones frontend empresariales

• Que el codebase crezca = se vuelve más difícil de entender y modificar

• ¿La solución? Mantener el codebase pequeño.

• ¡Separación del codebase por dominio y micro frontends al rescate!

• Las necesidades como definir relaciones de dependencia entre librerías dentro de un monorepo y verificar dependencias se resolvieron adoptando Nx

• Separar el código en aplicaciones y librerías

• Las aplicaciones cumplen el rol de inyectar dependencias y configuración

• La mayor parte de la funcionalidad se implementa en las librerías

  • En las librerías se escribe no solo el sistema de diseño, la internacionalización y los módulos de terceros que pueden usarse de forma general, sino también código no reutilizable como el hero banner de la página principal, la página de detalle de producto y el historial de pedidos.

Librerías Feature

• En principio, todos los componentes usados en una misma página se escriben en una librería Feature con el mismo nombre

  • ej.) todos los componentes de la página SignInPage del dominio account se escriben en la librería account/feature-sign-in

• Los componentes compartidos por dos o más páginas del mismo dominio se separan en un feature distinto dentro de ese dominio

  • ej.) si el componente KakaoLoginButton se usa en común en SignInPage y SignUpPage del dominio account, ese componente se escribe en la librería account/feature-social-login

• Los componentes compartidos por páginas de distintos dominios se separan en un feature distinto dentro del dominio compartido

  • ej.) el componente GlobalNavigation, compartido entre HomePage del dominio landing y LecturePage del dominio classroom, se escribe en la librería shared/feature-navigation

Librerías Shell

• Combinan componentes de librerías Feature y UI para crear páginas

  • ej.) el componente SignInPage es un componente de la librería account/shell-kr-web. Ahí también están SignUpPage, PhoneVerificationPage, etc.

• Las librerías Shell son el punto de entrada de un dominio específico que se ofrece a la aplicación

• Pueden proporcionar distintos puntos de entrada según la aplicación

  • Por ejemplo...

  • Los componentes usados en el componente HomePage están escritos en la librería landing/feature-home.

  • Pero incluso siendo la misma HomePage, su composición será diferente según si es la HomePage del sitio de Estados Unidos, Japón o Corea.

  • Por lo tanto, se pueden crear librerías shell para cada aplicación que accede al dominio landing. (shell-us-web, shell-jp-web, shell-kr-web)

Librerías Provider

• Librerías que gestionan estado compartido entre dos o más librerías Feature

  • ej.) shared/provider-auth-state, que gestiona el estado de inicio de sesión

Librerías UI

• Conjunto de componentes presentacionales compartidos entre dos o más librerías.

Librerías Utility

• Todos los módulos que no encajan en las cuatro categorías anteriores

• Deben ofrecer funcionalidades lo suficientemente independientes como para poder probarse y desplegarse sin relación con el modelo de dominio de Class101.

  • ej.) shared/utils-apollo-client, shared/utils-i18n

Aplicaciones

• Terminan encargándose solo de la configuración y la gestión de dependencias = casi no hay código en la aplicación