Microfronts sur iframe
Dans une entreprise, le CTO a pris une décision équilibrée et délibérée selon laquelle les micro-fronts devraient être sur un pied d'égalité avec les microservices, et ils devraient être servis sur des iframes.
En passant, le produit Office 360 de Microsoft a été donné, auparavant il utilisait `` <iframe /> '' pour les menus supérieur et latéral. Maintenant, les iframes ne sont pas là.
Raisons et conditions préalables pour les micro-fronts
L'un des principaux avantages des microfront-ends est la division des fonctionnalités du monolithe en équipes, la possibilité de mener des tests de bout en bout de manière plus granulaire, et facilite également la vente de logiciels en morceaux (dans le cas des solutions en boîte).
Toutes les applications disponibles sont React SPA. Ils n'ont rien en commun sauf Material UI, React Router v4 et l'embryon UI-kit en tant que modules npm.
Certaines applications seront utilisées et livrées à la fois dans une version autonome et dans le cadre d'une autre application.
Les micro-fronts ont été divisés en grands blocs fonctionnels:
- En-tête de l'application. Routage entre les applications
- Application de tableau de bord. Avec des métriques et des widgets. Chaque widget de tableau de bord doit faire partie de l'application correspondante (connectée via une iframe).
- Les applications elles-mêmes. Certains d'entre eux incluent des parties les uns des autres (mais sans fanatisme et récursivité)
Ainsi, différents cycles de libération sont obtenus, indépendants les uns des autres. Tant que les applications suivent l'API interne.
Problème n ° 0. Mauvaise séparation des micro-fronts
Malheureusement, les micro-fronts n'ont pas été suffisamment réfléchis. Un exemple est une boutique en ligne. Le bouton d'achat et le panier peuvent être dispersés dans de nombreux endroits, mais ils sont tous un micro-front. En tant que fiche produit en 10 variantes, et le processus de commande (où factures et adresses). Tous ces éléments peuvent être des micro-fronts séparés avec leurs propres cycles de publication.
En réalité, il s'est avéré que les candidatures étaient divisées très grossièrement. Par analogie avec une boutique en ligne, c'est à ce moment qu'une équipe crée le panier et la page de paiement, et la deuxième équipe fait le reste (y compris les compteurs de panier sur toutes les autres pages). Dans le même temps, tout le monde utilise la même logique métier, et l'interface est réutilisée au niveau du UI-kit, ou de la bibliothèque Material-UI.
Il s'est avéré que les applications fonctionnelles (marquées en vert et violet) ont beaucoup en commun. Une partie importante de la logique métier de ces deux applications a dû être séparée en une microfront distincte et utilisée. En fait, il existe loin de deux applications de ce type. Au total, il y avait environ sept applications fonctionnelles qui ne réutilisent pas la logique au niveau approprié.
En conséquence, le gain de temps sur la réutilisation des applications a échoué. La duplication des fonctionnalités est également restée à un niveau élevé. L'utilisation de micro-frontaux sans iframes ou de composants avec une logique plus complexe du kit d'interface utilisateur étendu pourrait résoudre le problème de la duplication des fonctionnalités.
Problème n ° 1. Manque d'orchestration des processus
Alors que beaucoup de questions sur l'organisation des microservices ont été abordées. Comment ils vont communiquer entre eux, par quel protocole, l'organisation du processus d'interaction entre microfrontés a été mise en veilleuse.
Afin de neutraliser une fois pour toutes tous les problèmes CORS, il a été décidé de planter nginx, qui gérerait le routage. Ainsi, chaque microfront et chaque microservice avaient sa propre adresse, par exemple: La question demeure, comment tester les applications en mode développement? Chaque application sera-t-elle servie sur un port différent?
https://domain.zone/dashboard
https://domain.zone/header
https://domain.zone/app1
https://domain.zone/app2
https://domain.zone/api1
https://domain.zone/api2
C'est là que le package `http-proxy-middleware` vient à la rescousse, qui peut être configuré en collaboration avec l'ARC. Il s'est avéré que seulement la moitié des développeurs frontaux ont pu mettre en place une telle configuration. Bien sûr, on ne peut blâmer personne ici, mais un tel problème est apparu, et il doit être résolu de manière organisationnelle.
Un versionnage clair de toutes les applications avec une description des fonctionnalités, des méthodes disponibles et de l'API interne est également nécessaire. Cela conduit au problème suivant: la documentation.
Problème n ° 2. Manque d'API interne
Pour que les applications interagissent très bien les unes avec les autres, une documentation est nécessaire. Malheureusement, dans notre cas, seuls les microservices ont de la documentation. Et le regard n'est pas tombé sur les micro-fronts.
Il s'agit d'une partie très critique du système dans le cas d'équipes réparties, et même en cas de rotation du personnel.
Il est également nécessaire de développer un mécanisme de communication entre les applications. Ici, l'API `postMessage` vient à la rescousse, ou l'accès direct à une autre, intégrée à presque toutes les applications React - Redux. Qu'est-ce qui n'est pas un bus de messages? Mais plus là-dessus plus tard.
Problème n ° 3. Iframe n'est pas assez flexible
Il n'y a rien de mal à utiliser la balise `<iframe />`. C'est un outil puissant avec un bus de messages intégré (API postMessage) et une personnalisation étendue de la sécurité.
Cependant, dans le cas des microfronthends, `<iframe />` impose beaucoup de restrictions. L'un d'eux est l'impossibilité de réutiliser une application dans plusieurs parties de la page.
Réutiliser les applications
Dans le cas d'une analogie avec une boutique en ligne, 10 boutons Acheter créeront 10 `<iframe /> '', c'est-à-dire 10 applications React en cours d'exécution. Il n'y a pas assez de mémoire pour cela. C'est l'une des raisons pour lesquelles il n'est pas possible de diviser l'application en équipes par fonctionnalités.
L'URL ne convient pas comme gestion d'état
Nous sommes tous habitués à acheminer les applications via des URL. Ceci est également pratique dans le cas de l'utilisation du micro-front comme unité indépendante. Par exemple, lorsqu'une partie de l'application principale est suffisamment cohérente pour être utile seule. Ce n'est bien sûr pas un avantage unique de l'approche iframe, mais c'est assez simple à faire.
Voici un exemple de la façon dont une application violette de KDPV avec une URL différente peut fonctionner en tant qu'application autonome:
Cependant, utiliser l'interface URL iframe pour changer l'état du microfront dans notre cas s'est avéré impossible: le microfront commence à se charger à partir de zéro en raison d'une intégration incomplète de l'API historique avec son pushState `et React Router - obtenir une pleine page par rafraîchissement.
En dehors des gestionnaires de clics ʻiframe`
Imaginez que vous allez créer un menu déroulant. Comme dans le schéma ci-dessus: depuis le menu rose. Et fermez-le également en cliquant sur un espace vide. Dans le cas d'une iframe, vous devez utiliser l'API postMessage conditionnelle, car un clic extérieur n'est tout simplement pas reconnu en raison de différents objets de fenêtre. Ou trouvez un hack avec un fond transparent de l'élément iframe agrandi en plein écran.
À propos, le redimensionnement de l'iframe et l'ajustement de l'application parente deviennent également plus fastidieux et complexes.
Problème de bonus: utilisation inappropriée des cookies
Ce problème n'est pas directement lié aux micro-fronts, mais il l'amène au niveau de folie suivant.
Il a été décidé d'écrire dans les cookies d'autorisation non seulement le jeton, mais également la liste complète des droits sur certaines parties de l'application. Tout cela a été crypté par SHA - ??? et converti en base64.
En conséquence, la taille du cookie a dépassé 8 Ko, qui est la valeur par défaut pour nodejs / nginx, (ou 2 Ko pour la taille d'un enregistrement de cookie dans Google Chrome), ce qui a conduit à une configuration de serveur plus complexe (sans éjecter CRA, vous ne pouvez pas démarrer avec ce paramètre), et également pour diviser ce grand ensemble de données cryptées en chaînes de cookies plus petites.
Cela signifie que chaque requête au serveur, même pour obtenir `favicon.ico` ou pour obtenir une liste des sections de menu disponibles, est équipée d'un en-tête supplémentaire d'une taille impressionnante.
Conclusion. Comment alors vivre avec les micro-fronts?
Pour commencer, bien sûr, vous devez décider si des micro-fronts sont nécessaires? Souvent, un kit d'interface utilisateur correctement configuré et enrichi sous la forme d'un module npm résout le problème des versions indépendantes et du même style visuel.
- N'utilisez pas iframe. Cela ne simplifie pas le travail, mais ne fait qu'ajouter des problèmes de performances, limitant considérablement la possibilité de diviser l'application en micro-fronts. Le rendu de morceaux de SPA en balises spécialement réservées est une solution beaucoup plus efficace.
- Développer l'orchestration des processus: à la fois en production et en développement. Tous les développeurs ne voudraient pas se plonger dans l'industrie connexe du routage et du proxy lorsqu'il a été embauché pour riveter des interfaces à partir de blocs prêts à l'emploi.
- Développez un bus de messages entre les applications. C'est beaucoup plus facile dans le cas d'un seul espace global, l'objet window.
- Créer une documentation sur l'interface pour l'interaction des applications, ainsi que leur lancement et leur configuration.