Architecture d’applications frontend pour l’entreprise

• Une base de code qui grossit = une base plus difficile à comprendre et à modifier

• La solution ? Garder la base de code de petite taille.

• Séparer la base de code par domaine & les micro-frontends à la rescousse !

• Les besoins comme la définition des relations de dépendance entre bibliothèques dans un monorepo et la vérification des dépendances ont été résolus par l’adoption de Nx

• Séparer le code entre applications et bibliothèques

• Les applications jouent le rôle d’injection des dépendances et de la configuration

• La majeure partie des fonctionnalités est implémentée dans les bibliothèques

  • Dans les bibliothèques, on écrit non seulement le design system, l’internationalisation et les modules tiers réutilisables de façon générale, mais aussi du code non réutilisé comme la bannière hero de la page d’accueil, la page de détail produit ou l’historique des commandes.

Bibliothèques Feature

• Par défaut, tous les composants utilisés sur une même page sont écrits dans une bibliothèque Feature portant le même nom

  • ex) pour la page SignInPage du domaine account, tous les composants sont écrits dans la bibliothèque account/feature-sign-in

• Les composants partagés entre deux pages ou plus d’un même domaine sont séparés dans une feature distincte au sein de ce domaine

  • ex) si le composant KakaoLoginButton est utilisé en commun par SignInPage et SignUpPage du domaine account, ce composant est écrit dans la bibliothèque account/feature-social-login

• Les composants partagés entre des pages de domaines différents sont séparés dans une feature distincte du domaine partagé

  • ex) le composant GlobalNavigation, partagé entre HomePage du domaine landing et LecturePage du domaine classroom, est écrit dans la bibliothèque shared/feature-navigation

Bibliothèques Shell

• Les pages sont construites en combinant les composants des bibliothèques Feature et UI

  • ex) le composant SignInPage est un composant de la bibliothèque account/shell-kr-web. On y trouve aussi SignUpPage, PhoneVerificationPage, etc.

• Les bibliothèques Shell sont les points d’entrée d’un domaine spécifique fournis à l’application

• Elles peuvent fournir des points d’entrée différents selon l’application

  • Par exemple...

  • Les composants utilisés dans le composant HomePage sont écrits dans la bibliothèque landing/feature-home.

  • Mais même pour une même HomePage, la composition diffère selon qu’il s’agit de la HomePage du site américain, japonais ou coréen.

  • Il est donc possible de créer une bibliothèque shell pour chaque application accédant au domaine landing (shell-us-web, shell-jp-web, shell-kr-web)

Bibliothèques Provider

• Bibliothèques qui gèrent l’état partagé entre au moins deux bibliothèques Feature

  • ex) shared/provider-auth-state, qui gère l’état de connexion

Bibliothèques UI

• Ensemble de composants de présentation partagés entre au moins deux bibliothèques.

Bibliothèques Utility

• Tous les modules qui n’entrent pas dans les quatre catégories ci-dessus

• Ils doivent fournir des fonctionnalités suffisamment indépendantes pour pouvoir être testées et déployées sans lien avec le modèle de domaine de CLASS101.

  • ex) shared/utils-apollo-client, shared/utils-i18n

Applications

• Elles n’assurent plus qu’un rôle de gestion de la configuration et des dépendances = le code applicatif est quasiment inexistant