Frontend
La couche où vivent l'interface utilisateur, l'interaction avec le client et la première prise de contact avec le système.
Qu’est-ce que cette couche ?
Le frontend est le point de contact direct avec l’utilisateur. C’est ici que l’on construit :
- les écrans
- les composants visuels
- les formulaires
- la navigation
- la gestion de l’état
- le retour visuel
- l’intégration avec les APIs
Son objectif n’est pas de contenir la logique métier centrale, mais d’offrir une expérience claire et utilisable au-dessus des fonctionnalités du système.
Responsabilités principales
Afficher l’interface
Présenter l’information et permettre à l’utilisateur d’interagir avec le système.
Gérer l’état de l’UI
Gérer les filtres, les formulaires, les sélections, le chargement, les erreurs et les autres états de l’expérience.
Validation basique côté client
Aider l’utilisateur avec des validations précoces, sans remplacer les véritables validations du backend.
Consommer les APIs
Envoyer des requêtes au système via l’API Gateway ou le BFF.
Gérer l’expérience
Messages, indicateurs de chargement, notifications, étapes de processus et retour visuel en cas d’erreurs.
Ce que le frontend ne devrait pas faire
Il ne devrait pas contenir de règles métier critiques
Il peut aider avec des validations liées à l’expérience, mais la vérité métier doit rester dans le backend.
Il ne devrait pas connaître trop de détails internes
Si le frontend a besoin de connaître tous les microservices, l’architecture devient fragile et difficile à maintenir.
Il ne devrait pas orchestrer des processus complexes
Pour cela, il existe des couches comme le BFF ou les services de domaine.
Relation avec les autres couches
Le frontend ne devrait normalement pas dialoguer directement avec tous les microservices. Sa relation idéale est :
- frontend → API Gateway
- gateway → BFF
- BFF → microservices
Cela permet de maintenir une expérience plus stable, même si l’architecture change en interne.
État local et état global
Dans les applications modernes, le frontend gère généralement deux types d’état.
État local
Il appartient à un composant ou à une vue spécifique. Par exemple :
- si une modale est ouverte
- la valeur actuelle d’un champ de saisie
- un interrupteur visuel
État global
Il est partagé entre plusieurs parties de l’application. Par exemple :
- l’utilisateur authentifié
- le thème visuel
- le panier
- les filtres persistants
- les données de session
Comprendre cette différence aide à ne pas surdimensionner la gestion de l’état.
Pourquoi ne pas mettre trop de logique ici ?
Parce que le frontend :
- change rapidement
- s’adapte aux besoins des écrans
- est plus exposé aux refontes d’UX
- ne doit pas devenir l’endroit où se décide la vérité du système
La logique métier importante doit rester protégée dans le backend ou les services de domaine.
Technologies courantes
Selon la stack, cette couche peut inclure :
- React, Vue ou Angular
- TypeScript
- de la gestion d’état comme Redux, Zustand ou Pinia
- des bibliothèques de formulaires
- des clients HTTP ou GraphQL
- des outils de build comme Vite
Exemple pratique
Imaginez l’écran d’un catalogue.
Le frontend :
- affiche les filtres
- présente les produits
- permet la pagination
- montre les états de chargement
- envoie la requête au backend
Mais il ne décide pas :
- si un produit est réellement valide
- si le stock peut être réservé
- si une commande peut être confirmée
Cela appartient au domaine.
Résumé
Le frontend est responsable de l’expérience utilisateur, de la présentation et de l’interaction. Il doit être une couche claire et efficace, mais pas l’endroit où se concentrent les règles métier principales.