[Article] Micro-frontend #230
Conversation
bdumas1
force-pushed
the
add-article/micro-frontend
branch
from
32accfd
to
15f2b28
Compare
| Le produit général se retrouve avec des bases de codes plus petites, plus cohérentes et maintenables. Mais aussi avec des équipes découplées et autonomes permettant de gagner en évolutivité. Tout cela favorise une mise à jour, une mise à niveau ou une réécriture des parties du frontend, bien plus progressive qu’auparavant. | ||
|
|
||
| Quel est le coût d’une telle architecture ? Il peut y avoir des fragmentations dans la manière dont les équipes travaillent et qui peut être causée par l’autonomie qui leurs sont accordées. | ||
| Plus les équipes augmentent, plus il devient difficile de s’assurer que les connaissances sont transférées et que les équipes ne deviennent pas cloisonnées. |
There was a problem hiding this comment.
Ce n'est pas contradictoire ?
D'un côté, on comprends que l'archi micro frontend sert à rendre indépendant des équipes.
Ici, on dit qu'il faut s'assurer que les équipes ne soient pas cloisonnées.
Je crois que je vois l'idée, mais ça manque peut-être d'une petite phrase ou d'un détail pour éviter l'ambiguïté.
Co-authored-by: Willy Malvault <4182953+vlamy@users.noreply.github.com>
Co-authored-by: Willy Malvault <4182953+vlamy@users.noreply.github.com>
Co-authored-by: Willy Malvault <4182953+vlamy@users.noreply.github.com>
Co-authored-by: Willy Malvault <4182953+vlamy@users.noreply.github.com>
Co-authored-by: Willy Malvault <4182953+vlamy@users.noreply.github.com>
Co-authored-by: Willy Malvault <4182953+vlamy@users.noreply.github.com>
Co-authored-by: Willy Malvault <4182953+vlamy@users.noreply.github.com>
Co-authored-by: Willy Malvault <4182953+vlamy@users.noreply.github.com>
Edit de la partie charte graphique
Co-authored-by: Liveche <55979648+Liveche@users.noreply.github.com>
Co-authored-by: Jean-Baptiste Mille <jibidus@gmail.com>
Co-authored-by: Jean-Baptiste Mille <jibidus@gmail.com>
Co-authored-by: Jean-Baptiste Mille <jibidus@gmail.com>
bdumas1
force-pushed
the
add-article/micro-frontend
branch
from
ee325bc
to
ab1d608
Compare
| Cette problématique est aussi présente sur des applications frontend monolothique. C'est encore l'architecture que l'on retrouve malheuresement le plus souvent dans les logiciels Web. | ||
|
|
||
| Le micro-frontend propose alors une approche différente. C’est un style d’architecture dans lequel des **sous-produits fronts indépendants** sont **composées ensemble pour former un tout plus grand**. | ||
| Par exemple, avec l’approche DDD (Domain Driven Design), on peut voir les sous-produits comme des "sous-domaines" (bounded context) d’un domaine. |
There was a problem hiding this comment.
Il pourrait être interessant de clarifier la notion de Domain Driven Design en mettant un lien vers la page wikipedia ou de la dddCommunity ;)
| Le micro-frontend vient alors en aide. C’est un style d’architecture dans lequel des **sous-produits fronts indépendants** sont **composées ensemble pour former un tout plus grand**. | ||
| Si l’approche DDD (Domain Driven Design), voyez les sous-produits comme les sous-domaines d’un domaine. | ||
| Pour cela, chaque sous-produit d’un produit applicatif est sous la responsabilité **d’une seule équipe fullstack autonome**, et n’a ainsi pas besoin de se coordonner avec quelqu’un d’autre pour le mettre en production. | ||
| Ainsi, celle-ci a donc la responsabilité **du backend et du frontend**, on y trouve donc des développeurs fullstack et/ou des développeurs backend et/ou des développeurs frontend. |
| Depuis quelques années, plusieurs approches ont été inventées pour faire cela : | ||
|
|
||
| - avoir une convention de dénomination stricte : | ||
| par exemple avec la [syntaxe BEM](http://getbem.com/) qui s’assure que les sélecteurs sont appliqués seulement aux endroits prévus (dans un composant par exemple) |
There was a problem hiding this comment.
Double répétition de "par exemple".
Je pense que : "La syntaxe BEM qui s’assure que les sélecteurs sont appliqués seulement aux endroits prévus (dans le cadre d'un composant par exemple) et avec une syntaxe précise" devrait suffire !
| - avoir une convention de dénomination stricte : | ||
| par exemple avec la [syntaxe BEM](http://getbem.com/) qui s’assure que les sélecteurs sont appliqués seulement aux endroits prévus (dans un composant par exemple) | ||
|
|
||
| - l’utilisation d’un préprocesseur, comme [SASS](https://sass-lang.com/) ou [LESS](http://lesscss.org/) |
There was a problem hiding this comment.
Il pourrait être intéressant de préciser (en une petite phrase, comme pour BEM) en quoi l'utilisation d'un préprocesseur peut être une solution.
En effet ce type de préprocesseur permet de structurer / hiérarchiser le css ce qui a pour effet de limiter les effets de bords.
|
|
||
| - l’utilisation d’un préprocesseur, comme [SASS](https://sass-lang.com/) ou [LESS](http://lesscss.org/) | ||
|
|
||
| - appliquer les styles programmatiquement avec des modules CSS ou avec du CSS-in-JS, pour garantir que les styles sont appliqués juste au bon endroit |
There was a problem hiding this comment.
| - appliquer les styles programmatiquement avec des modules CSS ou avec du CSS-in-JS, pour garantir que les styles sont appliqués juste au bon endroit | |
| - appliquer les styles programmatiquement avec les [Css modules](https://github.com/css-modules/css-modules) ou avec du [CSS-in-JS ](https://github.com/css-modules/css-modules), pour garantir que les styles sont appliqués aux bons endroits |
|
|
||
| - appliquer les styles programmatiquement avec des modules CSS ou avec du CSS-in-JS, pour garantir que les styles sont appliqués juste au bon endroit | ||
|
|
||
| - l’utilisation du [shadow DOM](https://developer.mozilla.org/fr/docs/Web/Web_Components/Using_shadow_DOM) avec des [Web Component](https://developer.mozilla.org/fr/docs/Web/Web_Components) par exemple |
There was a problem hiding this comment.
Pareil que ci dessus, une petite phrase d'explication serait vraiment top :)
|
|
||
| - l’utilisation du [shadow DOM](https://developer.mozilla.org/fr/docs/Web/Web_Components/Using_shadow_DOM) avec des [Web Component](https://developer.mozilla.org/fr/docs/Web/Web_Components) par exemple | ||
|
|
||
| ## Peut-on utiliser une bibliothèque de composants partagés |
There was a problem hiding this comment.
| ## Peut-on utiliser une bibliothèque de composants partagés | |
| ## Peut-on utiliser une bibliothèque de composants partagés ? |
| Chacune des équipes va donc créer son propre composant produit, avec ses propres règles. Ensuite, une équipe annexe, a la responsabilité de fusionner les règles du composant définies par les équipes A et B en respectant la charte initiale. Cette fusion va donner aux équipes de développement un composant produit de référence, disponible dans une bibliothèque qui leurs est accessible. | ||
| Cette équipe annexe n'est même pas dans l'obligation de fournir un composant de référence dans une bibliothèque, mais peut simplement emettre aux équipes de développement les règles CSS (padding, marging, fonts, taille etc...) qui doivent être respectées. | ||
|
|
||
| ## L'anarchie des micro-frontends |
There was a problem hiding this comment.
Sans rentrer dans le débat de l'anarchisme, je pense que le terme à utiliser ici est "Chaos" ("Le chaos des micro-frontends") ;)
|
|
||
| L'architecture en micro-frontend gagne de plus en plus en popularité. Mais elle est parfois mal utilisée, voir utilisée avec abus. Un biais commun, est le mélange de technologies et d'outils, laissant place à une complexité indéniable comme par exemple l'utilisation de plusieurs frameworks structurants (`React`, `Vue`, `Angular`) ou diversifier à outrance la gestion du style (une application avec SASS, l'autre en BEM, ou encore avec du CSS-in-JS). Tout cela déteriore la cohérence technique de l'application globale. | ||
| Même si les équipes sont complètement autonomes dans un système micro-frontend, il faut tout de même essayer de standardiser les approches et les technologies utilisées. | ||
|
|
There was a problem hiding this comment.
Il manque une petite conclusion en lien avec l'introduction / problématique afin de terminer proprement le papier :)
There was a problem hiding this comment.
Une architecture microservice permet d'une part l'utilisation et la cohabitation de technologies et d'outils hétérogènes, d'autre part, un fonctionnement sous forme de multiples équipes polyvalentes et autonomes.
Concevoir une application web sous la forme de microservices développés par plusieurs équipes nécessite une harmonisation et une spécification des pratiques.
Du point de vue front, le développement doit s'effectuer dans le respect de règles claires et tout particulièrement en ce qui concerne la cohérence des règles css. En effet des conventions de nommage ou l'utilisation d'outils dédiés permettent d'écarter en grande partie les conflits liés aux règles.
L'utilisation d'une bibliothèque de composant commune aux équipes apparait en faveur de la conservation d'une unité graphique. Celle-ci peut par ailleurs être améliorée au fur à mesure des développements afin d'être adaptée aux besoins.
Enfin, confier la réalisation d'une charte graphique ainsi que le maquettage à une équipe dédiée (UX / UI) permet d'obtenir des directives claires qui permettent à chaque équipe de développeurs de produire leurs services de manière cohérente.
Le succès de la conception d'un produit avec une architecture microservices ne repose pas exclusivement sur la qualité des outils et technologies utilisés. Mais dépend principalement des modes de fonctionnement et d'organisation permettant la bonne coopération des équipes.
| - frontend | ||
| - front | ||
| --- | ||
|
|
There was a problem hiding this comment.
Hello, ci dessous un brouillon d'une intro à ajouter / merger avec autres choses ;)
Dans le domaine du génie logiciel, les microservices désignent un type d'architecture dans lequel un ensemble de services indépendants et autonomes forment un tout cohérent.
Contrairement à une approche monolithique dans laquelle tous les éléments du logiciel sont étroitement liés, l'approche micro service consiste à fragmenter la logique en de multiples composants (écrits/basés sur différentes technologies) qui communiquent via des API définies.
Du point de vue des développeurs, l'idée principale repose dans la possibilité de gérer chaque service comme un projet à part entière, ce qui en facilite entre autres, la maintenance, l'évolution et la gestion projet.
En effet, une telle approche permet une répartition des différents travaux entre les équipes tout en leur accordant autonomie et liberté concernant leur organisation et leurs choix des technologies.
Dans le domaine du web l'approche microservice est souvent utilisée dans le cadre de l'implémentation de backends. Ceux-ci fonctionnent communément sous la forme d'un ensemble d'API REST qui discutent entre elles et / ou répondent aux requêtes des interfaces utilisateurs.
De manière similaire, la conception d'interfaces graphiques peut suivre une logique analogue. L'idée principale réside sur le principe de composition. En effet il s'agit d'une architecture dans laquelle des sous-produits fronts indépendants sont assemblés pour former un tout plus important, une application.
L'approche microservice appliquée au frontend et au backend permet de confier la réalisation d'une fonctionnalité à une équipe autonome et polyvalente chargée de sa conception dans son ensemble, de la gestion des données à leur présentation.
Dans le cadre de l'élaboration d'un logiciel, l'autonomie des équipes peut être une source de conflits et difficultés. C'est la raison pour laquelle il est nécessaire de définir un cadre et des règles de construction claires afin de coordonner et synchroniser les travaux afin d'aboutir à un produit cohérent.
Ce document se focalise sur l'application d'une approche microservice du côté du frontend. Avec quelles méthodes / outils les équipes peuvent-elles coordonner leur travaux et garantir la livraison d'un produit fonctionnel ?
En effet la cohérence des styles, l'utilisation de bibliothèques partagées et d'une charte graphique sont autant de modes de fonctionnement en faveur d'une appréhension et application correcte du paradigme.
No description provided.