Chlouchloutte ¯\_(ツ)_/¯
Une vision du micro-service back.
Je garde ça sous le coude, ça peut amener des débats.
Bon, même si je ne vois pas encore d'intérêt technique à cette façon de faire, je note l'article.
J'ai lu avec attention l'article.
J'ai du mal à sérieusement considérer une solution qui passerait par des iFrame...
Pour moi, ça n'est pas la bonne solution.
Encore une fois, la personne qui a écrit ça s'est concentré sur l'organisation des équipes autour de l'output. Je verrai plutôt à me demander comment gérer une équipe autour d'un travail.
Le problème avec les équipes autonomes sur des périmètres restreints, c'est le SILO. Donc, à mon sens, c'est un non-sens que de vouloir créer encore plus d'équipe en autarcie au sein d'une même application. Il faut une SEULE équipe autonome, qui se répartit le travail sur les différents morceaux.
1 tâche => 1 poste, at scale, ça fait : 1 segment => 1 équipe... Taylorisme, quand tu nous tiens...
Mais le silo a cet avantage certain qu'il nous évite d'avoir à communiquer et collaborer avec les autres. C'est très confortable quand on ne choisit pas ses collègues.
Je préfère la solution de Audrey Neveu consistant à inclure une lib dans une SPA, qui gère le menu.
Une propal de micro-front. On découpe le front avec les micro services et on les insère dans un "portail".
Premier essai via web-components :
Les pours :
- Look and feel consistant
- Plusieurs composants sur la même page
- Indépendant au niveau déploiement entre les composants
Les contres :
- Pas une SPA (on recharge tout à chaque fois)
- Mauvaises performances (notamment duplication librairies)
- Dépendances entre SPA qui rentrent en conflit.
- Mécanisme de routing (basé sur les #) : A redéfinir totalement pour éviter les conflits : conflit entre apps
- Installation de la stack lourd (surtout en local pour du test)
Second essai via les React Fragments (avec Tailor pour résoudre les temps différents de réponse entre les différentes applications) :
Les pours :
- Possibilité de partager des composants réact entiers
- Système de routage centralisé
Les contres :
- Dépendances entre libs : toujours un pb
- Dépendances de Réact encore plus problématiques
Troisième essai avec Layout-as-lib (c'est Layout-as-lib qui est la librairie qui s'inscrit dans les applications). Layout-as-lib est masqué par défaut pour la version "legacy" et affichée en cas de besoin dans les différentes SPA.
Les pours :
- Plus facile d'utiliser une lib dans une SPA que l'inverse : Intégration en 1,5 jour
- Plus rapide
- Indépendance dans le développement et le déploiement : on release chaque SPA distinctement
- Plus de conflit de librairie
- On ne peut continuer à tester que son composant
Les contres :
- Pas de SPA du tout (mais c'est pas grave dans leur cas)
- Pas de possibilité d'aggregation de composants (mais c'est pas grave dans leur cas)
- Expérience utilisateur peut être incohérente : Une SPA n'a pas l'appel à la lib à la même version que l'autre SPA
- Des changements majeurs dans la navigation doivent être reportés partout
L'idée est hyper intéressante : On garde le concept de SPA, mais on rajoute des éléments de navigation entre SPA via une logique de lib.
J'aime bien ! Je valide à 100% l'idée ! C'est super génial !
!! Points d'attention !! :
- Bien réfléchir son usecase d'abord
- Attention au design (style - Css)