Angulaire et micro-frontends
Je suis en train de faire des recherches sur la manière de diviser un énorme monolith d'une page en une architecture à micro-interface.
L'idée:
- la page est composée de plusieurs composants qui fonctionneraient de manière autonome
- chaque composant est géré par une équipe de développement
- chaque équipe peut modifier, mettre à jour et déployer ses composants sans briser les composants des autres équipes
- chaque équipe choisit sa propre pile d'outils
La raison
Pour développer efficacement des applications volumineuses, de nombreuses personnes doivent y travailler. Cependant, le nombre de développeurs par application/équipe ne s'adapte pas bien. Le développement parallèle de plusieurs applications indépendantes par des équipes indépendantes peut toutefois être dimensionné de manière arbitraire
Dans cet esprit, il est impératif que les équipes puissent choisir leur propre pile d'outils et surtout effectuer des mises à niveau indépendantes des versions de bibliothèques tierces (telles que angular, react, jquery). Si ce n'était pas le cas, une mise à jour du framework devrait être compatible avec chaque composant avant de pouvoir la déployer en production.
Est-ce que cela fonctionne avec Angular?
Bien que des mises à niveau de version indépendantes soient nécessaires, il serait raisonnable de limiter les équipes à quelques frameworks pris en charge (Angular, React, Vue, Polymer ...) et pour l’instant je tente de construire une démonstration uniquement composée d’applications angulaires.
Cependant, même si Angular 5 est censé être une plate-forme-cadre prenant en charge d’énormes applications multi-modules, il semble presque impossible de faire fonctionner plusieurs applications angulaires indépendantes dans la même fenêtre de navigateur.
J'ai réussi à amorcer plusieurs applications angulaires (différentes versions, chacune hébergée sur son propre serveur) sur une seule application Web en utilisant HTML-Imports. Cependant, plusieurs dépendances global doivent être partagées entre les applications.
- zone.js ne peut être démarré qu'une fois
- le routage nécessite des changements d'URL
- Des éléments du navigateur tels que les cookies, le stockage de session, etc ...
Il existe plusieurs articles sur Internet qui expliquent comment amorcer plusieurs modules angulaires, mais ils font tous référence à plusieurs modules dans la même application principale, ce qui signifie qu'ils s'exécutent tous sur la même version de framework et qu'une mise à jour signifie que vous devez reconstruire et déployer le monolithe entier.
Existe-t-il une solution autre que "iframes" pour que plusieurs applications angulaires (5) s'exécutent sur la même page?
Au lieu de suggérer carrément CONTRE cette idée principalement en raison d'exigences de pile distinctes, je vais exposer les compromis et proposer certaines restrictions qui rendront cela possible.
la page est composée de plusieurs composants qui fonctionneraient de manière autonome
Nous savons tous que les composants angulaires sont proposés tels quels, avec une démarcation claire des entrées et des sorties.
Petit CAVEAT: Lorsque/Si vous transmettez des objets pour @Input et émettez des objets d'événement avec des composants @Output() qui interagissent, ils doivent se mettre d'accord sur une interface définie en amont.
Solution: créez un autre projet TypeScript qui définit simplement ces artefacts. Tous les autres "projets de composants" dépendraient d'une version spécifique de celui-ci.
chaque composant est géré par une équipe de développement
Les équipes de développement peuvent distribuer les composants comme le font les autres projets angulaires d'OpenSource. Ils peuvent publier leurs artefacts dans un référentiel NPM. Pour développer des composants imputables, je vous recommande de vous référer à Angular Material2 , ce qui peut être fastidieux ou vous pouvez utiliser quelque chose du genre ngx-library-builder (basé sur Angular Team Member filipesilva/angular-quickstart-lib ) que chaque équipe de composant utilise.
CAVEAT: Jusqu'à cette date, l'équipe angulaire ne dispose pas d'une configuration de projet de partage de bibliothèque de composants rapide, comme le montre Angular CLI. Mais de nombreux développeurs ont créé une sorte de constructeur de bibliothèque pour combler le vide dans Angular CLI.
chaque équipe peut modifier, mettre à jour et déployer ses composants sans briser les composants des autres équipes
Demandez à votre projet principal d'extraire tous les composants et d'effectuer une construction/un déploiement périodique/modifié sur un serveur de CI. Cela produit essentiellement des versions de production AOT avec toutes les dernières versions de composants. En prime, vous pouvez avoir des tests abstraits e2e conçus pour effectuer des tests d'intégration automatisés, garantissant que les effets secondaires d'un composant ne détruisent pas les autres composants.
CAVEAT: Il sera difficile de contrôler la manière dont chaque équipe développe les composants, c’est-à-dire qu’elles optimisent l’utilisation et la disposition de la mémoire, du processeur et des autres ressources. par exemple. Et si une équipe commence à créer des abonnements et ne les supprime pas. Il peut être utile d’utiliser une analyse de code statique, mais vous ne disposerez pas de ce code source pour le moment - à moins qu’ils ne publient également leur code source.
chaque équipe choisit sa propre pile d'outils
C’est un compromis complet sauf si vous entendez "toolstack" comme dans des outils de développement tels que les IDE et certaines des "devDependencies". Bien que certaines parties des "devDependencies" de chaque équipe doivent avoir les mêmes versions exactes des kits de développement angulaires tels que les compilateurs, etc.
Au minimum, chaque équipe doit utiliser les mêmes Angular, RxJS, etc.
Le plus important est de veiller à ce que chaque membre de l’équipe n’amorce aucun composant - seuls les projets principaux auront un module d’amorçage et permettront d’amorcer le composant racine. Cela aidera à répondre à votre problème zone.js
Est-ce que cela fonctionne avec Angular?
Si vous reconnaissez les limites et assurez la gouvernance, je vous conseille d'y aller.
Nous nous sommes posé la même question. Malheureusement, il semble que la réponse à la question
Existe-t-il une solution autre que "iframes" pour que plusieurs applications angulaires (5) s'exécutent sur la même page (éditer: chaque application angulaire peut utiliser une version angulaire différente)?
est actuellement
Non, malheureusement pas, tant que vous voulez utiliser la détection de changement d’Anngular (qui utilise zone.js).
En raison de zone.js, Angular pollue l’envergure mondiale. Pire encore, zone.js corrige un très grand nombre d’API de navigateur ( https://github.com/angular/zone.js/blob/master/STANDARD-APIS.md ) pour détecter le moment où une zone est complétée.
Il n’est possible d’utiliser différentes versions d’un framework dans une page sans effets secondaires que si celui-ci n’a pas une portée globale (cela semble être vrai pour React und Vue). Ensuite, vous pouvez regrouper différentes versions de structure avec chaque application via Webpack (avec une portée et des inconvénients distincts augmentant la taille de chaque groupe d'applications).
Ainsi, si vous souhaitez créer une page Web avec Angular dans laquelle différents applications/modules doivent être intégrés sur une page, la seule solution réalisable consiste à créer un monolithe de déploiement (par exemple, regrouper différents modules de différentes équipes dans une application Angular via un CI./Système CD comme bhantol a expliqué dans sa réponse).
Il semble que l’équipe angulaire soit également consciente du problème et qu’elle pourrait l’aborder avec les versions majeures suivantes. Voir la réponse de robwormwald au sujet suivant de Github concernant la feuille de route pour les éléments angulaires: https://github.com/angular/angular/issues/20891
Espérons que l’équipe Angular fournira davantage d’informations sur ce sujet lors de la publication de la prochaine version majeure, Angular 6, à la fin du mois de mars.
Examinez les éléments angulaires (éléments personnalisés). https://moduscreate.com/blog/angular-elements-ngcomponents-everywhere/
La nouvelle version d'Ionic (4) est totalement basée sur cette dernière pour pouvoir être utilisée sur toutes les versions de Angular et sur tous les frameworks JS.
Pour cela, ils ont créé https://stenciljs.com/ qui vous aideront à créer des éléments personnalisés.
Mais si toutes les équipes utilisent Angular, chacune d’elles peut créer une bibliothèque en utilisant par exemple ngm.
Oui, vous pouvez.
Cependant vous ne voulez pas vraiment rester bloqué dans un framework lorsque vous écrivez des composants Web, car le but d'un composant Web est de pouvoir être réutilisé n'importe où.
Je partage votre vision: la qualité du logiciel, ainsi que la productivité des développeurs, sont indéniablement mieux adaptées aux fonctionnalités ciblées qu'aux grandes applications en matière de mise en œuvre.
Enfin, ce que vous recherchez maintenant n’est pas angulaire, mais StencilJS. Stencil est un compilateur pour les composants Web qui génèrent également un DOM virtuel à l'intérieur de votre composant pour améliorer les performances de son interface utilisateur. Vérifiez-le ;-)
La seule façon d'intégrer différentes applications angulaires en dehors d'IFrames et de la communication via postMessage consiste à les "lier de manière approfondie" et à échanger des informations à l'aide d'URL-Parameter. Toutes les applications angulaires sont ensuite situées sur leur propre onglet de navigateur. Mais pour les composants et services communs, vous souhaiterez peut-être implémenter un "noyau partagé" utilisé par toutes vos applications angulaires, et donc rester bloqué sur une certaine gamme de versions angulaires. Lorsque vous voulez ce noyau partagé, l'approche NGModule est la méthode recommandée. Vous pouvez mélanger les versions Angular 2 et Angular 5 dans une application, car elles sont rétrocompatibles. Il n’ya aucun besoin urgent pour les équipes de s’en tenir à la même version, jusqu’à ce que l’équipe Angular introduise des changements radicaux. Malgré cela, vos dettes techniques augmentent lorsque vous ne procédez pas à la mise à jour. La fréquence des mises à jour techniques est nettement plus élevée dans la zone angulaire/Javascript.
Autre que Iframe, une autre option est actuellement disponible dans le framework SPA, vous pouvez obtenir un exemple de code à partir d'ici.
https://github.com/PlaceMe-SAS/single-spa-angular-cli-exampleshttps://github.com/joeldenning/simple-single-spa-webpack-example
Il semble qu’il existe depuis longtemps une solution à vos besoins. Jetez un coup d'œil au projet Single-SPA ICI .
C'est un projet d'emballage pour vos projets de micro SPA.