Qu'est-ce que l'architecture d'applications Web ? Décomposer une application Web

Le monde est passé à Internet et les applications Web sont devenues les nouveaux lieux de travail et magasins commerciaux. Pour s'adapter à la variété des objectifs que servent les applications Web modernes, chacune d'entre elles doit être conçue pour des performances élevées et une personnalisation.

Les architectures d'applications Web résolvent ce problème.
Vous souhaitez en savoir plus sur l'architecture des applications Web ? Vous êtes au bon endroit Cliquez pour tweeter
L'architecture d'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 à la finalité de l'application web. Choisir la mauvaise architecture pour votre application Web peut faire des ravages dans 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'applications Web ?

Pour lancer la discussion, commençons par la définition de l'architecture des applications Web.

En termes simples, l'architecture de l'application Web est un aperçu de la façon 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. Cela peut également être aussi complexe que de définir les interrelations entre un essaim de serveurs backend conteneurisés, d'équilibreurs de charge, de passerelles API et d'interfaces à page unique destinées aux utilisateurs.

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 coûts. Voici à quoi ressemble un exemple d'architecture d'application Web sur papier :

Pourquoi l'architecture des applications Web est-elle importante ?

L'architecture des applications 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 avec une architecture spécifique à l'esprit, vous êtes certain de bénéficier de nombreux avantages en termes de maintenance et de développement de votre application.

Cependant, choisir 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.

S'adapter facilement aux besoins de l'entreprise

Votre application est une passerelle clé vers votre entreprise, et les besoins de l'entreprise évoluent avec l'évolution du marché. Pour suivre le rythme, vous souhaiterez que votre application soit suffisamment flexible pour s'adapter à l'évolution des besoins de votre entreprise. Et si vous créez une application sans tenir compte de la flexibilité intégrée, vous passerez forcément de plus en plus de temps et d'efforts à effectuer de minuscules ajustements dans votre application.

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 créez une application de commerce électronique qui évoluera et fournira un jour une large gamme de services à un grand nombre de clients, choisir une architecture de microservices plutôt qu'une architecture monolithique vous offrira 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 offre 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 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 autrement pu être dépensés ailleurs.

Meilleure gestion de la base de code

Outre l'écriture du code de votre application, vous passerez également beaucoup de temps à la gérer. L'organisation de vos fichiers de projet, la décomposition de votre application en modules et la configuration de pipelines personnalisés ne sont que quelques-unes des tâches qui nécessitent une maintenance active pour assurer un développement fluide.

La bonne architecture d'application Web vous permet d'apporter facilement des modifications. Vous pouvez mettre en œuvre les meilleures pratiques spécifiques aux composants, séparer les points faibles de votre application les uns des autres et garder chaque fonctionnalité 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.

Suivre une architecture prédéfinie vous permet également de développer facilement vos applications plus rapidement. La bonne architecture combinée à une bonne stratégie de contrôle de version peut permettre à vos développeurs de travailler en parallèle les uns avec les autres et de créer des fonctionnalités plus rapidement.

Une architecture d'application Web assure également la pérennité 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 pratiques à mettre en œuvre pour améliorer la sécurité de l'application avant son déploiement auprès des utilisateurs.

Par exemple, la création d'une application de streaming vidéo OTT qui offre à la fois du contenu payant et gratuit à l'aide de microservices est plus logique car l'architecture des microservices vous permet de diviser votre application en composants adaptés aux entreprises, tels que l'authentification de l'utilisateur et le streaming de contenu gratuit ou payant. Si votre module d'authentification utilisateur tombe en panne, vous pouvez facilement configurer votre application pour restreindre l'accès au module de contenu payant jusqu'à ce que l'authentification soit activée, tandis que le module de contenu gratuit est toujours 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 en panne signifierait soit une application en panne, soit un contenu payant mis à disposition gratuitement - des résultats que vous voudrez éviter à tout prix.

Comment fonctionne l'architecture des applications Web ?

Avant de parler du fonctionnement de l'architecture des applications Web, il est important de comprendre le fonctionnement d'un site Web simple :

1. L'utilisateur saisit l'URL de votre application dans la barre d'adresse du navigateur ou clique sur un lien.
2. Le navigateur recherche l'URL dans les serveurs DNS et identifie l'adresse IP de votre application.
3. Le navigateur envoie une requête HTTP à votre application.
4. Votre application répond avec le contenu correct (généralement une page Web).
5. Le navigateur affiche la page Web à l'écran.

Si vous deviez approfondir un peu, voici comment une application Web traiterait une requête :

1. L'utilisateur envoie une demande à votre application via votre interface utilisateur frontale.
2. Si vous avez configuré un cache pertinent, l'application le vérifiera d'abord pour voir s'il a un enregistrement valide qui peut être renvoyé directement au client. Si oui, le contenu mis en cache sera renvoyé et la demande sera marquée comme terminée.
3. S'il n'y a pas de cache, la demande est transmise à l'équilibreur de charge.
4. L'équilibreur de charge identifie une instance de serveur disponible pour gérer la demande et la transmet.
5. L'instance de serveur traite la demande et appelle les API externes si nécessaire.
6. Une fois les résultats collectés à un endroit, le serveur renvoie la réponse à l'équilibreur de charge.
7. L'équilibreur de charge renvoie la réponse à la passerelle API, qui à son tour l'envoie à l'utilisateur dans le client frontal. La demande est alors marquée comme terminée.

Types d'architecture d'applications 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 courants utilisés sur le Web.

Architecture monopage

L'architecture d'une application monopage (SPA) est aussi simple que son nom : toute l'application est basée sur une seule page. Une fois que l'utilisateur lance 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 afficher des écrans qui répondent aux exigences des utilisateurs lorsqu'ils naviguent dans l'application elle-même.

Les SPA sont parfaits lorsqu'il s'agit de fournir 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 référencement.

Avantages de l'architecture SPA

Certains des avantages de l'architecture SPA incluent :

• Vous pouvez créer des applications Web hautement interactives.
• Les SPA sont faciles à mettre à l'échelle.
• L'optimisation des performances des SPA ne nécessite 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 référencement.
• 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 Web progressive (PWA) s'appuie sur l'architecture de page unique en fournissant des fonctionnalités hors ligne pour votre application Web. Des technologies telles que Capacitor et Ionic sont utilisées pour créer des PWA qui peuvent offrir aux utilisateurs une expérience uniforme sur toutes les plateformes.

Semblables aux SPA, les PWA sont fluides et fluides. Avec la possibilité supplémentaire d'être installé sur les appareils des utilisateurs (via les techniciens de service), vos utilisateurs bénéficient d'une expérience plus uniforme avec votre application.

Dans le 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.

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.
• L'accès hors ligne et les API natives de l'appareil telles que les travailleurs en arrière-plan et les notifications push sont accessibles aux développeurs.

Inconvénients de l'architecture PWA

Certains des inconvénients de l'architecture PWA peuvent inclure :

• La prise en charge de la gestion des liens et du référencement est limitée.
• Pousser les mises à jour vers les PWA hors ligne est plus complexe qu'avec les applications natives.
• La prise en charge des PWA est limitée dans les navigateurs Web et les systèmes d'exploitation.

Architecture de rendu côté serveur

Dans le rendu côté serveur (SSR), les pages Web frontales sont rendues sur un serveur principal 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 HTML, CSS et JS statique.

Les applications SSR sont très populaires parmi les blogs et les sites de commerce électronique. En effet, ils simplifient la gestion des liens et le référencement. De plus, le premier rendu pour les applications SSR est assez rapide car le client n'a pas besoin de 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 à forte intensité de référencement.
• 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 liés à l'utilisation de l'architecture SSR :

• Il n'est pas recommandé pour les pages Web complexes ou lourdes car le serveur peut prendre du temps pour générer entièrement la page, ce qui entraîne un premier rendu retardé.
• Il est principalement recommandé pour les applications qui ne se concentrent pas beaucoup sur l'interface utilisateur et qui recherchent uniquement une évolutivité ou une sécurité accrues.

Architecture d'applications pré-rendu

L'architecture des applications pré-rendues est également connue sous le nom d'architecture de génération de site statique. Dans cette architecture, les pages Web frontales de l'application sont pré-générées et stockées sous forme de fichiers HTML, CSS et JS simples sur le serveur. Une fois qu'un utilisateur demande une page, elle est directement récupérée et affiché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 idéales lorsque vous cherchez à générer du contenu statique tel que des blogs ou des détails sur les produits qui ne changent pas souvent. Vous pouvez également utiliser des modèles pour simplifier la conception de votre page Web. Cependant, il est presque impossible de créer des applications Web dynamiques avec cette architecture. Si vous cherchez à créer 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 route possible de l'application est pré-rendue pendant le processus de construction, il est impossible d'avoir des routes dynamiques comme ci-dessus car il existe une infinité de possibilités qui ne peuvent pas être pré-rendues pendant la construction (et cela n'a pas de sens de faire donc non plus).

Avantages de l'architecture pré-rendu

Voici quelques-uns des principaux avantages de l'architecture des applications pré-rendues :

• Les pages Web sont générées en pur HTML, CSS et JS ; par conséquent, leurs performances sont similaires à celles des applications créées à l'aide de vanilla JS.
• Si vous connaissez tous les itinéraires possibles de votre application, le référencement devient super facile.

Inconvénients de l'architecture pré-rendu

Comme pour tout modèle architectural, le pré-rendu a son lot d'inconvénients :

• Le contenu dynamique ne peut pas être diffusé avec ces applications.
• Toute modification de l'application Web signifie reconstruire et déployer complètement l'application à partir de zéro.

Architecture d'application isomorphe

Les applications isomorphes sont celles qui sont un mélange d'applications et de SPA rendus côté serveur. Cela signifie que ces applications sont d'abord rendues sur le serveur en tant qu'application normale rendue côté serveur. Une fois qu'ils sont reçus 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 d'une seule page.

Isomorphic réunit le meilleur des deux mondes. Vous bénéficiez d'un traitement et d'une interface utilisateur ultra-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 référencement et de la liaison, grâce au rendu côté serveur.

Avantages de l'architecture isomorphe

Voici quelques-uns des avantages de l'utilisation d'une architecture d'application isomorphe :

• Les applications isomorphes ont un rendu initial ultra rapide et une prise en charge complète du référencement.
• Ces applications fonctionnent également bien sur le client car elles se transforment en SPA après le chargement.

Inconvénients de l'architecture isomorphe

Certains des inconvénients de l'architecture d'application isomorphe peuvent être :

• 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 ne pouvez choisir que parmi une poignée de bibliothèques et de frameworks (principalement) basés sur JS.

Architecture orientée services

L'architecture orientée services est l'une des alternatives les plus populaires à la méthode monolithique traditionnelle de création d'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 et interagissent les uns avec les autres via la transmission de messages.

L'architecture orientée services ajoute de la stabilité et de l'évolutivité à votre pile technologique d'applications. Cependant, la taille des services dans la SOA n'est pas clairement définie et est généralement liée aux composants métier, et non aux composants techniques ; par conséquent, la maintenance peut parfois être un problème.

Avantages de l'architecture orientée services

Les principaux avantages de l'architecture orientée services incluent :

• 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.

Inconvénients de l'architecture orientée services

Voici une liste des inconvénients potentiels de l'utilisation d'une 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. Certains services de la taille d'applications d'entreprise peuvent être difficiles à maintenir.
• Le partage de composants introduit des dépendances entre les services.

Architecture de microservices

L'architecture de microservices a été conçue pour résoudre les problèmes liés à l'architecture orientée services. Les microservices sont des composants encore plus modulaires qui s'emboîtent pour créer une application Web. Cependant, les microservices se concentrent sur le fait de garder chaque composant petit et avec un contexte limité. Le contexte délimité signifie essentiellement que chaque microservice a son code et ses données couplés avec des dépendances minimales sur d'autres microservices.

L'architecture des microservices est probablement la meilleure architecture pour créer des applications qui visent à s'adapter un jour à des milliers et des millions d'utilisateurs. Chaque composant est résilient, évolutif et facile à entretenir. Cependant, la maintenance du cycle de vie DevOps pour une application basée sur des microservices nécessite des efforts supplémentaires ; par conséquent, il peut ne pas convenir aux cas d'utilisation plus petits.

Avantages de l'architecture des microservices

Certains avantages de l'architecture de microservices incluent :

• Les composants de l'application 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 s'adapter au trafic utilisateur variable.
• Les applications basées sur des microservices sont hautement tolérantes aux pannes.

Inconvénients de l'architecture des microservices

Un inconvénient de l'architecture des microservices peut être :

• Pour les petits projets, l'architecture des microservices peut nécessiter trop d'efforts pour être maintenue.

Architecture sans serveur

L'architecture sans serveur est un autre entrant en vogue dans le monde des architectures d'applications Web. Cette architecture se concentre sur la décomposition de votre application en fonction des fonctions qu'elle est censée exécuter. Ensuite, ces fonctions sont hébergées sur des plates-formes FaaS (Function-as-a-Service) en tant que fonctions appelées au fur et à mesure que les demandes arrivent.

Contrairement à la plupart des autres architectures de cette liste, les applications créées à l'aide de l'architecture sans serveur ne restent pas en cours d'exécution en permanence. Ils se comportent comme le feraient des fonctions - attendent d'être appelés et, une fois appelés, exécutent le processus défini et renvoient un résultat. En raison de cette nature, ils réduisent les coûts de maintenance et sont hautement évolutifs sans trop d'efforts. Cependant, il est difficile d'effectuer des tâches de longue durée en utilisant de tels composants.

Avantages de l'architecture sans serveur

Voici les principaux avantages de l'architecture sans serveur :

• Les applications sans serveur sont hautement et facilement évolutives. Ils 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'utilisation des plates-formes sans serveur pour réduire les coûts d'infrastructure.
• Les applications sans serveur sont assez faciles à créer et à déployer car tout ce que vous avez à faire est d'écrire une fonction et de l'héberger sur une plate-forme comme les fonctions Firebase, 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 durée peuvent être coûteuses à réaliser sur une telle architecture.
• Lorsqu'une fonction reçoit une demande après une longue période, on parle de démarrage à froid. Les démarrages à froid sont lents et peuvent fournir une mauvaise expérience à votre utilisateur final.

Couches d'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 regroupés logiquement en couches définies qui aident à atteindre un objectif commercial.

Couche de présentation

La couche de présentation représente tout dans une application Web qui est exposée aux utilisateurs finaux. Principalement, la couche de présentation est composée du client frontal. Cependant, il intègre é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 adaptée à leur profil et à leurs besoins.

Trois technologies fondamentales sont utilisées pour construire cette couche : HTML, CSS et JavaScript. HTML présente votre frontend, CSS le stylise et 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. Certains frameworks frontaux courants incluent Laravel, React, NextJS, Vue, GatsbyJS, etc.

Couche métier

La couche métier est chargée de conserver et de gérer la logique de fonctionnement de votre application. Il s'agit généralement d'un service backend qui accepte les demandes du client et les traite. Il contrôle ce à quoi l'utilisateur peut accéder et détermine comment l'infrastructure est utilisée pour répondre aux demandes des utilisateurs.

Dans le cas d'une application de réservation d'hôtel, votre application client sert de portail permettant aux utilisateurs de saisir les noms d'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 demande et lance la logique de recherche des chambres d'hôtel disponibles qui correspondent à vos besoins. Le client reçoit alors simplement une liste de chambres d'hôtel sans aucune connaissance de la manière dont cette liste a été générée ou 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. Isoler la logique métier aide énormément dans 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 magasins de données. Cela agit comme une couche d'abstraction supplémentaire entre vos banques de données et votre couche métier. Il reçoit tous les appels liés aux données des couches métier et les traite en établissant des connexions sécurisées à la base de données.

Cette couche se compose généralement d'un serveur de base de données. Vous pouvez définir vous-même cette couche 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 cloud comme AWS, GCP, Microsoft Azure, etc.

Composants d'applications Web

Maintenant que vous comprenez ce qui se passe dans une architecture d'application Web, examinons en détail chacun des composants qui composent une application Web. Nous regrouperons cette discussion en deux rubriques principales - 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 sur le backend de votre application Web. Ceux-ci ne sont pas exposés directement aux utilisateurs et contiennent la logique métier et les ressources les plus importantes pour 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 également être un navigateur, pour rechercher et envoyer des requêtes aux composants de votre application. Le DNS est également utilisé par vos clients frontaux en interne pour déterminer l'emplacement de vos serveurs Web et des points de terminaison d'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 répartir les requêtes HTTP entre plusieurs serveurs Web identiques. L'intention d'avoir plusieurs serveurs Web est de maintenir une redondance qui aide à augmenter la tolérance aux pannes ainsi qu'à distribuer le trafic pour maintenir des performances élevées.

Les points de terminaison d'API sont utilisés pour exposer les services backend à l'application frontend. Ceux-ci aident à faciliter la communication entre le client et le serveur, et parfois même entre plusieurs serveurs également.

Stockage de données

Le stockage des données est un élément crucial de la plupart des applications modernes car il y a toujours des données d'application qui doivent être conservées à travers les sessions utilisateur. 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 pour un accès rapide. Habituellement, ils 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 préservation des données historiques. Celles-ci ne sont généralement pas nécessaires très souvent dans l'application, mais sont traitées régulièrement pour générer des informations commerciales.

Mise en cache

La mise en cache est une fonctionnalité facultative souvent implémentée dans les architectures d'applications Web pour fournir du contenu plus rapidement aux utilisateurs. Une grande partie du contenu de l'application est souvent répétitive pendant un certain temps, voire toujours. Au lieu d'y accéder à partir d'un magasin 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 régulièrement utilisées qui ne changent pas souvent. Des technologies telles que Redis et Memcache permettent de mettre en cache les données pour économiser sur les requêtes de base de données coûteuses simplement 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 rendues côté serveur, la mise en cache ne sert pas à grand-chose puisque leur contenu est censé être très dynamique.

Emplois et Services

Outre l'exposition d'une interface aux utilisateurs (frontend) et la gestion de leurs demandes (backend), il existe une autre catégorie de composants d'applications Web légèrement moins populaire. Les travaux sont souvent des services d'arrière-plan destinés à effectuer des tâches non urgentes ou synchrones.

Les tâches CRON sont celles qui sont exécutées encore et encore sur une période de temps fixe. Ces tâches sont planifiées sur le backend pour exécuter automatiquement des routines de maintenance à des heures définies. Certains exemples de cas d'utilisation courants incluent 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 frontale

L'interface utilisateur est l'aspect visuel de votre application. C'est ce que vos utilisateurs voient et interagissent pour accéder à vos services.

L'interface frontale repose principalement sur trois technologies populaires : HTML, CSS et JavaScript. L'interface utilisateur frontale peut être une application en soi avec son propre cycle de vie de développement logiciel.

Ces interfaces utilisateur n'hébergent pas une grande partie de votre logique métier puisqu'elles sont exposées directement à vos utilisateurs. Si un utilisateur malveillant essaie de rétro-concevoir votre application frontale, il peut obtenir des informations sur le fonctionnement de votre entreprise et mener des activités illégales telles que l'usurpation d'identité de marque et le vol de données.

De plus, étant donné que l'interface utilisateur frontale est exposée directement aux utilisateurs, vous souhaiterez l'optimiser pour un temps de chargement et une réactivité minimaux. Parfois, cela peut vous aider à offrir une meilleure expérience à vos utilisateurs, augmentant ainsi la croissance de votre entreprise.

Logique métier côté client

Parfois, vous devrez peut-être stocker une logique métier sur votre client afin d'effectuer rapidement des opérations plus simples. La logique côté client qui réside généralement dans votre application frontale 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 métier de l'application est entièrement stockée côté client (en particulier lors de la construction sans serveur principal traditionnel). Les solutions modernes telles que BaaS vous aident à accéder à des opérations courantes telles que l'authentification, le stockage de données, le stockage de fichiers, etc., en déplacement dans votre application frontale.

Il existe des moyens d'obscurcir ou de réduire ce code avant de le diffuser à vos utilisateurs afin de minimiser les risques de rétro-ingénierie.

Modèles de composants d'application Web

Il existe plusieurs modèles d'architectures d'applications Web, chacun basé sur la façon dont les serveurs Web se connectent à leurs magasins de données.

Un serveur, une base de données

Le modèle le plus simple de tous est un serveur Web se connectant à une instance de base de données. Un tel modèle est facile à mettre en œuvre et à entretenir, et passer en production avec lui est également assez facile.

De par sa simplicité, ce modèle est adapté à l'apprentissage et aux petites applications expérimentales qui ne seront pas exposées à un trafic important. Les développeurs novices peuvent facilement configurer et bricoler ces applications pour apprendre les bases du développement d'applications Web.

Cependant, ce modèle ne doit pas être utilisé en production car il est très peu fiable. Un problème au niveau du serveur ou de la base de données peut entraîner des temps d'arrêt et des pertes d'activité.

Plusieurs serveurs, une seule base de données

Ce modèle fait monter l'application d'un cran en configurant 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 d'une session à l'autre ; ils se contentent de le traiter et de le stocker dans la base de données.

Les applications créé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 à la tolérance aux pannes de l'application Web. Cependant, étant donné que la base de données reste une instance commune, c'est le maillon le plus faible de l'architecture et peut être une source de défaillance.

Plusieurs serveurs, plusieurs bases de données

Ce modèle est l'un des modèles traditionnels les plus courants de conception d'applications Web.

Dans ce cas, déployez votre logique d'application en tant que plusieurs instances de serveur Web identiques regroupées derrière un équilibreur de charge. Votre magasin de données est également géré sur plusieurs instances de base de données pour une meilleure tolérance aux pannes.

Vous pouvez également choisir de diviser votre base de données entre les instances disponibles pour améliorer les performances ou conserver des doublons de l'ensemble du magasin de données pour la redondance. Dans les deux cas, la défaillance d'une instance de votre base de données n'entraînera pas une indisponibilité complète de l'application.

Ce modèle est très apprécié pour sa fiabilité et son évolutivité. Cependant, le développement et la maintenance d'applications utilisant ce modèle sont relativement compliqués et nécessitent des développeurs expérimentés et coûteux. En tant que tel, ce modèle n'est suggéré que lorsque vous construisez à grande échelle.

Services d'application

Alors que 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 de services d'application décompose une application en modules plus petits basés sur les fonctionnalités de l'entreprise. 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 seul à la base de données. 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 monolithes hérités sont souvent migrés vers ce modèle pour tirer parti de ses avantages d'évolutivité et de modularité. Cependant, la gestion d'applications construites sur un tel modèle nécessite souvent des développeurs chevronnés, en particulier 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 de votre application Web choisie.

1. Rendez votre interface réactive

On ne le soulignera jamais assez : visez toujours des interfaces réactives. 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 frontaux.

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 interfaces accessibles, faciles à utiliser et légères.

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 qualifiés pour créer des conceptions et des architectures conviviales qui peuvent permettre à vos utilisateurs de tirer le meilleur parti de vos applications.

Nous vous conseillons de réfléchir sérieusement à la réactivité de votre interface avant de déployer votre produit auprès de vos utilisateurs.

2. Surveiller les temps de chargement

En plus d'être faciles à comprendre, vos interfaces doivent également être rapides à charger.

Selon Portent, les taux de conversion de commerce électronique les plus élevés se produisent sur les pages avec des temps de chargement compris entre 0 et 2 secondes, et selon Unbounce, environ 70 % des consommateurs admettent que le temps de chargement de la page est un facteur important dans leur choix d'acheter auprès d'un vendeur en ligne.

Lors de la conception d'applications natives mobiles, vous ne pouvez généralement pas être certain des spécifications des appareils de vos utilisateurs. Tout appareil qui ne répond pas aux exigences de votre application est généralement déclaré ne pas prendre en charge l'application.

Cependant, c'est tout à fait différent avec le Web.

En ce qui concerne les applications Web, vos utilisateurs peuvent utiliser n'importe quoi, des derniers Apple Macbook M1 Pro aux téléphones vintage Blackberry et Nokia pour afficher votre application. Optimiser votre expérience frontale pour un si large éventail d'utilisateurs peut parfois être difficile.

Des services tels que LightHouse et Google PageSpeed ​​viennent à l'esprit lorsque l'on parle de performances frontales. Vous devez utiliser ces outils pour comparer votre application frontale avant de la déployer en production. La plupart de ces outils vous fournissent une liste de conseils pratiques pour vous aider à améliorer autant que possible les performances de votre application.

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 connaît bien votre application et ses technologies. Investir dans la performance Web ne fait jamais de mal !

3. Préférez les PWA dans la mesure du possible

Comme indiqué précédemment, les PWA sont les conceptions du futur. Ils peuvent bien s'adapter à la plupart des cas d'utilisation et ils offrent l'expérience la plus uniforme sur les principales plates-formes.

Vous devriez envisager d'utiliser 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 une grande partie de votre propre charge de travail.

Les PWA sont également rapides à charger, faciles à optimiser et rapides à créer. Opter pour les PWA peut vous aider à vous concentrer très tôt sur le développement et sur les affaires.

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 dommages. Voici quelques conseils que vous pouvez suivre pour vous assurer que votre base de code ne vous cause pas plus de problèmes qu'elle ne le devrait.

• Concentrez-vous sur la réutilisation du code : conserver des copies du même code dans votre base de code est non seulement redondant, mais cela peut également entraîner des divergences, ce qui rend 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 devenir très volumineux avec le temps. Si vous ne commencez pas avec une structure planifiée d'organisation de code et de ressources, vous risquez de passer plus de temps à rechercher des fichiers qu'à écrire du code utile.
• Écrire 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 testeurs et les outils de couverture de code peuvent vous aider à déterminer si vos efforts de test unitaire donnent les résultats souhaités.
• Haute modularité : lorsque vous écrivez du code, concentrez-vous toujours sur la modularité. L'écriture de code étroitement couplé à d'autres éléments de code rend difficile le test, la réutilisation et la modification en cas de besoin.

5. Automatisez vos processus CI/CD

CI/CD signifie Intégration continue/Déploiement continu. Les processus CI/CD sont cruciaux pour le développement de votre application car ils vous aident à créer, tester et déployer facilement votre projet.

Cependant, vous ne voulez pas avoir à les exécuter manuellement à chaque fois. Vous devez plutôt configurer des pipelines qui se déclenchent automatiquement en fonction des activités de votre projet. Par exemple, vous pouvez configurer un pipeline qui exécute vos tests automatiquement chaque fois que vous validez votre code dans votre système de contrôle de version. Il existe également de nombreux cas d'utilisation plus complexes, tels que la génération d'artefacts multiplateformes à partir de votre référentiel de code chaque fois qu'une version est créée.

The possibilities are endless, so it's up to you to figure out how you can make the most out of your CI/CD pipelines.

6. Incorporate Security Features

Most modern apps are made of multiple components. Take the following app as an example:

Client requests are routed to the app through an API gateway. While this one currently only allows direct requests to the home module of the app, in the future, it could allow for access to more components without going through the home module.

Next up, the home module checks an external authentication BaaS before allowing access. Once authenticated, the client can access the “Update Profile” or “View Profile” pages. Both these pages interact with a common, managed database solution that handles the profile data.

As you can see, the application seems like a very basic and minimal version of an online people directory. You can add/update your own profile or view other profiles available.

Here's a quick legend of the various components in the architecture:

• Blue boxes: App modules, which are possibly hosted as microservices or serverless functions.
• Red boxes: External BaaS components that provide for authentication and database.
• Green box: Routing component that moderates incoming requests from the client.
• Black box: Your client application exposed to the user.

The components of each of the colors above are vulnerable to various kinds of security threats. Here are a few security constructs you can put in place to minimize your exposure:

• App modules (blue): Since these are serverless functions, here are a few tips to strengthen their security:
  • Isolate app secrets and manage them independently of your source code
  • Maintain access controls through IAM services
  • Improve your testing efforts to also look for security threats through techniques such as SAST
• External services (red):
  • Set up access controls through their IAM modules to regulate access
  • Opt for API rate limiting
  • Pour les services tels que les bases de données, configurez des autorisations de contrôle plus précises, telles que qui peut accéder aux données des profils, qui peut afficher les données des utilisateurs, etc. De nombreux services, comme Firebase, fournissent un ensemble détaillé de ces règles.
• Routing component (green):
  • Like all other components, implement access controls
  • Set up authorization
  • Double-check on standard best practices such as CORS
• Client:
  • Ensure that no app secrets are available to your client
  • Obfuscate your client code to minimize the chances of reverse engineering

While these are just a handful of suggestions, they stand to make the point that app security is complicated, and it's your responsibility to ensure that you're not leaving any loose ends for attackers to pull on. You cannot rely on a central security component to protect your business; app security is distributed across your app architecture.

7. Collect User Feedback

User feedback is a crucial tool to understand how well your app is doing in terms of business and technical performance. You can build the lightest and the smoothest app in the world, but if it doesn't let your users do what they expect, then all your efforts go down the drain.

There are multiple ways to collect user feedback. While a quick and anonymized survey is the conventional approach, you could also go for a more sophisticated solution, such as a heat map of your users' activity.

The choice of feedback collection method is less important than taking action on the collected feedback. Customers love businesses that listen to their problems. Giants like McDonald's and Tesla do it, and that's one of the reasons why they continue to succeed in their markets.

Sommaire

The web is a huge playground of a variety of applications, each designed in its own unique way. Multiple types of architectures make way for web apps to diversify, thrive, and offer services to users all across the globe.
Learn how web application architecture affects the end-user experience and see best practices you can implement, all in this guide Click to Tweet
In this guide, we broke down the different models of web app architecture and showed you how crucial they are to an application's growth.

Is there a web app architecture that you really loved? Or is there another that you'd like to share with the world? Let us know in the comments below!