051.2 Leçon 1

Lorsque vous utilisez des systèmes en ligne, il est très probable que vous ayez rencontré à un moment ou à un autre un message comme celui de l'Exemple d’écran affiché pendant qu’une réponse est en préparation.

Prenons un peu de recul et examinons le contexte dans lequel vous voyez ce message. Supposons que vous essayez d’accéder à votre compte bancaire par l’intermédiaire du site web de votre banque. Lorsque vous essayez d’accéder au site web de votre banque sur votre ordinateur portable, vous utilisez un type de logiciel (c’est-à-dire une application) appelé navigateur web, tel que Google Chrome ou Firefox. Dans ce cas, le navigateur de votre ordinateur envoie une demande à un autre ordinateur qui héberge le site web. Ce type d’ordinateur est appelé serveur. Il est spécialement conçu pour fonctionner 24 heures sur 24, 7 jours sur 7, et répondre en permanence aux nouvelles demandes provenant de toutes les régions du monde.

Un serveur est donc un ordinateur, comme celui que vous utilisez pour travailler, jouer à des jeux vidéo et faire des travaux de programmation. Il existe toutefois une différence majeure : Un serveur utilise normalement toutes ses ressources pour l’application logicielle qu’il exécute. Dans cet exemple, le logiciel est une application web, un programme informatique qui s’exécute sur le serveur.

Dans l'Exemple d’écran affiché pendant qu’une réponse est en préparation, le serveur a reçu une demande de la part d’un navigateur et l’application qui tourne sur le serveur traite l’opération qui en résulte. Cette opération peut consister à interroger une base de données pour obtenir les coordonnées d’un utilisateur dans la banque, ou à communiquer avec un autre serveur pour vérifier une réduction spéciale sur le prochain prêt de l’utilisateur.

Dans cet exemple, nous appelons le navigateur qui tourne sur votre machine l'application cliente, ou plus simplement, le client. Le client interagit avec le serveur distant.

La communication entre le client et le serveur peut avoir lieu au sein d’un réseau d’entreprise ou à travers le réseau mondial que nous appelons l’internet. Une caractéristique commune de l’interaction client-serveur est qu’un serveur peut établir des multiples relations avec plusieurs clients. Reprenons l’exemple précédent : le site web d’une banque hébergé sur un serveur peut recevoir des milliers de demandes par minute en provenance de plusieurs endroits, chacune d’entre elles émanant d’un utilisateur qui tente d’accéder à son compte bancaire personnel.

Tous les scénarios ne sont pas structurés comme un navigateur interagissant avec un serveur qui effectue la quasi-totalité du traitement. Dans certains cas, le client peut être l’instance principale de traitement ; ce concept est appelé client lourd, dans lequel le client stocke et traite la majorité des tâches au lieu de s’appuyer sur les ressources du serveur. Dans notre exemple bancaire, en revanche, le navigateur est un client léger qui s’appuie sur le serveur pour calculer et renvoyer des informations via le réseau.

Un exemple de client lourd est l’application de bureau d’un jeu vidéo, où l’essentiel du stockage et du traitement des données se fait localement, en utilisant le GPU, la RAM, le CPU et l’espace disque de l’ordinateur pour traiter les informations. Une telle application dépend rarement d’un serveur externe, surtout si le jeu est joué hors ligne.

Les deux approches présentent des avantages et des inconvénients : Pour un client lourd, l’instabilité du réseau est moins problématique que pour un client léger qui dépend d’un serveur distant, mais les mises à jour logicielles peuvent être plus difficiles à appliquer et le client lourd nécessite plus de ressources informatiques. Pour un client léger, les coûts inférieurs peuvent être un grand avantage. Quel que soit le type de client, la transmission de données personnelles à une application tierce peut poser des problèmes.

Une application web est un logiciel qui s’exécute sur un serveur, traite les interactions des utilisateurs et est contacté par des clients lourds ou légers via un réseau informatique. Tous les sites web ne sont pas considérés comme des applications web : Les simples pages web statiques sans interactivité ne sont pas considérées comme des applications web car le serveur n’exécute pas d’application pour traiter les actions demandées par le client.

De nombreuses applications web peuvent être divisées en deux groupes : les applications monopage (single page application ou SPA) et les applications multipages (multi-page application ou MPA). Une SPA ne comporte qu’une seule page web, où tous les échanges et chargements de données ont lieu sans qu’il soit nécessaire de rediriger l’utilisateur vers une autre page web à l’intérieur de l’application. Une MPA, contrairement à une SPA, comporte plusieurs pages web. Une modification des données peut soit rafraîchir la page web à l’origine de l’action, soit rediriger l’utilisateur vers une autre page web.

Reprenons l’exemple précédent, dans lequel un utilisateur souhaite consulter les dernières transactions de son compte sur le site web de la banque en ligne. Imaginons qu’une transaction se produise après le chargement de la page web. Si l’application web de la banque est une SPA, la nouvelle transaction sera affichée automatiquement sur la même page web, sans rediriger l’utilisateur vers une nouvelle page. Si l’utilisateur vérifie ses prêts, les nouvelles informations sont également affichées sur la même page, sans qu’il soit nécessaire de rediriger l’utilisateur vers une nouvelle page web. La modification de la page sans redirection de l’utilisateur rend la navigation fluide.

Dans le cas d’une MPA, lorsque l’utilisateur demande la page web du prêt, le serveur doit le rediriger vers un nouvel emplacement, c’est-à-dire une autre page web.

Google Mail (Gmail) est un exemple très connu d’application web SPA. L’application ne redirige pas l’utilisateur vers une page complètement nouvelle lorsque, par exemple, il souhaite afficher le dossier des messages indésirables (spam) ; elle se contente de rafraîchir la partie spécifique de l’affichage qui montre tous les messages indésirables, et reste sur la même page web.

D’autre part, une application MPA très connue est Amazon.com, le géant du commerce électronique, où chaque article se trouve sur une page web distincte.

L’un des avantages d’une MPA par rapport à une SPA est qu’il est beaucoup plus facile de recueillir et de mesurer les données analytiques. Ces données sont essentielles pour aider les développeurs à optimiser les résultats de recherche sur internet.

En général, une application web est divisée en deux parties distinctes : la frontale (frontend) et la dorsale (backend). La partie frontale est la couche de visualisation, où l’utilisateur interagit avec un navigateur en utilisant les éléments de la page en cliquant, en sélectionnant ou en tapant. C’est ici que les données du serveur sont reçues, mises en forme et affichées à l’utilisateur par l’intermédiaire du navigateur.

La partie dorsale est généralement la plus importante d’une application web. Elle comprend la logique commerciale, les gestionnaires de communication, la majorité du traitement et le stockage des données. Le stockage des données utilise un système de gestion de base de données distinct connecté à la partie dorsale.

La partie frontale et la partie dorsale communiquent entre elles. Les demandes de données sont transmises par la partie frontale à la partie dorsale, et les données renvoyées par la partie dorsale sont reçues, formatées et affichées par la partie frontale à destination de l’utilisateur.

Dans notre exemple simple de recherche de la dernière transaction sur le compte bancaire d’un utilisateur, l’action est interprétée par la partie frontale de l’application, qui s’exécute dans le navigateur sur le bureau de l’utilisateur. Cette demande est ensuite envoyée via l’internet à la partie dorsale de l’application, qui vérifie si l’utilisateur est autorisé à effectuer l’action, récupère les données et renvoie la liste des transactions à la partie frontale chargée dans le navigateur. Le navigateur met alors en forme et affiche les données à l’utilisateur.

Aucun logiciel n’est utile s’il ne communique pas avec des composants internes et externes. Comment le client peut-il communiquer avec l’application web ? Comment la partie frontale peut-elle envoyer des données à la partie dorsale ?

Les applications logicielles communiquent entre elles par l’intermédiaire d’une interface de programmation d’application (application programming interface ou API), fonctionnant sur des protocoles de communication Internet basiques. Les protocoles sont des normes et des règles élaborées pour garantir que deux ou plusieurs applications échangent des commandes et des données.

Le principal avantage d’une API est de dissocier les différentes parties de l’application tout en leur permettant de coopérer dans le traitement des données. Les API centralisent également le flux de données dans des canaux prédéfinis, agissant comme une passerelle qui garantit que tout le monde utilise la même voie pour aller et venir. Dans les applications web, les API sont essentielles au fonctionnement de l’application, car elles permettent l’interaction avec l’utilisateur, la fourniture d’informations traitées, les demandes de stockage de données et bien d’autres tâches. Une API peut être utilisée par le client pour demander des actions qui seront exécutées sur le serveur, par exemple.

Revenons à notre exemple d’application web bancaire. Pour se connecter à un compte via une application web, l’utilisateur saisit généralement des données telles que son nom d’utilisateur et son mot de passe dans certains champs de texte et clique sur un bouton “Connexion”. Le navigateur saisit ces informations et appelle une API dorsale. L’application web exécutée sur le serveur distant reçoit les données de l’utilisateur, valide l’utilisateur, vérifie le droit de l’utilisateur à obtenir l’accès, et enfin renvoie une réponse au navigateur. Pour que l’utilisateur puisse communiquer avec le serveur, le client et le serveur doivent obligatoirement envoyer des données dans les deux sens. C’est ce que permettent les API.

Notez que l’application web de la banque n’expose pas d’autres informations sensibles ; elle ne montre à l’utilisateur que les champs autorisés et nécessaires à l’interaction souhaitée. Le reste est caché à l’utilisateur.

La communication entre les API peut être basée sur des conceptions et des protocoles très différents. Le hypertext transfer protocol (HTTP) est de loin le protocole le plus fréquemment utilisé dans les applications web. L'hypertexte est un texte comportant des liens vers d’autres textes, concept qui constitue la base des liens dans les pages web HTML. Les hyperliens constituent donc la base de la construction des pages web et de leur affichage dans les navigateurs.

Le protocole HTTP a été conçu pour les applications client-serveur, dans lesquelles les ressources sont demandées à un serveur et renvoyées au client via le réseau en utilisant une structure prédéfinie spécifiée par le protocole HTTP.

Dans le cas d’une application web structurée, les ingénieurs logiciels conçoivent l’application avec des parties ou des modules distincts. Cette séparation des responsabilités permet de définir clairement les tâches et les responsabilités, ce qui accélère le développement et améliore la maintenance.

Prenons l’exemple d’une application comportant deux modules internes : l’un qui met en œuvre la logique commerciale et l’autre qui s’appuie sur l’intégration d’un tiers. Cette tierce partie est une entreprise externe qui fournit son API dans un but spécifique, par exemple pour les prévisions météorologiques. Si le serveur météorologique est en panne, il est impossible d’obtenir des détails météorologiques, et si ces données sont cruciales pour le résultat final du traitement, l’utilisateur peut éprouver quelques maux de tête temporaires s’il n’y a pas de source alternative pour les données.

Imaginons maintenant que ce fournisseur tiers soit remplacé et que le nouveau ait une façon différente de gérer la même API. La séparation des modules signifie que les développeurs d’un seul module doivent le mettre à jour. La logique commerciale de l’autre module n’a pas besoin d’être modifiée, ou du moins ne nécessite que des mises à jour minimales.

La nécessité de structures de processus claires influence également la conception des API afin de faciliter leur utilisation. Le concept de representational state transfer (REST) est un style architectural avec un ensemble de lignes directrices pour la conception et la mise en œuvre de l’accès aux données dans une application.

Il existe six principes REST. Par souci de simplicité, nous allons en expliquer trois qui sont les plus pertinents pour cette leçon :

Les API qui suivent les principes REST sont appelées RESTful, et dans le web moderne, la conception REST est suivie par de nombreuses applications web. Bien qu’une API RESTful ne doive pas nécessairement mettre en œuvre ces principes à l’aide du protocole HTTP, celui-ci est presque universellement utilisé dans le modèle REST en raison de sa robustesse, de sa simplicité et de son omniprésence dans l’environnement du web mondial.

Il existe des dizaines de styles et de normes architecturales qui tentent d’organiser les structures des applications web. Comme presque tout dans le monde de l’informatique, il n’y a pas de “gagnant”, seulement un ensemble d’avantages et d’inconvénients pour chaque modèle. Un paradigme important est l'architecture microservice, qui a été créée comme une alternative à l’ancienne architecture monolithique.

L’architecture microservice est un modèle logiciel composé de multiples services interdépendants qui forment ensemble l’application finale. Cette architecture vise à décentraliser le code base : Les multiples couches de logiciels sont divisées en plusieurs applications plus petites pour une meilleure maintenance (Architecture microservice).

En revanche, une architecture monolithique contient tous les services et ressources de l’application dans une seule application (Architecture monolithique).

Les images montrent que le modèle microservice est décentralisé et que l’application repose sur plusieurs services, chacun ayant sa propre base de données, son propre code base et même ses propres ressources de serveur. Comme son nom l’indique, chaque microservice doit être plus petit que son homologue monolithique, qui prend la responsabilité de tous les services.

L’application monolithique encapsule toutes ses ressources dans une seule unité. Toute la logique commerciale, les données et le code base sont centralisés dans un énorme bloc, c’est pourquoi on l’appelle un “monolithe”.

Les utilisateurs remarquent à peine si une application web fonctionne selon un modèle monolithique ou microservice ; le choix devrait être transparent. Notre application bancaire, par exemple, pourrait être un monolithe dans lequel toute la logique commerciale concernant les paiements, les transactions, les prêts, etc. se trouve dans le même code base qui s’exécute sur un ou plusieurs serveurs. En revanche, si l’application bancaire utilise un style de microservice, elle dispose probablement d’un microservice dédié au traitement des paiements et d’un autre microservice réservé à l’octroi de prêts. Ce dernier microservice appelle encore un autre microservice pour analyser la probabilité que le demandeur n’effectue pas le paiement. L’application pourrait comporter des milliers de petits services.

L’approche monolithique nécessite davantage de frais généraux de maintenance lorsque l’application prend de l’ampleur, en particulier lorsque plusieurs équipes codent dans le même code base. Compte tenu de la centralisation des ressources logicielles, il est très probable qu’une équipe modifie quelque chose qui casse la partie de l’application appartenant à une autre équipe. Cela peut constituer un véritable casse-tête pour les grandes équipes, particulièrement lorsqu’elles sont très nombreuses.

Les microservices sont beaucoup plus flexibles à cet égard, car chaque service est géré par une seule équipe. Une équipe peut, bien entendu, gérer plus d’un service. Les changements de code sont faciles à effectuer et la concurrence entre les ressources n’est pas un réel problème. Comme chaque service est interconnecté, tout point de défaillance peut avoir un impact négatif sur l’ensemble de l’application. En outre, étant donné que de multiples instances de bases de données, serveurs et API externes communiquent entre eux, la résilience de l’ensemble de l’application n’est que le reflet de son microservice le plus faible.

L’un des avantages de l’approche monolithique est de disposer d’une source de données centralisée, ce qui permet d’éviter plus facilement la duplication des données. Cette approche permet également de réduire la consommation des ressources cloud, car un grand serveur nécessite moins de ressources informatiques que plusieurs serveurs décentralisés. Une application de microservices de taille à peu près équivalente fait peser une charge plus importante sur le cloud.