L’essentiel d’un environnement backend consiste à fournir des données aux utilisateurs de manière fiable. Pour cela, trois éléments clés sont indispensables : le serveur web, le WAS et la base de données. Ces trois composants ont évolué pour résoudre les problèmes apparus au fil du développement du web. Les technologies avancées comme le monitoring, le load balancing, le caching, les pipelines CI/CD ou Kubernetes reviennent à construire une maison prête à s’effondrer à tout moment si la compréhension de ces trois éléments n’est pas acquise au préalable.
Premièrement, le rôle du serveur web
Le rôle principal du serveur web était celui d’un serveur de fichiers chargé de distribuer des fichiers. Parmi les serveurs web représentatifs, on trouve Nginx, Apache, IIS et Caddy. Ces serveurs web excellent dans leur fonction de base, qui est de fournir des fichiers statiques, et sont hautement optimisés.
Deuxièmement, l’apparition et le rôle du WAS (Web Application Server)
Le WAS fonctionne en recevant certaines requêtes, en exécutant un programme prédéfini, puis en renvoyant à l’utilisateur le résultat produit par ce programme. On peut considérer cette approche comme la véritable naissance du backend : le moment où le serveur a cessé de se contenter d’afficher des fichiers pour commencer à réfléchir, calculer et traiter de la logique. Le serveur web renvoie toujours la même page statique, tandis que le WAS renvoie des pages dynamiques.
Troisièmement, la nécessité et le rôle de la base de données
La base de données a pour rôle de stocker les données de manière persistante, de les gérer de façon sécurisée et de contrôler les accès concurrents.
Parmi les autres notions très utiles à connaître pour concevoir le backend, on peut citer la conception d’API RESTful (conception d’URL centrée sur les ressources, signification de HTTP (GET, POST, PUT, DELETE, etc.), utilisation des codes d’état et principes de conception d’API fondés sur le style architectural REST), ainsi que l’authentification (compréhension de base des méthodes d’authentification et d’autorisation, comme l’authentification basée sur les sessions, et définition de politiques de gestion des utilisateurs) et la gestion des erreurs (concept de traitement des cas d’exception indispensables pour garantir la stabilité du système).
8 commentaires
Ceux qui croient que le back-end n’utilise que les protocoles web au monde
On dit qu’il s’agit des trois éléments clés du back-end, mais voir apparaître un serveur web me laisse perplexe.
Des éléments comme l’ALB ou le CDN remplissent déjà tous les rôles qu’on attendrait d’un serveur web, donc je ne vois pas vraiment pourquoi il faudrait absolument s’y accrocher. Est-ce que, de votre côté, vous avez déjà eu des cas concrets où la présence d’un serveur web a permis de bloquer un problème de sécurité ou autre ?
Si, sur le plan fonctionnel, l’ALB remplace le serveur web et que les utilisateurs ne peuvent pas accéder directement au backend, comme le WAS, on peut considérer que cela répond aux exigences de la configuration de sécurité existante. Et puis, beaucoup de services fonctionnent encore dans un environnement on-premise.
Du point de vue de la sécurité, je pense qu’il reste nécessaire de séparer le serveur Web et le serveur WAS. Le fait d’être dans un environnement cloud native n’y change rien. Les backends comme le WAS ne doivent pas se trouver sur une couche à laquelle les utilisateurs peuvent se connecter directement.
Est-il toujours pertinent de connaître les concepts de serveur web / WAS ?
À l’époque où Java EE, php et CGI étaient à la mode, c’était une distinction pertinente, mais aujourd’hui la plupart des langages embarquent leur propre serveur HTTP, et avec l’apparition puis la généralisation de concepts comme ALB, API Gateway, CDN ou Object Storage, l’époque a changé.
Au contraire, sans ce contexte historique, les notions de Web Server et de WAS, très différentes de la réalité actuelle, ne me semblent plus vraiment adaptées, et j’ai l’impression qu’elles risquent surtout de semer encore plus la confusion chez les débutants.
Dans la fintech, à cause des exigences de sécurité, il existe encore souvent des environnements où le Web et le WAS sont séparés. Comme on ne sait jamais dans quel environnement on va tomber, je pense qu’il vaut mieux se préparer à tout, haha.
Même dans l’environnement cloud actuel, on l’utilise pour traiter de gros volumes de données
afin d’équilibrer efficacement plusieurs WAS au sein d’une même instance.
S’il y a peu de requêtes réseau, cela n’est peut-être pas nécessaire.
Je suis d’accord. Il serait sans doute plus utile d’enseigner les principes du 12-factor app et les patterns cloud native. Le concept lui-même est trop ancien.