What is client-server architecture and when do we meet it?
How does the client-server architecture works ? This will guide you through the basis of the web communication and exchanges.
👋🏻 For a English version of this article 🇺🇸 : let’s check out at Medium 

Lors de la réalisation de solutions informatiques — par exemple une application pour téléphone — cette dernière doit généralement s'alimenter auprès d'une base de données afin d'afficher son contenu.


L'application est donc dite cliente, car cette dernière ne contient pas les sources d'informations permettant l'affichage, on parlera également parfois de « front-end», retenez ce terme.


En complément une autre application est chargée de lui fournir ces données ainsi que de procéder à leurs mises à jour : c'est le serveur dont le rôle est donc de servir les données demandées par l'application, plus généralement on parlera ici de « back-end », un terme que vous verrez aussi fréquemment.

Avant d'aller plus loin sachez que cette architecture n'est pas l'unique solution possible pour structurer sa pile technique et bien qu'elle présente de nombreux avantages il existe d'autres alternatives basées sur divers protocoles tels que le fameux paire à paire (« peer to peer ») avec les fameuses blockchains dont vous avez très certainement entendu parler.


Un peu de concret
Dans la réalité il n'y a pas qu'une seule application qui dialogue avec un seul serveur. Ces notions de client et de serveur deviennent en fin de compte des rôles, des étiquettes que chaque machine endossera afin de composer l'ensemble de la pile architecturale et répondre aux besoins du produit.

Une histoire de communication entre machines

D'accord, super ! Mais qu'est-ce que ça veut dire tout cela finalement ?


Un serveur répond à des requêtes en construisant des réponses, le format de ces réponses peut être divers : html, json, xml, … Ces échanges interviennent par le biais d'un protocole de communication (comprendre un langage de communication, vous et moi utilisons le protocole « Langue Française ») tel que le très connu http ou https qu'utilise votre navigateur web et que vous tapez dans la barre d'adresse à chaque visite de site web. Il en existe beaucoup d'autres comme par exemple ws (websocket) et mqtt.


Un serveur en fonction de la puissance de la machine sur laquelle il est hébergé peut répondre à plusieurs centaines voir milliers de requêtes à la seconde en fonction de la complexité induite par ces-dites requêtes. Par exemple l'infographie ci-dessous représente un serveur unique qui sert 3 terminaux en même temps, chacun envoyant des requêtes et recevant des réponses.

La communication entre les clients et le serveur


Pour résumer et vulgariser, les machines discutent entre-elles, comme le feraient des humains et ces dernières échanges des informations par l'intermédiaire du réseau. Le serveur est la « glue » entre ces machines, c'est lui qui les mets en relation et qui leur permet d'échanger des informations.
On parle alors de modèle centralisé, si le serveur tombe, alors tout le réseau tombe car ce dernier est le talon d'Achille de l'architecture. C'est l'effet qu'une personne mal intentionnée cherche à produire par exemple avec une attaque DDOS (Dénie de service distribué).

Comment les clients communiquent-ils entre-eux ? Quel sont les avantages du serveur et son rôle ?


Dans l'exemple suivant A et C sont des clients pilotés par des utilisateurs (cela peut être leurs ordinateurs ou leurs téléphones). B quant à lui est un serveur.

Le serveur joue le rôle des services postaux


Nous l'avons vu plus haut, techniquement les terminaux échanges des messages nommés requêtes et réponses par le biais d'un protocole de communication, dans l'architecture client-serveur ce dernier joue d'une part le rôle de « La Poste » qui fait transiter le courrier entre les terminaux (les interlocuteurs).


Imaginons que A souhaite communiquer avec C, dans le cas d'une architecture client-serveur généralement A devra passer par B pour communiquer avec C soit le schéma ci-dessous :


A <-> B <-> C


Le chemin est certes plus long qu'une communication directe de A à C mais cela représente plusieurs avantages que nous allons détailler par la suite.

  1. Imaginons que `A` écrive un article sur un blog, ce dernier envoi un message à `B` avec le contenu de l'article ainsi que les metadonnées (status de publication, auteur, …).
  2. C demande à B la liste des articles sur le blog, B lui renvoie l'article de `A` écrit un peu plus tôt et certainement quelques autres articles qu'il possédait déjà dans sa base.
  3. Après lecture C apprécie l'article de A, il souhaite lui écrire un commentaire pour témoigner de son engagement et lui poser une question. Cependant C ne peut communiquer directement avec A car ce dernier n'est pas forcément connecté à ce moment-là et que B doit assurer la cohérence du commentaire, il laisse donc un message public à B qui stocke le message dans sa base de données et pourra envoyer une notification à A.


Mais pourquoi diable toujours passer par le serveur ? Quels sont les avantages qui en découlent dans les échanges entre applications ?

Le serveur joue le rôle de police de contrôle et de tiers de confiance


Le serveur joue également rôle de la police qui vérifie l'intégrité de ce qui transite afin de ne pas mettre le système dans un état d'incohérence, par exemple un mauvais message accessible à un destinataire qui n'était pas le destinataire originel.
Dans notre architecture — entre-autres — les avantages d'avoir un serveur en guise d'intermédiaire (middleware) sont les suivants :

  • Le serveur joue essentiellement le rôle de Tiers de confiance, il reçoit des données qu'il enregistre ou servent à consulter d'autres données, il y applique des modifications si nécessaire et filtre qui peut y accéder. Il est également programmé par les développeurs pour veiller à l'intégrité de la base de données et garantir que ce qui transite n'est pas du code malicieux. Par exemple dans le cas d'une application comme Blablacar, le serveur est chargé de veiller au bon déroulement de la transaction entre les utilisateurs et le co-voitureur, il vérifie le solde du compte et crédite l'utilisateur quand la course s'est correctement déroulée.
  • Sur des applications modernes comme nous verrons sur ce blog, le serveur est théoriquement « agnostique » c'est-à-dire qu'il retourne des réponses dans un format adapté aux besoins du client, généralement du JSON afin que n'importe quel client puisse consommer la réponse afin d'alimenter son affichage.
  • Mais ce qu'il faut vraiment retenir, c'est que lorsque votre serveur écoute les requêtes sur le réseau, ces dernières ne proviendront pas forcément de l'application que vous avez développé. Pour imager, imaginez que pendant la guerre une escouade de soldats a pour habitude de recevoir des ordres d'un groupe d'officiers, et bien cela ne veut pas dire que tous les courriers postaux (les requêtes) contenant les ordres de mission seront bien écrit par les officiers en charge du commandement (même si l'émetteur le prétend), un ennemi (une application tierce) connaissant le protocole pourrait malicieusement essayer de glisser une fausse lettre pour semer le chaos (une requête outrepassant les droits autorisés) dans l'espoir que l'escouade soit dupe, fonce tête baissée et dérègle la stratégie globale de l'armée (dérèglement de l'intégrité des données, vol de données, suppression de données).

Différents clients


Les clients se catégorisent en deux grands types :

  • Des clients dits Lourds : Ce sont des clients qui embarquent une grosse partie de code dans l'application, permettant de ne récupérer que les parties dynamiques nécessaires à l'affichage du contenu (le texte, les images, bref les données). Par exemple une application pour téléphone est un client lourd.
  • Les avantages qui en découlent sont une meilleure optimisation de la bande passante, une plus grande rapidité du fait de la légèreté des données qui transitent.
  • Mais en conséquence certaines choses sont figées tant que l'on ne met pas à jour le client, le poids est également plus lourd en terme d'octets, ce qui dans le cas d'une page web impacte le référencement et les performances et sur une application mobile le poids de l'application.
  • Des clients dits Légers : ce sont des clients qui embarquent seulement de quoi interpréter l'affichage de l'application. Votre navigateur internet est (généralement) un client léger, à chaque requête l'intégralité du code source de la page demandée est rechargé, même si une partie seulement a changé. Bien que de nos jours les applications en JS permettent de transformer des sites web en clients lourds :)


L'architecture clients / serveurs en 2019 : est-ce d'actualité ?


Plus que jamais en 2019 l'architecture client-serveur est d'actualité, les données sont une des plus précieuses ressources disponibles dans ce monde, on le voit avec des sociétés comme Facebook qui font leur business dessus. Des lois telle que le RGPD visent à améliorer la sécurité de ces données, cela fait une des raisons pour laquelle l'architecture client-serveur est adaptée à ce genre de problématiques en plus de tous les autres avantages évoqués.



Cet article évoque de nombreux avantages et objectifs de cette architecture et se veut non-exhaustif sur le sujet, n'hésitez pas à dialoguer dans les commentaires à ce sujet.