Le monde s’est déplacé vers l’Internet, et les applications web sont devenues les nouveaux lieux de travail et magasins commerciaux. Pour répondre à la diversité des objectifs des applications web modernes, chacune d’entre elles doit être conçue pour offrir de hautes performances et une grande capacité de personnalisation.
Les architectures d’applications web résolvent ce problème.
L’architecture d’une application web définit la manière dont les différents composants d’une application web sont structurés. Cette architecture est très spécifique à la nature et à l’objectif de l’application web. Choisir la mauvaise architecture pour votre application web peut avoir des conséquences désastreuses sur votre entreprise.
Dans ce guide, nous allons décomposer le concept d’architecture d’application web et comprendre comment il affecte l’expérience de l’utilisateur final de votre application. Vers la fin, nous examinerons également certaines des meilleures pratiques que vous pouvez mettre en œuvre pour tirer le meilleur parti de votre application web.
Qu’est-ce que l’architecture d’application web ?
Pour lancer la discussion, commençons par la définition de l’architecture d’application web.
En termes simples, l’architecture d’application web est un aperçu de la manière dont les différents composants de votre application web interagissent les uns avec les autres.
Cela peut être aussi simple que de définir la relation entre le client et le serveur. Elle peut également être aussi complexe que la définition des interrelations entre un essaim de serveurs backend conteneurisés, des équilibreurs de charge, des passerelles API et des interfaces publiques à page unique orientées vers l’utilisateur.
Cela dit, il s’agit rarement de choisir le langage de programmation dans lequel vous allez écrire votre code.
La façon dont vous concevez votre application web joue un rôle clé à la fois dans sa convivialité et dans l’optimisation de vos couts. Voici à quoi ressemble un exemple d’architecture d’application web sur le papier :
Pourquoi l’architecture d’application web est-elle importante ?
L’architecture d’application web est, sans aucun doute, l’une des parties les plus importantes de votre application web. Si vous choisissez de développer votre application web en tenant compte d’une architecture spécifique, vous êtes certain de bénéficier de nombreux avantages lorsqu’il s’agit de maintenir et de développer votre application.
Toutefois, le choix de la bonne architecture amplifie encore ces avantages.
Voici quelques-unes des principales raisons pour lesquelles vous devriez sérieusement envisager d’adopter une architecture d’application web.
Adaptation aisée aux besoins de l’entreprise
Votre application est une porte d’entrée clé pour votre entreprise, et les besoins de l’entreprise évoluent avec les changements du marché. Pour suivre le rythme, vous voudrez que votre application soit suffisamment flexible pour s’adapter aux besoins changeants de votre entreprise. Si vous construisez une application sans tenir compte de la flexibilité intégrée, vous passerez certainement de plus en plus de temps et d’efforts à faire de petits ajustements à votre application au fil du temps.
La bonne architecture d’application web tient déjà compte de certains des changements dont votre entreprise pourrait avoir besoin à l’avenir. Par exemple, si vous savez que vous construisez une application de commerce électronique qui évoluera et offrira un jour une large gamme de services à un grand nombre de clients, choisir une architecture de micro-services plutôt qu’une architecture monolithique vous apportera plus de flexibilité.
D’autre part, si vous créez une application interne pour votre entreprise avec seulement une ou deux exigences fixes, vous pouvez opter pour un monolithe plus simple pour accélérer le développement et garder votre base de code propre.
Développement organisé
Comme nous l’avons mentionné précédemment, la bonne architecture d’application web vous fournit une feuille de route plus pratique pour le développement. L’architecture fournit suffisamment de modularité dans votre système pour isoler les composants si nécessaire, et vous avez la liberté de choisir la bonne structure de projet pour chacun de vos modules et composants si nécessaire.
Si vous vous plongez dans le développement d’applications sans avoir une architecture en tête, vous risquez de perdre du temps et de l’argent à réorganiser vos composants et à établir de nouvelles règles pour faciliter la collaboration entre les membres de votre équipe – du temps et de l’argent qui auraient pu être dépensés ailleurs.
Meilleure gestion de la base de code
Outre l’écriture du code de votre application, vous passerez également un temps considérable à le gérer. L’organisation des fichiers de votre projet, la décomposition de votre application en modules et la mise en place de pipelines personnalisés ne sont que quelques-unes des tâches qui nécessitent une maintenance active pour assurer un développement harmonieux.
La bonne architecture d’application web vous permet d’apporter facilement des modifications. Vous pouvez mettre en œuvre les meilleures pratiques propres à chaque composant, séparer les points sensibles de votre application les uns des autres et faire en sorte que chaque fonctionnalité soit indépendante et faiblement couplée. Ce n’est pas que ces choses ne peuvent pas être faites sans architecture ; c’est juste que la bonne architecture rend tout cela beaucoup plus simple.
Le fait de suivre une architecture prédéfinie vous permet également de développer vos applications plus rapidement. La bonne architecture combinée à une bonne stratégie de contrôle des versions peut permettre à vos développeurs de travailler en parallèle les uns avec les autres et de construire des fonctionnalités plus rapidement.
Une architecture d’application web permet également d’assurer l’avenir de votre application. Une fois que vous avez défini une stratégie solide sur la façon d’organiser les composants de votre application, vous pouvez facilement migrer ces composants vers des technologies plus récentes, un par un, sans avoir à refaire toute votre application.
Sécurité renforcée
La plupart des architectures d’applications web tiennent compte de la sécurité lors de la structuration des composants. Les développeurs peuvent planifier, à l’avance, les mesures et les pratiques à mettre en œuvre pour améliorer la sécurité de l’application avant qu’elle ne soit déployée auprès des utilisateurs.
Par exemple, il est plus logique de créer une application de streaming vidéo qui offre du contenu gratuit et payant en utilisant des micro-services, car l’architecture de micro-services vous permet de diviser votre application en composants adaptés aux besoins de l’entreprise, tels que l’authentification de l’utilisateur et le streaming de contenu gratuit ou payant. Si votre module d’authentification de l’utilisateur tombe en panne, vous pouvez facilement configurer votre application pour restreindre l’accès au contenu payant jusqu’à ce que l’authentification soit rétablie, tandis que le module de contenu gratuit reste disponible pour vos utilisateurs.
Dans un autre cas, où cette même application a été conçue comme un monolithe étroitement couplé, un service d’authentification hors service signifierait soit une application hors service, soit un contenu payant mis à disposition gratuitement – des résultats que vous voudrez éviter à tout prix.
Comment fonctionne l’architecture d’application web ?
Avant de parler du fonctionnement de l’architecture des applications web, il est important de comprendre comment fonctionne un simple site web :
- L’utilisateur saisit l’URL de votre application dans la barre d’adresse du navigateur ou clique sur un lien.
- Le navigateur recherche l’URL dans les serveurs DNS et identifie l’adresse IP de votre application.
- Le navigateur envoie une requête HTTP à votre application.
- Votre application répond avec le contenu correct (généralement une page web).
- Le navigateur rend la page web sur l’écran.
Si vous deviez plonger un peu plus profondément, voici comment une application web traiterait une requête :
- L’utilisateur envoie une requête à votre application via votre interface utilisateur frontend.
- Si vous avez configuré un cache approprié, l’application le vérifiera d’abord pour voir s’il contient un enregistrement valide qui peut être renvoyé directement au client. Si c’est le cas, le contenu du cache sera renvoyé, et la requête sera marquée comme terminée.
- S’il n’y a pas de cache, la requête est transmise à l’équilibreur de charge.
- L’équilibreur de charge identifie une instance de serveur qui est disponible pour traiter la requête et la transmet.
- L’instance de serveur traite la requête et appelle les API externes si nécessaire.
- Une fois les résultats rassemblés en un seul endroit, le serveur renvoie la réponse à l’équilibreur de charge.
- L’équilibreur de charge renvoie la réponse à la passerelle API, qui l’envoie à son tour à l’utilisateur dans le client frontend. La requête est alors marquée comme terminée.
Types d’architecture d’application web
Maintenant que vous avez une idée de base de ce qu’est l’architecture d’application web, examinons en détail certains des types d’architecture d’application web les plus populaires utilisés.
Architecture à page unique
L’architecture d’une application à page unique (Single-Page Application ou SPA) est aussi simple que son nom : l’application entière est basée sur une seule page. Une fois que l’utilisateur a lancé votre application, il n’a pas besoin de naviguer vers d’autres pages web. L’application est rendue suffisamment dynamique pour récupérer et rendre les écrans qui répondent aux exigences des utilisateurs au fur et à mesure qu’ils naviguent dans l’application elle-même.
Les SPA sont excellents lorsqu’il s’agit d’offrir une expérience rapide et transparente aux utilisateurs finaux ou aux consommateurs. Cependant, ils n’ont pas la touche d’un site web traditionnel, et ils peuvent être difficiles à optimiser pour le SEO.
Les avantages de l’architecture SPA
Voici quelques-uns des avantages de l’architecture SPA :
- Vous pouvez créer des applications web hautement interactives.
- Les SPA sont faciles à mettre à l’échelle.
- L’optimisation des SPA pour les performances ne demande pas beaucoup d’efforts.
Inconvénients de l’architecture SPA
Voici quelques-uns des inconvénients de l’architecture SPA :
- Les SPA limitent la flexibilité avec les hyperliens et le SEO.
- Le rendu initial est généralement lent.
- La navigation dans l’application peut être peu intuitive.
Architecture d’application web progressive
L’architecture d’application wep progressive (Progressive Web Application ou PWA) s’appuie sur l’architecture à page unique en fournissant des capacités hors ligne pour votre application web. Des technologies telles que Capacitor et Ionic sont utilisées pour construire des PWA qui peuvent offrir aux utilisateurs une expérience uniforme sur toutes les plates-formes.
Comme les SPA, les PWA sont fluides et transparentes. Avec la possibilité supplémentaire d’être installées sur les appareils des utilisateurs (via les workers de service), vos utilisateurs bénéficient d’une expérience plus uniforme avec votre application.
En même temps, il peut être difficile d’optimiser ces applications pour le référencement, et les mises à jour des applications installées peuvent être difficiles à pousser.
Les avantages de l’architecture PWA
L’architecture PWA présente de nombreux avantages, notamment :
- Les applications fonctionnent très bien et offrent une compatibilité multiplateforme.
- L’évolutivité est simple.
- Les développeurs ont accès à l’accès hors ligne et aux API natives des appareils, comme les travailleurs en arrière-plan et les notifications push.
Inconvénients de l’architecture PWA
Parmi les inconvénients de l’architecture PWA, on peut citer :
- La prise en charge de la gestion des liens et du référencement est limitée.
- L’envoi de mises à jour aux PWA hors ligne est plus complexe qu’avec les applications natives.
- La prise en charge des PWA par les navigateurs web et les systèmes d’exploitation est limitée.
Architecture à rendu côté serveur
Dans le rendu côté serveur (Server-Side Rendering ou SSR), les pages web frontend sont rendues sur un serveur backend après avoir été demandées par l’utilisateur. Cela permet de réduire la charge sur le périphérique client car il reçoit une page web statique en HTML, CSS et JS.
Les applications SSR sont très populaires parmi les blogs et les sites de commerce électronique. Cela est dû au fait qu’elles rendent la gestion des liens et le référencement assez simples. De plus, le premier rendu des applications SSR est assez rapide puisque le client n’a pas à traiter de code JS pour rendre les écrans.
Avantages de l’architecture SSR
Certains des avantages de l’architecture SSR sont énumérés ci-dessous :
- Ces applications sont idéales pour les sites web à fort SEO.
- Le chargement de la première page est presque instantané dans la plupart des cas.
- Vous pouvez l’associer à un service de mise en cache pour améliorer encore les performances de votre application.
Inconvénients de l’architecture SSR
Voici quelques inconvénients de l’utilisation de l’architecture SSR :
- Elle n’est pas recommandée pour les pages web complexes ou lourdes, car le serveur peut prendre du temps pour générer entièrement la page, ce qui entraine un retard dans le premier rendu.
- Il est surtout recommandé pour les applications qui ne se concentrent pas beaucoup sur l’interface utilisateur et qui recherchent uniquement une évolutivité ou une sécurité accrue.
Architecture d’applications pré-rendues
L’architecture d’applications pré-rendues est également connue sous le nom d’architecture de génération de sites statiques. Dans cette architecture, les pages web frontend de l’application sont pré-générées et stockées sous forme de fichiers HTML, CSS et JS simples sur le serveur. Lorsqu’un utilisateur demande une page, celle-ci est directement récupérée et lui est présentée. Cela rend l’application web très rapide, avec des temps de chargement minimaux de tout type. Cependant, cette architecture augmente le temps de construction de l’application puisque les pages web sont rendues pendant le processus de construction.
Les applications web pré-rendues sont parfaites lorsque vous cherchez à générer du contenu statique tel que des blogs ou des détails sur des produits qui ne changent pas souvent. Vous pouvez également utiliser des modèles pour simplifier la conception de vos pages web. Cependant, il est presque impossible de construire des applications web dynamiques avec cette architecture. Si vous cherchez à construire une page de recherche qui prend la requête dans son chemin (quelque chose comme https://myapp.com/search/foo+bar), vous êtes au mauvais endroit.
Étant donné que chaque itinéraire possible de l’application est rendu au préalable pendant le processus de construction, il est impossible d’avoir des itinéraires dynamiques comme ci-dessus puisqu’il existe une infinité de possibilités qui ne peuvent pas être rendues au préalable pendant la construction (et cela n’a pas de sens de le faire non plus).
Avantages de l’architecture pré-rendue
Voici quelques-uns des principaux avantages de l’architecture d’application pré-rendue :
- Les pages web sont générées en HTML, CSS et JS purs ; leurs performances sont donc similaires à celles des applications construites à l’aide de vanilla JS.
- Si vous connaissez toutes les voies possibles de votre application, le référencement devient super facile.
Inconvénients de l’architecture pré-rendue
Comme tout modèle architectural, l’architecture pré-rendue a son lot d’inconvénients :
- Le contenu dynamique ne peut pas être servi avec ces applications.
- Toute modification de l’application web implique de reconstruire et de déployer l’application à partir de zéro.
Architecture d’application isomorphe
Les applications isomorphes sont celles qui sont un mélange d’applications à rendu côté serveur et de SPA. Cela signifie que ces applications sont d’abord rendues sur le serveur comme une application normale rendue côté serveur. Une fois qu’elles sont reçues par le client, l’application s’hydrate et attache le DOM virtuel pour un traitement client plus rapide et plus efficace. Cela transforme essentiellement l’application en une application à page unique.
L’architecture d’application isomorphe réunit le meilleur des deux mondes. Vous obtenez un traitement et une interface utilisateur super rapides sur le client, grâce au SPA. Vous bénéficiez également d’un rendu initial rapide et d’une prise en charge complète du SEO et des liens, grâce au rendu côté serveur.
Les avantages de l’architecture isomorphe
Voici quelques-uns des avantages de l’utilisation de l’architecture d’application isomorphe :
- Les architectures d’applications isomorphies ont un rendu initial super rapide et une prise en charge complète du référencement.
- Ces applications sont également performantes sur le client puisqu’elles se transforment en SPA après le chargement.
Inconvénients de l’architecture isomorphe
Voici quelques-uns des inconvénients de l’architecture d’application isomorphe :
- La mise en place d’une telle application nécessite des talents qualifiés.
- Les options de la pile technologique sont limitées lorsqu’il s’agit de concevoir une application isomorphe. Vous n’avez le choix qu’entre une poignée de bibliothèques et de frameworks (principalement) basés sur JS.
Architecture orientée services
L’architecture orientée services (Service-Oriented Architecture ou SOA) est l’une des alternatives les plus populaires à la manière traditionnelle monolithique de construire des applications. Dans cette architecture, les applications web sont décomposées en services qui représentent chacun une unité fonctionnelle de l’entreprise. Ces services sont faiblement couplés entre eux et interagissent les uns avec les autres par le biais du passage de messages.
L’architecture orientée services ajoute de la stabilité et de l’évolutivité à la pile technologique de votre application. Toutefois, la taille des services dans l’architecture orientée services n’est pas clairement définie et est généralement liée à des composants métier, et non à des composants techniques ; par conséquent, la maintenance peut parfois poser problème.
Les avantages de l’architecture orientée services
Les principaux avantages de l’architecture orientée services sont les suivants :
- Cette architecture permet de créer des applications hautement évolutives et fiables.
- Les composants sont réutilisables et sont partagés pour améliorer les efforts de développement et de maintenance.
Les inconvénients de l’architecture orientée services
Voici une liste des inconvénients potentiels de l’utilisation de l’architecture orientée services :
- Les applications SOA ne sont toujours pas flexibles à 100 % car la taille et la portée de chaque service ne sont pas fixes. Il peut y avoir des services de la taille d’applications d’entreprise qui peuvent être difficiles à maintenir.
- Le partage des composants introduit des dépendances entre les services.
L’architecture micro-services
L’architecture micro-services a été conçue pour résoudre les problèmes de l’architecture orientée services. Les micro-services sont des composants encore plus modulaires qui s’assemblent pour construire une application web. Cependant, les micro-services s’attachent à garder chaque composant petit et avec un contexte délimité. Le contexte délimité signifie essentiellement que chaque micro-service a son code et ses données couplés ensemble avec des dépendances minimales sur les autres micro-services.
L’architecture micro-services est probablement la meilleure architecture pour construire des applications qui visent à évoluer vers des milliers et des millions d’utilisateurs un jour. Chaque composant est résilient, évolutif et facile à maintenir. Cependant, le maintien du cycle de vie DevOps d’une application basée sur des micro-services nécessite des efforts supplémentaires ; par conséquent, elle ne convient pas forcément aux petits cas d’utilisation.
Avantages de l’architecture micro-services
Voici quelques-uns des avantages de l’architecture micro-services :
- Les composants des applications sont hautement modulaires, indépendants et peuvent être réutilisés dans une plus large mesure que ceux de l’architecture orientée services.
- Chaque composant peut être mis à l’échelle indépendamment pour répondre à un trafic utilisateur variable.
- Les applications basées sur les micro-services sont hautement tolérantes aux pannes.
Inconvénients de l’architecture micro-services
Un inconvénient de l’architecture micro-services peut être :
- Pour les petits projets, l’architecture micro-services peut demander trop d’efforts de maintenance.
Architecture sans serveur
L’architecture sans serveur (serverless) est un autre nouveau venu dans le monde des architectures d’applications web. Cette architecture se concentre sur la décomposition de votre application en termes de fonctions qu’elle est censée exécuter. Ces fonctions sont ensuite hébergées sur des plates-formes FaaS (Function-as-a-Service) en tant que fonctions qui sont invoquées au fur et à mesure des requêtes.
Contrairement à la plupart des autres architectures de cette liste, les applications construites à l’aide de l’architecture sans serveur ne restent pas tout le temps en fonctionnement. Elles se comportent comme des fonctions : elles attendent d’être appelées et, une fois appelées, exécutent le processus défini et renvoient un résultat. En raison de cette nature, ils réduisent les couts de maintenance et sont hautement évolutifs sans grand effort. Cependant, il est difficile d’exécuter des tâches de longue durée à l’aide de tels composants.
Les avantages de l’architecture sans serveur
Voici les principaux avantages de l’architecture sans serveur :
- Les applications sans serveur sont hautement et facilement évolutives. Elles peuvent même s’adapter au trafic entrant en temps réel pour réduire la charge sur votre infrastructure.
- Ces applications peuvent utiliser le modèle de tarification à l’usage des plateformes sans serveur pour réduire les couts d’infrastructure.
- Les applications sans serveur sont assez faciles à construire et à déployer, car il suffit d’écrire une fonction et de l’héberger sur une plate-forme comme Firebase functions, AWS Lambda, etc.
Inconvénients de l’architecture sans serveur
Voici quelques-uns des inconvénients de l’architecture sans serveur :
- Les tâches de longue haleine peuvent être couteuses à réaliser sur une telle architecture.
- Lorsqu’une fonction reçoit une requête après une longue période, on parle de démarrage à froid. Les démarrages à froid sont lents et peuvent offrir une mauvaise expérience à votre utilisateur final.
Couches de l’architecture d’application web
Bien que les architectures d’applications web que vous avez vues ci-dessus puissent toutes sembler très différentes les unes des autres, leurs composants peuvent être logiquement regroupés en couches définies qui aident à atteindre un objectif commercial.
Couche de présentation
La couche de présentation représente tout ce qui, dans une application web, est exposé aux utilisateurs finaux. Principalement, la couche de présentation est composée du client frontend. Cependant, elle incorpore également toute logique que vous avez écrite sur votre backend pour rendre votre frontend dynamique. Cela vous donne la possibilité de servir vos utilisateurs avec une interface utilisateur personnalisée en fonction de leur profil et de leurs exigences.
Trois technologies fondamentales sont utilisées pour construire cette couche : HTML, CSS et JavaScript. Le HTML dessine votre frontend, le CSS le stylise et le JS lui donne vie (c’est-à-dire qu’il contrôle son comportement lorsque les utilisateurs interagissent avec lui). En plus de ces trois technologies, vous pouvez utiliser n’importe quel type de framework pour faciliter votre développement. Parmi les frameworks frontend courants, citons Laravel, React, NextJS, Vue, GatsbyJS, etc.
Couche métier
La couche métier est chargée de contenir et de gérer la logique de fonctionnement de votre application. Il s’agit généralement d’un service backend qui accepte les requêtes du client et les traite. Elle contrôle ce à quoi l’utilisateur peut accéder et détermine comment l’infrastructure est utilisée pour servir les requêtes des utilisateurs.
Dans le cas d’une application de réservation d’hôtel, votre application client sert de portail pour que les utilisateurs puissent saisir les noms des hôtels et d’autres données pertinentes. Cependant, dès que l’utilisateur clique sur le bouton de recherche, la couche métier reçoit la requêtes et lance la logique de recherche des chambres d’hôtel disponibles qui correspondent à vos exigences. Le client reçoit alors simplement une liste de chambres d’hôtel sans savoir comment cette liste a été générée ni même pourquoi les éléments de la liste sont disposés de la manière dont ils ont été envoyés.
La présence d’une telle couche garantit que votre logique métier n’est pas exposée à votre client et, en fin de compte, aux utilisateurs. L’isolement de la logique métier est d’une aide précieuse pour les opérations sensibles telles que le traitement des paiements ou la gestion des dossiers médicaux.
Couche de persistance
La couche de persistance est chargée de contrôler l’accès à vos stockages de de données. Elle agit comme une couche d’abstraction supplémentaire entre vos stockages de données et votre couche métier. Elle reçoit tous les appels liés aux données en provenance des couches métier et les traite en établissant des connexions sécurisées avec la base de données.
Cette couche consiste généralement en un serveur de base de données. Vous pouvez mettre en place cette couche vous-même en provisionnant une base de données et un serveur de base de données dans votre infrastructure sur site ou opter pour une solution distante/gérée par l’un des principaux fournisseurs d’infrastructure dans le cloud comme AWS, GCP, Microsoft Azure, etc.
Composants de l’application web
Maintenant que vous comprenez ce qui entre dans l’architecture d’une application web, examinons en détail chacun des composants qui composent une application web. Nous regrouperons cette discussion en deux grandes rubriques : les composants côté serveur et les composants côté client, ou les composants backend et frontend.
Composants côté serveur
Les composants côté serveur sont ceux qui résident dans le backend de votre application web. Ils ne sont pas exposés directement aux utilisateurs et contiennent la logique commerciale et les ressources les plus importantes de votre application web.
DNS et routage
Le DNS est chargé de contrôler la manière dont votre application est exposée au web. Les enregistrements DNS sont utilisés par les clients HTTP, qui peuvent aussi être des navigateurs, pour trouver et envoyer des requêtes aux composants de votre application. Le DNS est également utilisé par vos clients frontend en interne pour résoudre l’emplacement de vos serveurs web et des points de terminaison API afin d’envoyer des requêtes et de traiter les opérations des utilisateurs.
L’équilibrage de charge est un autre composant populaire de l’architecture des applications web. Un équilibreur de charge est utilisé pour distribuer les requêtes HTTP entre plusieurs serveurs web identiques. L’intention derrière la présence de plusieurs serveurs web est de maintenir la redondance qui aide à augmenter la tolérance aux pannes ainsi qu’à distribuer le trafic pour maintenir une haute performance.
Les points de terminaison API sont utilisés pour exposer les services backend à l’application frontend. Ils permettent de faciliter la communication entre le client et le serveur, et parfois même entre plusieurs serveurs.
Stockage des données
Le stockage des données est une partie cruciale de la plupart des applications modernes, car il y a toujours des données d’application qui doivent être conservées à travers les sessions des utilisateurs. Le stockage des données est de deux types :
- Bases de données : Les bases de données sont utilisées pour stocker des données en vue d’un accès rapide. Habituellement, elles prennent en charge le stockage d’une petite quantité de données auxquelles votre application accède régulièrement.
- Entrepôts de données : Les entrepôts de données sont destinés à la conservation de données historiques. Celles-ci ne sont généralement pas utilisées très souvent dans l’application mais sont traitées régulièrement pour générer des informations commerciales.
La mise en cache
La mise en cache est une fonction facultative souvent mise en œuvre dans les architectures d’applications web pour servir le contenu plus rapidement aux utilisateurs. Une grande partie du contenu des applications est souvent répétitive pendant un certain temps, voire toujours. Au lieu d’y accéder depuis un stockage de données et de le traiter avant de le renvoyer à l’utilisateur, il est souvent mis en cache. Voici les deux types de mise en cache les plus populaires utilisés dans les applications web :
- Mise en cache des données : la mise en cache des données permet à votre application d’accéder facilement et rapidement aux données utilisées régulièrement et qui ne changent pas souvent. Des technologies telles que Redis et Memcache permettent de mettre les données en cache afin d’économiser les couteuses requêtes de base de données pour récupérer les mêmes données encore et encore.
- Mise en cache des pages web : un CDN (Content Delivery Network) met en cache les pages web de la même manière que Redis met en cache les données. De la même manière que seules les données qui ne changent pas souvent sont mises en cache, il est généralement recommandé de ne mettre en cache que les pages web statiques. Pour les applications web à rendu côté serveur, la mise en cache n’est pas très utile puisque leur contenu est censé être très dynamique.
Les tâches et les services
Outre l’exposition d’une interface aux utilisateurs (frontend) et le traitement de leurs requêtes (backend), il existe une autre catégorie de composants d’applications web un peu moins populaire. Les travaux sont souvent des services d’arrière-plan destinés à accomplir des tâches qui ne sont pas sensibles au temps ou synchrones.
Les travaux CRON sont ceux qui sont exécutés sur une période de temps fixe, encore et encore. Ces tâches sont planifiées sur le backend pour exécuter automatiquement des routines de maintenance à des moments précis. Parmi les exemples de cas d’utilisation courants, citons la suppression des doublons/anciens enregistrements de la base de données, l’envoi d’e-mails de rappel aux clients, etc.
Composants côté client
Les composants côté client sont ceux qui sont exposés à vos utilisateurs, directement ou indirectement.
Il existe principalement deux types de composants dans cette catégorie.
Interface utilisateur frontend
L’interface utilisateur est l’aspect visuel de votre application. C’est ce que vos utilisateurs voient et avec lequel ils interagissent afin d’accéder à vos services.
L’interface frontend est principalement construite sur trois technologies populaires : HTML, CSS et JavaScript. L’interface utilisateur frontend peut être une application en soi avec son propre cycle de vie de développement logiciel.
Ces interfaces utilisateur n’abritent pas une grande partie de votre logique commerciale puisqu’elles sont exposées directement à vos utilisateurs. Si un utilisateur malveillant tente de désosser votre application frontend, il peut obtenir des informations sur le fonctionnement de votre entreprise et mener des activités illégales telles que l’usurpation d’identité et le vol de données.
En outre, puisque l’interface utilisateur frontend est exposée directement aux utilisateurs, vous voudrez l’optimiser pour un temps de chargement et une réactivité minimaux. Cela peut parfois vous aider à offrir une meilleure expérience à vos utilisateurs, augmentant ainsi la croissance de votre entreprise.
Logique d’entreprise côté client
Parfois, vous pouvez avoir besoin de stocker une certaine logique commerciale sur votre client afin d’effectuer rapidement des opérations plus simples. La logique côté client qui réside habituellement dans votre application frontend peut vous aider à éviter le voyage vers le serveur et à offrir à vos utilisateurs une expérience plus rapide.
Il s’agit d’une fonctionnalité facultative des composants côté client. Dans certains cas, la logique d’entreprise de l’application est entièrement stockée côté client (notamment lors de la construction sans serveur backend traditionnel). Les solutions modernes telles que BaaS vous permettent d’accéder à des opérations courantes telles que l’authentification, le stockage de données, le stockage de fichiers, etc., en cours de route dans votre application frontend.
Il existe des moyens d’obscurcir ou de minifier ce code avant de le déployer auprès de vos utilisateurs afin de minimiser les risques de rétro-ingénierie.
Modèles de composants d’applications web
Il existe plusieurs modèles d’architectures d’applications web, chacun basé sur la façon dont les serveurs web se connectent à leurs stockages de données.
Un serveur, une base de données
Le modèle le plus simple de tous est celui d’un serveur web se connectant à une instance de base de données. Un tel modèle est facile à mettre en œuvre et à maintenir, et sa mise en production est également assez aisée.
En raison de sa simplicité, ce modèle convient à l’apprentissage et aux petites applications expérimentales qui ne seront pas exposées à un trafic élevé. Les développeurs novices peuvent facilement mettre en place et bricoler ces applications pour apprendre les principes fondamentaux du développement d’applications web.
Cependant, ce modèle ne devrait pas être utilisé en production car il est très peu fiable. Un problème dans le serveur ou la base de données peut entrainer un temps d’arrêt et une perte d’activité.
Plusieurs serveurs, une base de données
Ce modèle fait monter l’application d’un cran en mettant en place plusieurs serveurs pour la redondance avec une seule instance de base de données commune.
Étant donné que plusieurs serveurs web accèdent simultanément à la base de données, des problèmes d’incohérence peuvent survenir. Pour éviter cela, les serveurs web sont conçus pour être sans état. Cela signifie que les serveurs ne conservent pas les données entre les sessions ; ils se contentent de les traiter et de les stocker dans la base de données.
Les applications réalisées à l’aide de ce modèle sont certainement plus fiables que celles du modèle précédent, car la présence de plusieurs serveurs web ajoute de la tolérance aux pannes de l’application web. Toutefois, comme la base de données est toujours une instance commune, elle constitue le maillon faible de l’architecture et peut être une source de défaillance.
Serveurs multiples, bases de données multiples
Ce modèle est l’un des modèles les plus courants et traditionnels de conception d’applications web.
Dans ce cas, déployez la logique de votre application sous la forme de plusieurs instances de serveurs web identiques regroupées derrière un équilibreur de charge. Votre stockage de données est également maintenu sur plusieurs instances de base de données pour une tolérance accrue aux pannes.
Vous pouvez également choisir de répartir votre base de données entre les instances disponibles pour améliorer les performances ou de maintenir des doubles de l’ensemble du stockage de données pour la redondance. Dans les deux cas, la défaillance d’une instance de votre base de données n’entrainera pas l’interruption complète de l’application.
Ce modèle est très apprécié pour sa fiabilité et son évolutivité. Toutefois, le développement et la maintenance d’applications utilisant ce modèle sont relativement compliqués et nécessitent des développeurs chevronnés et coûteux. En tant que tel, ce modèle n’est suggéré que lorsque vous construisez à grande échelle.
Services d’applications
Si les trois modèles mentionnés ci-dessus sont bien adaptés aux applications monolithiques, il existe un autre modèle pour les applications modulaires.
Le modèle des services d’application décompose une application en modules plus petits basés sur la fonctionnalité commerciale. Ces modules peuvent être aussi petits qu’une fonction ou aussi grands qu’un service.
L’idée ici est de rendre chaque fonctionnalité métier indépendante et évolutive. Chacun de ces modules peut se connecter à la base de données de manière autonome. Vous pouvez même avoir des instances de base de données dédiées pour répondre aux besoins d’évolutivité de votre module.
Parmi les applications non monolithiques, ce modèle est assez populaire. Les anciennes applications monolithiques sont souvent migrées vers ce modèle pour profiter de ses avantages en termes d’évolutivité et de modularité. Cependant, la gestion des applications construites sur un tel modèle nécessite souvent des développeurs chevronnés, notamment une expérience en DevOps et CI/CD.
Meilleures pratiques pour l’architecture des applications web
Voici quelques bonnes pratiques que vous pouvez mettre en œuvre dans votre projet d’application web pour tirer le meilleur parti de l’architecture d’application web que vous avez choisie.
1. Rendez votre frontend responsive
On ne le dira jamais assez : Visez toujours des frontends responsives. Quelle que soit l’ampleur et la complexité de votre application web en interne, tout est exposé à vos utilisateurs via des pages web, des applications et des écrans frontend.
Si vos utilisateurs trouvent ces écrans peu intuitifs ou lents, ils ne resteront pas assez longtemps pour voir et admirer la merveille d’ingénierie qu’est votre application web.
Par conséquent, il est très important de concevoir des frontends accessibles, faciles à utiliser et légers.
Il existe de nombreuses meilleures pratiques UI/UX disponibles sur le web pour vous aider à comprendre ce qui fonctionne le mieux pour vos utilisateurs. Vous pouvez trouver des professionnels compétents pour réaliser des conceptions et des architectures conviviales qui permettront à vos utilisateurs de tirer le meilleur parti de vos applications.
Nous vous conseillons de réfléchir sérieusement à la réactivité de votre frontend avant de déployer votre produit auprès de vos utilisateurs.
2. Surveillez les temps de chargement
En plus d’être faciles à comprendre, vos interfaces publiques doivent également être rapides à charger.
Selon Portent, les taux de conversion eCommerce les plus élevés se produisent sur les pages dont le temps de chargement est compris entre 0 et 2 secondes, et selon Unbounce, environ 70 % des consommateurs admettent que le temps de chargement des pages est un facteur important dans leur choix d’acheter auprès d’un vendeur en ligne.
Lorsque vous concevez des applications natives mobiles, vous ne pouvez généralement pas être certain des spécifications de l’appareil de vos utilisateurs. Tout appareil qui ne répond pas aux exigences de votre application est généralement déclaré comme ne supportant pas l’application.
Cependant, il en va tout autrement avec le web.
Lorsqu’il s’agit d’applications web, vos utilisateurs peuvent utiliser n’importe quoi, du dernier Macbook M1 Pros d’Apple aux téléphones Blackberry et Nokia vintage, pour visualiser votre application. Optimiser votre expérience frontend pour un tel éventail d’utilisateurs peut parfois être difficile.
Des services comme LightHouse et Google PageSpeed viennent à l’esprit lorsqu’on parle de performances d’interfaces publiques. Vous devriez utiliser ces outils pour évaluer votre application frontend avant de la déployer en production. La plupart de ces outils vous fournissent une liste de conseils pratiques pour vous aider à améliorer les performances de votre application autant que possible.
Les derniers 5 à 10 % des performances de l’application sont généralement spécifiques à votre cas d’utilisation et ne peuvent être corrigés que par quelqu’un qui connait bien votre application et ses technologies. Cela ne fait jamais de mal d’investir dans les performances web !
3. Préférez les PWA chaque fois que c’est possible
Comme nous l’avons vu précédemment, les PWA sont les designs de l’avenir. Elles s’adaptent bien à la plupart des cas d’utilisation et offrent l’expérience la plus uniforme sur les principales plates-formes.
Vous devriez envisager d’utiliser les PWA pour votre application aussi souvent que possible. L’expérience native sur le web et le mobile a un impact considérable sur vos utilisateurs et peut également réduire votre propre charge de travail.
Les PWA sont également rapides à charger, faciles à optimiser et rapides à construire. Opter pour les PWA peut vous aider à déplacer une grande partie de votre attention du développement vers les affaires dès le début.
4. Gardez votre base de code propre et succincte
Une base de code propre peut vous aider à repérer et à résoudre la plupart des problèmes avant qu’ils ne causent des dégâts. Voici quelques conseils que vous pouvez suivre pour vous assurer que votre base de code ne vous cause pas plus de problèmes qu’il ne devrait.
- Concentrez-vous sur la réutilisation du code : Maintenir des copies du même code dans l’ensemble de votre base de code n’est pas seulement redondant, mais cela peut également entrainer des divergences, rendant votre base de code difficile à maintenir. Concentrez-vous toujours sur la réutilisation du code dans la mesure du possible.
- Planifiez la structure de votre projet : Les projets logiciels peuvent prendre beaucoup d’ampleur avec le temps. Si vous ne commencez pas avec une structure planifiée de l’organisation du code et des ressources, vous pourriez finir par passer plus de temps à trouver des fichiers qu’à écrire du code utile.
- Écrivez des tests unitaires : Chaque morceau de code a une chance de se casser. Il n’est pas possible de tout tester manuellement, vous avez donc besoin d’une stratégie fixe pour automatiser les tests de votre base de code. Les outils d’exécution des tests et d’évaluation du code peuvent vous aider à déterminer si vos efforts en matière de tests unitaires donnent les résultats escomptés.
- Une grande modularité : Lorsque vous écrivez du code, concentrez-vous toujours sur la modularité. L’écriture d’un code étroitement couplé à d’autres morceaux de code rend difficile le test, la réutilisation et la modification en cas de besoin.
5. Automatisez vos processus CI/CD
CI/CD est l’abréviation de Continuous Integration/Continuous Deployment (intégration continue/déploiement continu). Les processus CI/CD sont cruciaux pour le développement de votre application car ils vous aident à construire, tester et déployer votre projet en toute simplicité.
Cependant, vous ne voulez pas avoir à les exécuter manuellement à chaque fois. Vous devriez plutôt mettre en place des pipelines qui se déclenchent automatiquement en fonction des activités de votre projet. Par exemple, vous pourriez mettre en place un pipeline qui exécute vos tests automatiquement chaque fois que vous livrez votre code à votre système de contrôle de version. Il existe également de nombreux cas d’utilisation plus complexes, comme la génération d’artefacts multiplateformes à partir de votre dépôt de code chaque fois qu’une version est créée.
Les possibilités sont infinies, il ne tient qu’à vous de trouver comment tirer le meilleur parti de vos pipelines CI/CD.
6. Incorporez des fonctions de sécurité
La plupart des applications modernes sont constituées de plusieurs composants. Prenez l’application suivante comme exemple :
Les requêtes des clients sont acheminées vers l’application par une passerelle API. Bien que celle-ci ne permette actuellement que des demandes directes au module d’accueil de l’application, elle pourrait, à l’avenir, permettre l’accès à davantage de composants sans passer par le module d’accueil.
Ensuite, le module d’accueil vérifie un BaaS d’authentification externe avant d’autoriser l’accès. Une fois authentifié, le client peut accéder aux pages « Mettre à jour le profil » ou « Voir le profil ». Ces deux pages interagissent avec une solution de base de données commune et gérée qui traite les données du profil.
Comme vous pouvez le constater, l’application ressemble à une version très basique et minimale d’un annuaire de personnes en ligne. Vous pouvez ajouter/mettre à jour votre propre profil ou consulter les autres profils disponibles.
Voici une rapide légende des différents composants de l’architecture :
- Boîtes bleues : Modules d’application, qui sont éventuellement hébergés en tant que micro-services ou fonctions sans serveur.
- Boîtes rouges : Composants BaaS externes qui assurent l’authentification et la base de données.
- Boîtes vertes : Composant de routage qui modère les requêtes entrantes du client.
- Boîte noire : Votre application client exposée à l’utilisateur.
Les composants de chacune des couleurs ci-dessus sont vulnérables à divers types de menaces de sécurité. Voici quelques constructions de sécurité que vous pouvez mettre en place pour minimiser votre exposition :
- Modules d’application (bleu) : Comme il s’agit de fonctions sans serveur, voici quelques conseils pour renforcer leur sécurité :
- Isolez les secrets de l’application et gérez-les indépendamment de votre code source
- Maintenez les contrôles d’accès par le biais de services IAM
- Améliorez vos efforts de test pour rechercher également les menaces de sécurité grâce à des techniques telles que SAST
- Services externes (rouge) :
- Mettez en place des contrôles d’accès via leurs modules IAM pour réguler l’accès
- Optez pour la limitation du débit de l’API
- Pour les services tels que les bases de données, mettez en place des autorisations de contrôle plus fin, comme par exemple qui peut accéder aux données des profils, qui peut voir les données des utilisateurs, et plus encore. De nombreux services, comme Firebase, fournissent un ensemble détaillé de ces règles.
- Composant de routage (vert) :
- Comme tous les autres composants, mettez en place des contrôles d’accès
- Configurez l’autorisation
- Vérifiez les meilleures pratiques standard telles que CORS
- Client :
- Assurez-vous qu’aucun secret de l’application n’est accessible à votre client
- Obfusquez votre code client pour minimiser les risques de rétro-ingénierie
Bien qu’il ne s’agisse que de quelques suggestions, elles démontrent que la sécurité des applications est complexe et qu’il est de votre responsabilité de vous assurer que vous ne laissez aucune marge de manœuvre aux attaquants. Vous ne pouvez pas compter sur un composant de sécurité central pour protéger votre entreprise ; la sécurité des applications est répartie sur l’ensemble de votre architecture d’applications.
7. Collectez les commentaires des utilisateurs
Le retour d’information des utilisateurs est un outil crucial pour comprendre l’efficacité de votre application en termes de performances commerciales et techniques. Vous pouvez construire l’application la plus légère et la plus fluide du monde, mais si elle ne permet pas à vos utilisateurs de faire ce qu’ils attendent, tous vos efforts seront réduits à néant.
Il existe de multiples façons de recueillir les commentaires des utilisateurs. Si une enquête rapide et anonyme est l’approche classique, vous pouvez également opter pour une solution plus sophistiquée, comme une carte thermique de l’activité de vos utilisateurs.
Le choix de la méthode de collecte des commentaires est moins important que le fait de prendre des mesures en fonction des commentaires recueillis. Les clients aiment les entreprises qui sont à l’écoute de leurs problèmes. Des géants comme McDonald’s et Tesla le font, et c’est l’une des raisons pour lesquelles ils continuent à réussir sur leurs marchés.
Résumé
Le web est un immense terrain de jeu où l’on trouve une grande variété d’applications, chacune conçue de manière unique. Les multiples types d’architectures permettent aux applications web de se diversifier, de prospérer et d’offrir des services aux utilisateurs du monde entier.
Dans ce guide, nous avons décomposé les différents modèles d’architecture d’application web et vous avons montré à quel point ils sont cruciaux pour la croissance d’une application.
Y a-t-il une architecture d’application web que vous avez vraiment aimée ? Ou y a-t-il une autre que vous aimeriez partager avec le monde ? Faites-nous en part dans les commentaires ci-dessous !
Kumar is a software developer and a technical author based in India. He specializes in JavaScript and DevOps. You can learn more about his work on his website.
Laisser un commentaire