Conseil en architecture micro frontale
Nous souhaitons présenter plusieurs applications Web sous une seule page. Nous recherchons une architecture/un cadre micro-interface à utiliser. Comme nous le voyons, voici nos options de mise en oeuvre:
- Utilisation du framework open source mono-spa: https://github.com/CanopyTax/single-spa
- Utilisation d'Iframe (Iframes convivial) de l'application d'hébergement (le shell) et chargement de chaque application en fonction de l'URL actuelle.
- Écrire notre propre framework Javascript
- Autre?
L'état actuel est une application FE monolithique qui consomme l'autre application enfant en tant que packages tiers internes .. Cette approche n'est pas évolutive pour nous, car l'application d'hébergement crée tous les produits ensemble et rien n'est vraiment séparé.
Nos exigences sont les exigences habituelles pour micro-frontend: 1. Développement indépendant - Chaque équipe peut choisir ses propres frameworks et construire ses produits indépendamment des autres produits.
Déploiement indépendant - Chaque application peut être mise à niveau en production sans interruption et sans interférer avec les autres applications.
Composants partagés - .__ Nous utilisons Angular4 dans nos applications et nous avons déjà écrit une bibliothèque propriétaire tierce (composants partagés et logique) qui devrait être partagée entre tous les produits pour un aspect similaire.
Nous aimerions avoir la possibilité de mettre à niveau le framework de chaque application (Angular, RXjs, TypeScript, etc. et également pour notre bibliothèque de composants propriétaires) sans se soucier des autres applications.
Nous avons essayé d'utiliser le cadre de spa unique, mais nous avons quelques problèmes et nous sommes actuellement convaincus si c'est la bonne approche pour nous, ou devrions-nous essayer une approche différente.
Les problèmes que nous rencontrons avec le spa unique sont les suivants: 1. Le chargement des actifs est problématique. (Nous devons avoir les fichiers d’actifs dans le dossier racine de l’application d’hébergement et subir des conflits d’actifs lorsque nous passons à une autre application) . 2. Nous ne savons toujours pas comment gérer le style global pour toutes les applications (nous utilisons sass pour le style et il doit être respecté avec les styles locaux de chaque application) 3. Mettre à niveau le cadre angulaire (ou tous les autres cadres) n’est pas possible pour une application, c’est tout ou rien (puisque nous avons un exemple d’angle) . 4. Nous devons mettre en œuvre un regroupement différent pour le développement de l'autre côté de l'application d'hébergement (le shell).
Lorsque nous réfléchissons à la solution Iframe (utilisation d’Ifame convivial), nous visualisons une séparation complète entre toutes les applications pour enfants et avons tendance à croire que cette approche est plus appropriée pour nous.
Existe-t-il des pièges à l’utilisation d’Iframes?
Merci, Daniel
J'aimerais ajouter 2 ¢ au sujet des solutions architecturales possibles pour les microservices de l'interface:
- OpenComponents utilisés par OpenTable - https://github.com/opentable/oc
- Mosaïque de Zalando - https://www.mosaic9.org/
J'espère que vous les trouverez utiles.
Vous pouvez essayer PuzzleJs . Il est conçu pour être une solution-cadre pour l’architecture de micro-interfaces pour la passerelle et la vitrine. Il est utilisé pour la production de notre site Web de commerce électronique à fort trafic. Vous devriez vraiment vérifier.
En fait, il couvre presque toutes vos exigences.
- Déploiements indépendants
- Code source indépendant
- Technologies indépendantes
Et à propos de la solution iframe, il pourrait être difficile de gérer des tâches telles que CORS et la communication avec d'autres iframes.
Mais la solution micro-front n'est pas encore parfaite. Il y a beaucoup de complexités lorsque vous plongez vraiment dans le sujet.
Certains actifs essaieront de déclarer la même variable dans la portée globale et auront parfois des versions différentes qui provoqueront des erreurs. Les équipes ne seront donc pas totalement indépendantes les unes des autres.
La journalisation et la surveillance deviennent extrêmement difficiles. Des outils comme New Relic vous aideront, mais cela ne suffira pas. Vous devez implémenter des outils de surveillance et de rapport d'erreur personnalisés.
Garder les applications dockérisées et à l’échelle automatique est vraiment important. Avec cette architecture, si vous avez 4 passerelles et une vitrine, cela peut être délicat.
Le coût initial de la mise en œuvre d'une architecture de micro-interfaces est assez élevé. Vous devriez considérer votre temps et votre ressource de développement avec soin
La performance est la chose la plus importante. Vous ne voulez pas télécharger Reaction ou d'autres bibliothèques plus d'une fois, car plusieurs équipes les utilisent. Vous devez implémenter DllPluginn pour supprimer les codes en double. Et cela rendra tout plus difficile.
Et il y a beaucoup d'autres problèmes dont je ne me souvenais plus. Si vous n'avez pas plus de 50 développeurs travaillant sur le même projet de vitrine, la micro-interface est une décision excessive.
Étant donné que votre question est un peu large, je ne ferai que répondre à vos questions sur l’utilisation d’Iframes, car vous conseiller sur l’architecture est inutile, sans connaître les circonstances (groupe cible?, Mobile?, Quels sont les KPI? (Performances, charge initiale, coûts de développement, capacité de réutilisation, ...)
Les iframes sont bons pour l'isolation "totale" (code + style), aucune autre approche ne vous donnera cela. Cependant, à cause de cela, ils présentent un beaucoup des inconvénients:
- le partage de données entre iframes nécessite une orchestration dans les SPA externes et internes, ce qui implique la mise en place de mesures de sécurité supplémentaires (chaque SPA étant exposé)
- le style de vos SPA internes par ceux de l'extérieur ne fonctionnera que s'ils se trouvent sur le même domaine et nécessitent un code JS supplémentaire
- le partage des cookies ne fonctionne que si les SPA internes se trouvent sur le même domaine que les SPA externes.
- en termes de performances, chaque Iframe doit tout charger par lui-même; Réutiliser des ressources, des bibliothèques, etc. est très difficile et implique une ingérence dans l'outillage de chaque SPA.
Habituellement, si vous avez tout sous votre contrôle, une meilleure approche frontale est la meilleure solution que l’Iframes.
Vous pouvez exposer les composants Web de chacune de vos applications et les regrouper/les utiliser dans votre SPA principal. Les composants Web sont pris en charge par tous les navigateurs, ainsi que par tous les principaux supports SAP farmeworks (tels que angular, ember, react, vue) supportés par Webcomponent. De cette façon, vous n'êtes pas lié à un framework SPA spécifique et pouvez récupérer les composants n'importe où.
Nous avons actuellement travaillé sur exactement la même chose avec la structure mono-spa. Et nous sommes arrivés aux mêmes conclusions que vous. Un problème majeur pour nous était la traduction pour une application enfant, car au moins nous ne pouvions pas trouver un moyen de les regrouper avec l’application enfant. D'autres éléments, tels que les styles, posent également problème.
Ma suggestion serait d’attendre les éléments angulaires puisque le cadre n’est pas conçu pour être utilisé dans un style micro-frontal.