Depuis un certain temps, les développeur·euse·s mettent en place au niveau des services back-end des micros-services, et ce pour sortir du paradigme d’applicatif monolithique. Et ce toujours dans le but de pouvoir faire évoluer leurs applicatifs de la manière la plus souple, la plus rapide et la plus robuste possible. Ce n’est pas la solution magique, mais ce concept permet d’aller plus loin et plus vite.

En analysant les évolutions technologiques des navigateurs, poussées par les chiffres impressionnant d’utilisation du web, ainsi qu’à la mise au point de nouveaux outils de développement pour le front-end, comme les framework JavaScript, tels que Angular, VueJS, ReactJS, EmberJS, SvelteJS et de leur écosystème, on constate aujourd’hui que ce concept d’application monolithique s'étend malheureusement vers les développements front-end.

De plus les évolutions incessantes de ces frameworks ne sont pas sans avoir un impact sur les choix futurs des architectes de solution ou responsables informatique pour leur stack de développement front-end.

La question que tout un chacun se pose lorsqu’un nouveau développement se lance est de savoir quelle brique technologique implémenter. Existera-t-elle encore dans 2 ans, vais-je encore trouver des développeur·euse·s pour maintenir ces outils, etc. ?

C’est là que les micros front-end deviennent une des clés de la solution. Pourquoi mettre en place une architecture applicative full Angular, EmberJS ou encore full ReactJS ?

C’est la certitude d’être coincé dans un avenir plus ou moins proche. Et de posséder à nouveau une dette technologique, avec le risque de devoir tout recommencer et/ou de ne pas pouvoir faire évoluer l’application !

Mais c’est quoi ces micros front-ends à la fin ?

Il est habituel dans une architecture applicative de séparer les domaines métier dans le développement back-end d’où l’implémentation des micros-services. Par contre en front-end, vous allez plus souvent retrouver une seule application qui va combiner les différents domaines applicatifs et ce à cause d'une idée reçue :  "Le front ne fait qu’afficher ce que le back-end va lui fournir en données".

Sur le fond c’est vrai, les spécialistes front-end sont cantonés à l'affichage de par leur domaine de compétences: UI-UX-CSS-JS-HTML. Mais dans les faits, au plus tôt les concepts du front-end seront intégrés au processus de développement, au plus juste sera la répartition des taches et des fonctionnalités entre le back et le front.

Si l’on prend une application de gestion de contacts comme exemple, on peut identifier 3 domaines distincts :

• la gestion de la sécurité applicative (Authentification/Autorisation)
• la gestion des contacts et de leurs informations
• le moteur de recherche des contacts

Ce sont 3 domaines du monolithe applicatif qui pourraient être dissociés aussi bien en back-end qu’en front-end. On pourrait donc en faire 3 équipes séparées qui géreraient leur propre domaine applicatif verticalement avec l’intégration de toute l’équipe dès le départ.

Et donc un micros front-end est tout ou partie applicative intégrée dans une URL gérant un de ces domaines applicatifs. Nous les retrouverons sous plusieurs formes : les applications complètes et les fragments applicatifs. C’est-à-dire des composants qui sont spécifiques au domaine applicatif.

Dans notre exemple, nous aurons une URL qui présente les contacts sous forme d’une liste et donc nous évoluons dans une page complète. Cependant, pour la fonctionnalité de recherche, l’équipe a mis en place un fragment intégrable dans cette même page. Ces 2 éléments peuvent être de technologies totalement différentes, mais sont visuellement intégrés dans une même interface utilisateur.

D’accord, mais comment on les intègre ces éléments/fragments ?

L’intégration des éléments peut se faire de plusieurs manières, du côté serveur ou du côté client. Dans le cadre de l’intégration client, on peut envisager des Iframes, de l’Ajax, les Unified Single-Page_App, ou des composants Web, mais en fonction des besoins de l’application nous combinerons probablement plusieurs techniques.

Notre fonctionnalité de login pourrait être un webcomponent et le moteur de recherche, une Iframe. Ou encore les 2 en webcomponent, c’est là où l’expérience de l’intégrateur·trice sera primordiale.

De mon expérience, la notion d’intégration rapprochée (c’est-à-dire définir si et quand l’utilisateur doit passer d’un micros front-end à un autre) sera prépondérante dans les choix d’intégration (App Shell, Macro SPA).

Quels en sont les avantages ?

Les micros front-end permettent de séparer les possibilités front-end et ce aussi bien technologiquement qu’au niveau des domaines applicatifs (conf fig 1).

Un avantage que j’ai pu mettre en lumière personnellement est la possibilité, au sein d’une même application, d’avoir des versions d’outils différentes (ex. : Ember 2.16 et Ember 3.15). Ce qui nous amène une meilleure évolutivité des outils dans le temps, et ceci grâce aux fragments.

Je terminerais les avantages par l’aspect architecture applicative, les spécialistes front-end pourront dès le départ comprendre les logiques business et mettre en place des solutions adaptées, entendez frameworks adaptés aussi, tous ne sont pas équipés de la même manière.

Oui, c’est bien, mais il y a sûrement des inconvénients !

Les micros front-ends sont adaptés pour des projets de moyennes et grandes envergures, pour les plus petits projets ils seraient un frein au développement rapide au vu de la complexité de mise en œuvre et d’organisation induite.

Cette méthodologie n’est pas utile en dehors des applications Web. Par nature, les applications mobiles et desktops sont et resteront monolithiques.

En conclusion

Cela fait plus ou moins 3 ans que j’opère ces changements chez TRIPTYK, mais également chez nos client·e·s, et le moins que je puisse dire c’est que cela a permis une évolutivité rapide, efficace et proportionnelle aux besoins du marché au quotidien.

De plus je pense que cette approche a permis de distiller les évolutions rapides des frameworks front-end en d’en réduire de ce fait les risques liés au choix initial.

Si vous désirez en savoir plus sur les micros front-ends, n’hésitez pas à nous contacter par téléphone +32 65 98 09 60 ou via notre site web.