Micro Frontends Hypermedia avec HTMX

MyFakeSocial

MyFakeSocial

MyFakeSocial

MyFakeSocial

Feed	Profil	Chat
Fort besoin data Complexité front (tracking)	Application web assez classique Beaucoup de features	Système distribué Besoin de résilience

Feed

Profil

Chat

Fort besoin data

Complexité front (tracking)

Application web assez classique

Beaucoup de features

Système distribué

Besoin de résilience

Benoit Averty

linkedin.com/in/BenoitAverty

benoitaverty.com

Pour quelles raisons ?

Un produit, plusieurs équipes
Un produit, plusieurs technologies

Les micro frontends en 2025

Un shell avec un framework front
Des web-components
Des import-maps ou module-federation
Du tooling pour le développement

Et si on repartait de zéro ?

⚠️

Cahier des charges

Déployer indépendamment
Développer indépendamment
Découpage plus fin que page par page
Communication entre micro-frontends
Multi-techno
Server-Side Rendering

La base : un reverse-proxy, plusieurs apps

La base : un reverse-proxy, plusieurs apps

Routage

Pré-configuré	Service-discovery
Simple	Complexe
Un peu de couplage	Indépendance
Routage flexible	Conventions

Pré-configuré

Service-discovery

Simple

Complexe

Un peu de couplage

Indépendance

Routage flexible

Conventions

Impact sur le développement

Certains challenges apparaissent déjà

Bibliothèque graphique (qui marche dans toutes vos technos)
Granularité et frontières

Simple, efficace, mais limité

✅ Marche avec toutes les stacks
✅ Complexité faible
❌ Limité à 1 Micro Frontend par page
Naviguer d’un MFE à l’autre implique un rechargement complet de la page

Résoudre ces limitations

Résoudre ces limitations

Pourquoi moins de JS ?

(dans le navigateur)

Pour la planète (Data, obsolescence des terminaux)
Pour l’UX (stabilité, rapidité en toutes circonstances)
Pour l’inclusivité (accessibilité, progressive enhancement)
Pour le développeur (Maintenance dans le temps)

https://infrequently.org/2024/08/the-landscape/

https://medium.com/@jason.godesky/when-javascript-fails-52eef47e90db

(Applications hypermedia)

(HTMX)

<script type="text/javascript" src="htmx.min.js" />

(HTMX)

HTML Extended : On conserve l’approche orientée documents

Déclencher des requêtes plus librement
Utiliser une partie seulement de la réponse
Insérer la réponse sans remplacer la page actuelle intégralement

(HTMX)

<form
    hx-trigger="submit"
    hx-post="/connections"
    hx-include="find input"
    hx-target="#result"
    hx-swap="beforeend"
>
    <input type="text" name="url" />
    <input type="text" name="password" />
</form>
<table id="result">
</table>

Charger un Micro Frontend au sein d’une page

<!doctype html>
<html>
<body>
<!-- ... -->
<div
    hx-get="/chat"
    hx-trigger="load"
    hx-swap="outerhtml"
></div>
<!-- ... -->
</body>
</html>

Charger un Micro Frontend au sein d’une page

Réponse du Micro Frontend

<!doctype html>
<html>
<head>
    <script src="..." />
    <link rel="stylesheet" href="..." />
</head>
<body>
    <div id="chat-mfe">
        <!-- ... -->
    </div>
</body>
</html>

Communication entre MFE

Toutes les techniques de base qui marchaient déjà (Local Storage, Cookies, URL)
Des évènements (pour le mode push et le découplage)

myElement.dispatchEvent(new CustomEvent('business:connectedToUser', {
    bubbles: true,
    detail: user.id
}))

<div class="contacts-list"
    hx-trigger="business:connectedToUser from:body"
    hx-get="/chat/new"
    hx-vals='js:{"userId": event.detail}'
>

Démo

Toujours aussi simple, beaucoup moins limité

Aucune stack, seulement des apps
Seulement une dépendance + plugins (moins de 20ko)
Inclusion en cascade

Attention aux contraintes

Aucun outil technologique n’empêche de faire n’importe quoi
Pas de déduplication des dépendances
Gestion de l’url

On peut ajouter tous ces outils, au bon moment.

En attendant : documentation et conventions.

Contrats d’interface

Microservices ou micro frontends, il faut des interfaces

À quoi il est destiné
Un endpoint (Comme si c’était un Microservice back)
Des events pour communiquer avec

Le reste est géré en interne par le MFE lui-même

Server-Side Rendering

Comme des Microservices

Appeler le endpoint du MFE qu’on veut insérer
Insérer le body au bon endroit
Ajouter les scripts / css dans le head
Gérer la résilience : circuit breaker, fallback…

Démo

Et le développement ?

Un Micro Frontend = une application web

Développé comme une appli web

Pas de build en webcomponent
Pas de stack techno
Pas de compilation comme bibliothèque

Démo

En dev

Pour remplacer le reverse-proxy :

Changer l’url des MFE qu’on inclut
OU utiliser un serveur de dev
OU lancer le reverse-proxy en local

Difficile en cas de SSR sans outillage personnalisé

Aller plus loin

Inclure HTMX et gérer le document dans le reverse-proxy
Utiliser une import map pour les dépendances
Utiliser du shadow DOM à la main

Import map

<script type="importmap">
{
    "imports": {
        "htmx": "http://htmx.org/htmx.esm.js"
    }
}
</script>

<script type="module">
    window.htmx = (await import("htmx")).default
</script>

Enseignements clés

Un peu limité, BEAUCOUP moins complexe

Un autre paradigme

Quel sens en isolation ?

Scalabilité d’une application hypermedia

SPA : Ultra-Complexe tout de suite, je gère tous les cas (fictifs)

Hypermedia : Je démarre simple, je peux aller très loin

Merci

benoitaverty.com/confs

Feedback