Qu’est-ce que l’architecture d’application web ?<\/h2>\n
Pour lancer la discussion, commen\u00e7ons par la d\u00e9finition de l’architecture d’application web.<\/p>\n
En termes simples, l’architecture d’application web est un aper\u00e7u de la mani\u00e8re dont les diff\u00e9rents composants de votre application web interagissent les uns avec les autres.<\/p>\n
Cela peut \u00eatre aussi simple que de d\u00e9finir la relation entre le client et le serveur. Elle peut \u00e9galement \u00eatre aussi complexe que la d\u00e9finition des interrelations entre un essaim de serveurs backend conteneuris\u00e9s, des \u00e9quilibreurs de charge, des passerelles API et des interfaces publiques \u00e0 page unique orient\u00e9es vers l’utilisateur.<\/p>\n
Cela dit, il s’agit rarement de choisir le langage de programmation<\/a> dans lequel vous allez \u00e9crire votre code.<\/p>\n La fa\u00e7on dont vous concevez votre application web joue un r\u00f4le cl\u00e9 \u00e0 la fois dans sa convivialit\u00e9 et dans l’optimisation de vos couts. Voici \u00e0 quoi ressemble un exemple d’architecture d’application web sur le papier :<\/p>\n 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\u00e9velopper votre application web en tenant compte d’une architecture sp\u00e9cifique, vous \u00eates certain de b\u00e9n\u00e9ficier de nombreux avantages lorsqu’il s’agit de maintenir et de d\u00e9velopper votre application.<\/p>\n Toutefois, le choix de la bonne architecture amplifie encore ces avantages.<\/p>\n Voici quelques-unes des principales raisons pour lesquelles vous devriez s\u00e9rieusement envisager d’adopter une architecture d’application web.<\/p>\n Votre application est une porte d’entr\u00e9e cl\u00e9 pour votre entreprise, et les besoins de l’entreprise \u00e9voluent avec les changements du march\u00e9. 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\u00e9 int\u00e9gr\u00e9e, vous passerez certainement de plus en plus de temps et d’efforts \u00e0 faire de petits ajustements \u00e0 votre application au fil du temps.<\/p>\n La bonne architecture d’application web tient d\u00e9j\u00e0 compte de certains des changements dont votre entreprise pourrait avoir besoin \u00e0 l’avenir. Par exemple, si vous savez que vous construisez une application de commerce \u00e9lectronique qui \u00e9voluera et offrira un jour une large gamme de services \u00e0 un grand nombre de clients, choisir une architecture de micro-services plut\u00f4t qu’une architecture monolithique vous apportera plus de flexibilit\u00e9.<\/p>\n D’autre part, si vous cr\u00e9ez une application interne pour votre entreprise avec seulement une ou deux exigences fixes, vous pouvez opter pour un monolithe plus simple pour acc\u00e9l\u00e9rer le d\u00e9veloppement et garder votre base de code propre.<\/p>\n Comme nous l’avons mentionn\u00e9 pr\u00e9c\u00e9demment, la bonne architecture d’application web vous fournit une feuille de route plus pratique pour le d\u00e9veloppement. L’architecture fournit suffisamment de modularit\u00e9 dans votre syst\u00e8me pour isoler les composants si n\u00e9cessaire, et vous avez la libert\u00e9 de choisir la bonne structure de projet pour chacun de vos modules et composants si n\u00e9cessaire.<\/p>\n Si vous vous plongez dans le d\u00e9veloppement d’applications sans avoir une architecture en t\u00eate, vous risquez de perdre du temps et de l’argent \u00e0 r\u00e9organiser vos composants et \u00e0 \u00e9tablir de nouvelles r\u00e8gles pour faciliter la collaboration entre les membres de votre \u00e9quipe<\/a> – du temps et de l’argent qui auraient pu \u00eatre d\u00e9pens\u00e9s ailleurs.<\/p>\n Outre l’\u00e9criture du code de votre application, vous passerez \u00e9galement un temps consid\u00e9rable \u00e0 le g\u00e9rer. L’organisation des fichiers de votre projet, la d\u00e9composition de votre application en modules et la mise en place de pipelines personnalis\u00e9s ne sont que quelques-unes des t\u00e2ches qui n\u00e9cessitent une maintenance active pour assurer un d\u00e9veloppement harmonieux.<\/p>\n La bonne architecture d’application web vous permet d’apporter facilement des modifications. Vous pouvez mettre en \u0153uvre les meilleures pratiques propres \u00e0 chaque composant, s\u00e9parer les points sensibles de votre application les uns des autres et faire en sorte que chaque fonctionnalit\u00e9 soit ind\u00e9pendante et faiblement coupl\u00e9e. Ce n’est pas que ces choses ne peuvent pas \u00eatre faites sans architecture ; c’est juste que la bonne architecture rend tout cela beaucoup plus simple.<\/p>\n Le fait de suivre une architecture pr\u00e9d\u00e9finie vous permet \u00e9galement de d\u00e9velopper vos applications plus rapidement. La bonne architecture combin\u00e9e \u00e0 une bonne strat\u00e9gie de contr\u00f4le des versions<\/a> peut permettre \u00e0 vos d\u00e9veloppeurs de travailler en parall\u00e8le les uns avec les autres et de construire des fonctionnalit\u00e9s plus rapidement.<\/p>\n Une architecture d’application web permet \u00e9galement d’assurer l’avenir de votre application. Une fois que vous avez d\u00e9fini une strat\u00e9gie solide sur la fa\u00e7on d’organiser les composants de votre application, vous pouvez facilement migrer ces composants vers des technologies plus r\u00e9centes, un par un, sans avoir \u00e0 refaire toute votre application.<\/p>\n La plupart des architectures d’applications web tiennent compte de la s\u00e9curit\u00e9 lors de la structuration des composants. Les d\u00e9veloppeurs peuvent planifier, \u00e0 l’avance, les mesures et les pratiques \u00e0 mettre en \u0153uvre pour am\u00e9liorer la s\u00e9curit\u00e9 de l’application<\/a> avant qu’elle ne soit d\u00e9ploy\u00e9e aupr\u00e8s des utilisateurs.<\/p>\n Par exemple, il est plus logique de cr\u00e9er une application de streaming vid\u00e9o<\/a> 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\u00e9s aux besoins de l’entreprise, tels que l’authentification de l’utilisateur<\/a> 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\u00e8s au contenu payant<\/a> jusqu’\u00e0 ce que l’authentification soit r\u00e9tablie, tandis que le module de contenu gratuit reste disponible pour vos utilisateurs.<\/p>\n Dans un autre cas, o\u00f9 cette m\u00eame application a \u00e9t\u00e9 con\u00e7ue comme un monolithe \u00e9troitement coupl\u00e9, un service d’authentification hors service signifierait soit une application hors service<\/a>, soit un contenu payant mis \u00e0 disposition gratuitement – des r\u00e9sultats que vous voudrez \u00e9viter \u00e0 tout prix.<\/p>\n Avant de parler du fonctionnement de l’architecture des applications web, il est important de comprendre comment fonctionne un simple site web :<\/p>\n Si vous deviez plonger un peu plus profond\u00e9ment, voici comment une application web<\/em> traiterait une requ\u00eate :<\/p>\n Maintenant que vous avez une id\u00e9e de base de ce qu’est l’architecture d’application web, examinons en d\u00e9tail certains des types d’architecture d’application web les plus populaires utilis\u00e9s.<\/p>\n L’architecture d’une application \u00e0 page unique (Single-Page Application ou SPA) est aussi simple que son nom : l’application enti\u00e8re est bas\u00e9e sur une seule page. Une fois que l’utilisateur a lanc\u00e9 votre application, il n’a pas besoin de naviguer vers d’autres pages web. L’application est rendue suffisamment dynamique pour r\u00e9cup\u00e9rer et rendre les \u00e9crans qui r\u00e9pondent aux exigences des utilisateurs au fur et \u00e0 mesure qu’ils naviguent dans l’application elle-m\u00eame.<\/p>\n Les SPA sont excellents lorsqu’il s’agit d’offrir une exp\u00e9rience rapide et transparente aux utilisateurs finaux ou aux consommateurs. Cependant, ils n’ont pas la touche d’un site web traditionnel, et ils peuvent \u00eatre difficiles \u00e0 optimiser pour le SEO<\/a>.<\/p>\n Voici quelques-uns des avantages de l’architecture SPA :<\/p>\n Voici quelques-uns des inconv\u00e9nients de l’architecture SPA :<\/p>\n L’architecture d’application wep progressive (Progressive Web Application ou PWA) s’appuie sur l’architecture \u00e0 page unique en fournissant des capacit\u00e9s hors ligne pour votre application web. Des technologies telles que Capacitor et Ionic sont utilis\u00e9es pour construire des PWA qui peuvent offrir aux utilisateurs une exp\u00e9rience uniforme<\/a> sur toutes les plates-formes.<\/p>\n Comme les SPA, les PWA sont fluides et transparentes. Avec la possibilit\u00e9 suppl\u00e9mentaire d’\u00eatre install\u00e9es sur les appareils des utilisateurs (via les workers de service), vos utilisateurs b\u00e9n\u00e9ficient d’une exp\u00e9rience plus uniforme avec votre application.<\/p>\n En m\u00eame temps, il peut \u00eatre difficile d’optimiser ces applications pour le r\u00e9f\u00e9rencement, et les mises \u00e0 jour des applications install\u00e9es peuvent \u00eatre difficiles \u00e0 pousser.<\/p>\n L’architecture PWA pr\u00e9sente de nombreux avantages, notamment :<\/p>\n Parmi les inconv\u00e9nients de l’architecture PWA, on peut citer :<\/p>\n Dans le rendu c\u00f4t\u00e9 serveur (Server-Side Rendering ou SSR), les pages web frontend sont rendues sur un serveur backend apr\u00e8s avoir \u00e9t\u00e9 demand\u00e9es par l’utilisateur. Cela permet de r\u00e9duire la charge sur le p\u00e9riph\u00e9rique client car il re\u00e7oit une page web statique en HTML, CSS et JS.<\/p>\n Les applications SSR sont tr\u00e8s populaires parmi les blogs et les sites de commerce \u00e9lectronique. Cela est d\u00fb au fait qu’elles rendent la gestion des liens et le r\u00e9f\u00e9rencement assez simples. De plus, le premier rendu des applications SSR est assez rapide puisque le client n’a pas \u00e0 traiter de code JS pour rendre les \u00e9crans.<\/p>\n Certains des avantages de l’architecture SSR sont \u00e9num\u00e9r\u00e9s ci-dessous :<\/p>\n Voici quelques inconv\u00e9nients de l’utilisation de l’architecture SSR :<\/p>\n L’architecture d’applications pr\u00e9-rendues est \u00e9galement connue sous le nom d’architecture de g\u00e9n\u00e9ration de sites statiques. Dans cette architecture, les pages web frontend de l’application sont pr\u00e9-g\u00e9n\u00e9r\u00e9es et stock\u00e9es sous forme de fichiers HTML, CSS et JS simples sur le serveur. Lorsqu’un utilisateur demande une page, celle-ci est directement r\u00e9cup\u00e9r\u00e9e et lui est pr\u00e9sent\u00e9e. Cela rend l’application web tr\u00e8s 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.<\/p>\n Les applications web pr\u00e9-rendues sont parfaites lorsque vous cherchez \u00e0 g\u00e9n\u00e9rer du contenu statique tel que des blogs ou des d\u00e9tails sur des produits qui ne changent pas souvent. Vous pouvez \u00e9galement utiliser des mod\u00e8les 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 \u00e0 construire une page de recherche qui prend la requ\u00eate dans son chemin (quelque chose comme \u00c9tant donn\u00e9 que chaque itin\u00e9raire possible de l’application est rendu au pr\u00e9alable pendant le processus de construction, il est impossible d’avoir des itin\u00e9raires dynamiques comme ci-dessus puisqu’il existe une infinit\u00e9 de possibilit\u00e9s qui ne peuvent pas \u00eatre rendues au pr\u00e9alable pendant la construction (et cela n’a pas de sens de le faire non plus).<\/p>\n Voici quelques-uns des principaux avantages de l’architecture d’application pr\u00e9-rendue :<\/p>\n Comme tout mod\u00e8le architectural, l’architecture pr\u00e9-rendue a son lot d’inconv\u00e9nients :<\/p>\n Les applications isomorphes sont celles qui sont un m\u00e9lange d’applications \u00e0 rendu c\u00f4t\u00e9 serveur et de SPA. Cela signifie que ces applications sont d’abord rendues sur le serveur comme une application normale rendue c\u00f4t\u00e9 serveur. Une fois qu’elles sont re\u00e7ues 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 \u00e0 page unique.<\/p>\n L’architecture d’application isomorphe r\u00e9unit le meilleur des deux mondes. Vous obtenez un traitement et une interface utilisateur super rapides sur le client, gr\u00e2ce au SPA. Vous b\u00e9n\u00e9ficiez \u00e9galement d’un rendu initial rapide et d’une prise en charge compl\u00e8te du SEO et des liens, gr\u00e2ce au rendu c\u00f4t\u00e9 serveur.<\/p>\n Voici quelques-uns des avantages de l’utilisation de l’architecture d’application isomorphe :<\/p>\n Voici quelques-uns des inconv\u00e9nients de l’architecture d’application isomorphe :<\/p>\n L’architecture orient\u00e9e services (Service-Oriented Architecture ou SOA) est l’une des alternatives les plus populaires \u00e0 la mani\u00e8re traditionnelle monolithique de construire des applications. Dans cette architecture, les applications web sont d\u00e9compos\u00e9es en services qui repr\u00e9sentent chacun une unit\u00e9 fonctionnelle de l’entreprise. Ces services sont faiblement coupl\u00e9s entre eux et interagissent les uns avec les autres par le biais du passage de messages.<\/p>\n L’architecture orient\u00e9e services ajoute de la stabilit\u00e9 et de l’\u00e9volutivit\u00e9 \u00e0 la pile technologique de votre application. Toutefois, la taille des services dans l’architecture orient\u00e9e services n’est pas clairement d\u00e9finie et est g\u00e9n\u00e9ralement li\u00e9e \u00e0 des composants m\u00e9tier, et non \u00e0 des composants techniques ; par cons\u00e9quent, la maintenance peut parfois poser probl\u00e8me.<\/p>\n Les principaux avantages de l’architecture orient\u00e9e services sont les suivants :<\/p>\n Voici une liste des inconv\u00e9nients potentiels de l’utilisation de l’architecture orient\u00e9e services :<\/p>\n L’architecture micro-services a \u00e9t\u00e9 con\u00e7ue pour r\u00e9soudre les probl\u00e8mes de l’architecture orient\u00e9e services. Les micro-services sont des composants encore plus modulaires qui s’assemblent pour construire une application web. Cependant, les micro-services s’attachent \u00e0 garder chaque composant petit et avec un contexte d\u00e9limit\u00e9. Le contexte d\u00e9limit\u00e9 signifie essentiellement que chaque micro-service a son code et ses donn\u00e9es coupl\u00e9s ensemble avec des d\u00e9pendances minimales sur les autres micro-services.<\/p>\n L’architecture micro-services est probablement la meilleure architecture pour construire des applications qui visent \u00e0 \u00e9voluer vers des milliers et des millions d’utilisateurs un jour. Chaque composant est r\u00e9silient, \u00e9volutif et facile \u00e0 maintenir. Cependant, le maintien du cycle de vie DevOps d’une application bas\u00e9e sur des micro-services n\u00e9cessite des efforts suppl\u00e9mentaires ; par cons\u00e9quent, elle ne convient pas forc\u00e9ment aux petits cas d’utilisation.<\/p>\n Voici quelques-uns des avantages de l’architecture micro-services :<\/p>\n Un inconv\u00e9nient de l’architecture micro-services peut \u00eatre :<\/p>\n 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\u00e9composition de votre application en termes de fonctions qu’elle est cens\u00e9e ex\u00e9cuter. Ces fonctions sont ensuite h\u00e9berg\u00e9es sur des plates-formes FaaS (Function-as-a-Service) en tant que fonctions qui sont invoqu\u00e9es au fur et \u00e0 mesure des requ\u00eates.<\/p>\n Contrairement \u00e0 la plupart des autres architectures de cette liste, les applications construites \u00e0 l’aide de l’architecture sans serveur ne restent pas tout le temps en fonctionnement. Elles se comportent comme des fonctions : elles attendent d’\u00eatre appel\u00e9es et, une fois appel\u00e9es, ex\u00e9cutent le processus d\u00e9fini et renvoient un r\u00e9sultat. En raison de cette nature, ils r\u00e9duisent les couts de maintenance et sont hautement \u00e9volutifs sans grand effort. Cependant, il est difficile d’ex\u00e9cuter des t\u00e2ches de longue dur\u00e9e \u00e0 l’aide de tels composants.<\/p>\n Voici les principaux avantages de l’architecture sans serveur :<\/p>\n Voici quelques-uns des inconv\u00e9nients de l’architecture sans serveur :<\/p>\n Bien que les architectures d’applications web que vous avez vues ci-dessus puissent toutes sembler tr\u00e8s diff\u00e9rentes les unes des autres, leurs composants peuvent \u00eatre logiquement regroup\u00e9s en couches d\u00e9finies qui aident \u00e0 atteindre un objectif commercial.<\/p>\n La couche de pr\u00e9sentation repr\u00e9sente tout ce qui, dans une application web, est expos\u00e9 aux utilisateurs finaux. Principalement, la couche de pr\u00e9sentation est compos\u00e9e du client frontend. Cependant, elle incorpore \u00e9galement toute logique que vous avez \u00e9crite sur votre backend pour rendre votre frontend dynamique. Cela vous donne la possibilit\u00e9 de servir vos utilisateurs avec une interface utilisateur personnalis\u00e9e en fonction de leur profil et de leurs exigences.<\/p>\n Trois technologies fondamentales sont utilis\u00e9es 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-\u00e0-dire qu’il contr\u00f4le son comportement lorsque les utilisateurs interagissent avec lui). En plus de ces trois technologies, vous pouvez utiliser n’importe quel type de framework<\/a> pour faciliter votre d\u00e9veloppement. Parmi les frameworks frontend courants, citons Laravel<\/a>, React, NextJS, Vue, GatsbyJS, etc.<\/p>\n La couche m\u00e9tier est charg\u00e9e de contenir et de g\u00e9rer la logique de fonctionnement de votre application. Il s’agit g\u00e9n\u00e9ralement d’un service backend qui accepte les requ\u00eates du client et les traite. Elle contr\u00f4le ce \u00e0 quoi l’utilisateur peut acc\u00e9der et d\u00e9termine comment l’infrastructure est utilis\u00e9e pour servir les requ\u00eates des utilisateurs.<\/p>\n Dans le cas d’une application de r\u00e9servation d’h\u00f4tel, votre application client sert de portail pour que les utilisateurs puissent saisir les noms des h\u00f4tels et d’autres donn\u00e9es pertinentes. Cependant, d\u00e8s que l’utilisateur clique sur le bouton de recherche, la couche m\u00e9tier re\u00e7oit la requ\u00eates et lance la logique de recherche des chambres d’h\u00f4tel disponibles qui correspondent \u00e0 vos exigences. Le client re\u00e7oit alors simplement une liste de chambres d’h\u00f4tel sans savoir comment cette liste a \u00e9t\u00e9 g\u00e9n\u00e9r\u00e9e ni m\u00eame pourquoi les \u00e9l\u00e9ments de la liste sont dispos\u00e9s de la mani\u00e8re dont ils ont \u00e9t\u00e9 envoy\u00e9s.<\/p>\n La pr\u00e9sence d’une telle couche garantit que votre logique m\u00e9tier n’est pas expos\u00e9e \u00e0 votre client et, en fin de compte, aux utilisateurs. L’isolement de la logique m\u00e9tier est d’une aide pr\u00e9cieuse pour les op\u00e9rations sensibles telles que le traitement des paiements ou la gestion des dossiers m\u00e9dicaux.<\/p>\n La couche de persistance est charg\u00e9e de contr\u00f4ler l’acc\u00e8s \u00e0 vos stockages de de donn\u00e9es. Elle agit comme une couche d’abstraction suppl\u00e9mentaire entre vos stockages de donn\u00e9es et votre couche m\u00e9tier. Elle re\u00e7oit tous les appels li\u00e9s aux donn\u00e9es en provenance des couches m\u00e9tier et les traite en \u00e9tablissant des connexions s\u00e9curis\u00e9es avec la base de donn\u00e9es.<\/p>\n Cette couche consiste g\u00e9n\u00e9ralement en un serveur de base de donn\u00e9es<\/a>. Vous pouvez mettre en place cette couche vous-m\u00eame en provisionnant une base de donn\u00e9es et un serveur de base de donn\u00e9es dans votre infrastructure sur site ou opter pour une solution distante\/g\u00e9r\u00e9e par l’un des principaux fournisseurs d’infrastructure dans le cloud comme AWS, GCP, Microsoft Azure, etc.<\/p>\n Maintenant que vous comprenez ce qui entre dans l’architecture d’une application web, examinons en d\u00e9tail chacun des composants qui composent une application web. Nous regrouperons cette discussion en deux grandes rubriques : les composants c\u00f4t\u00e9 serveur et les composants c\u00f4t\u00e9 client, ou les composants backend et frontend<\/a>.<\/p>\n Les composants c\u00f4t\u00e9 serveur sont ceux qui r\u00e9sident dans le backend de votre application web. Ils ne sont pas expos\u00e9s directement aux utilisateurs et contiennent la logique commerciale et les ressources les plus importantes de votre application web.<\/p>\n Le DNS est charg\u00e9 de contr\u00f4ler la mani\u00e8re dont votre application est expos\u00e9e au web. Les enregistrements DNS sont utilis\u00e9s par les clients HTTP, qui peuvent aussi \u00eatre des navigateurs, pour trouver et envoyer des requ\u00eates aux composants de votre application. Le DNS est \u00e9galement utilis\u00e9 par vos clients frontend en interne pour r\u00e9soudre l’emplacement de vos serveurs web et des points de terminaison API afin d’envoyer des requ\u00eates et de traiter les op\u00e9rations des utilisateurs.<\/p>\n L’\u00e9quilibrage de charge est un autre composant populaire de l’architecture des applications web. Un \u00e9quilibreur de charge est utilis\u00e9 pour distribuer les requ\u00eates HTTP entre plusieurs serveurs web identiques. L’intention derri\u00e8re la pr\u00e9sence de plusieurs serveurs web est de maintenir la redondance qui aide \u00e0 augmenter la tol\u00e9rance aux pannes ainsi qu’\u00e0 distribuer le trafic pour maintenir une haute performance.<\/p>\n Les points de terminaison API sont utilis\u00e9s pour exposer les services backend \u00e0 l’application frontend. Ils permettent de faciliter la communication entre le client et le serveur, et parfois m\u00eame entre plusieurs serveurs.<\/p>\n Le stockage des donn\u00e9es est une partie cruciale de la plupart des applications modernes, car il y a toujours des donn\u00e9es d’application qui doivent \u00eatre conserv\u00e9es \u00e0 travers les sessions des utilisateurs. Le stockage des donn\u00e9es est de deux types :<\/p>\n La mise en cache est une fonction facultative souvent mise en \u0153uvre dans les architectures d’applications web pour servir le contenu plus rapidement aux utilisateurs. Une grande partie du contenu des applications est souvent r\u00e9p\u00e9titive pendant un certain temps, voire toujours. Au lieu d’y acc\u00e9der depuis un stockage de donn\u00e9es et de le traiter avant de le renvoyer \u00e0 l’utilisateur, il est souvent mis en cache. Voici les deux types de mise en cache les plus populaires utilis\u00e9s dans les applications web :<\/p>\n Outre l’exposition d’une interface aux utilisateurs (frontend) et le traitement de leurs requ\u00eates (backend), il existe une autre cat\u00e9gorie de composants d’applications web un peu moins populaire. Les travaux sont souvent des services d’arri\u00e8re-plan destin\u00e9s \u00e0 accomplir des t\u00e2ches qui ne sont pas sensibles au temps ou synchrones.<\/p>\n Les travaux CRON sont ceux qui sont ex\u00e9cut\u00e9s sur une p\u00e9riode de temps fixe, encore et encore. Ces t\u00e2ches sont planifi\u00e9es sur le backend pour ex\u00e9cuter automatiquement des routines de maintenance \u00e0 des moments pr\u00e9cis. Parmi les exemples de cas d’utilisation courants, citons la suppression des doublons\/anciens enregistrements de la base de donn\u00e9es, l’envoi d’e-mails de rappel aux clients, etc.<\/p>\n Les composants c\u00f4t\u00e9 client sont ceux qui sont expos\u00e9s \u00e0 vos utilisateurs, directement ou indirectement.<\/p>\n Il existe principalement deux types de composants dans cette cat\u00e9gorie.<\/p>\n 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\u00e9der \u00e0 vos services.<\/p>\n L’interface frontend est principalement construite sur trois technologies populaires : HTML, CSS et JavaScript<\/a>. L’interface utilisateur frontend peut \u00eatre une application en soi avec son propre cycle de vie de d\u00e9veloppement logiciel.<\/p>\n Ces interfaces utilisateur n’abritent pas une grande partie de votre logique commerciale puisqu’elles sont expos\u00e9es directement \u00e0 vos utilisateurs. Si un utilisateur malveillant tente de d\u00e9sosser votre application frontend, il peut obtenir des informations sur le fonctionnement de votre entreprise et mener des activit\u00e9s ill\u00e9gales telles que l’usurpation d’identit\u00e9<\/a> et le vol de donn\u00e9es.<\/p>\n En outre, puisque l’interface utilisateur frontend est expos\u00e9e directement aux utilisateurs, vous voudrez l’optimiser pour un temps de chargement et une r\u00e9activit\u00e9 minimaux<\/a>. Cela peut parfois vous aider \u00e0 offrir une meilleure exp\u00e9rience \u00e0 vos utilisateurs, augmentant ainsi la croissance de votre entreprise.<\/p>\n Parfois, vous pouvez avoir besoin de stocker une certaine logique commerciale sur votre client afin d’effectuer rapidement des op\u00e9rations plus simples. La logique c\u00f4t\u00e9 client qui r\u00e9side habituellement dans votre application frontend peut vous aider \u00e0 \u00e9viter le voyage vers le serveur et \u00e0 offrir \u00e0 vos utilisateurs une exp\u00e9rience plus rapide.<\/p>\n Il s’agit d’une fonctionnalit\u00e9 facultative des composants c\u00f4t\u00e9 client. Dans certains cas, la logique d’entreprise de l’application est enti\u00e8rement stock\u00e9e c\u00f4t\u00e9 client (notamment lors de la construction sans serveur backend traditionnel<\/a>). Les solutions modernes telles que BaaS vous permettent d’acc\u00e9der \u00e0 des op\u00e9rations courantes telles que l’authentification, le stockage de donn\u00e9es, le stockage de fichiers, etc., en cours de route dans votre application frontend.<\/p>\n Il existe des moyens d’obscurcir ou de minifier ce code<\/a> avant de le d\u00e9ployer aupr\u00e8s de vos utilisateurs afin de minimiser les risques de r\u00e9tro-ing\u00e9nierie.<\/p>\n Il existe plusieurs mod\u00e8les d’architectures d’applications web, chacun bas\u00e9 sur la fa\u00e7on dont les serveurs web se connectent \u00e0 leurs stockages de donn\u00e9es.<\/p>\n Le mod\u00e8le le plus simple de tous est celui d’un serveur web se connectant \u00e0 une instance de base de donn\u00e9es. Un tel mod\u00e8le est facile \u00e0 mettre en \u0153uvre et \u00e0 maintenir, et sa mise en production est \u00e9galement assez ais\u00e9e.<\/p>\n En raison de sa simplicit\u00e9, ce mod\u00e8le convient \u00e0 l’apprentissage et aux petites applications exp\u00e9rimentales qui ne seront pas expos\u00e9es \u00e0 un trafic \u00e9lev\u00e9. Les d\u00e9veloppeurs novices peuvent facilement mettre en place et bricoler ces applications pour apprendre les principes fondamentaux du d\u00e9veloppement d’applications web<\/a>.<\/p>\n Cependant, ce mod\u00e8le ne devrait pas \u00eatre utilis\u00e9 en production car il est tr\u00e8s peu fiable. Un probl\u00e8me dans le serveur ou la base de donn\u00e9es peut entrainer un temps d’arr\u00eat et une perte d’activit\u00e9.<\/p>\n Ce mod\u00e8le fait monter l’application d’un cran en mettant en place plusieurs serveurs pour la redondance avec une seule instance de base de donn\u00e9es commune.<\/p>\n \u00c9tant donn\u00e9 que plusieurs serveurs web acc\u00e8dent simultan\u00e9ment \u00e0 la base de donn\u00e9es, des probl\u00e8mes d’incoh\u00e9rence peuvent survenir. Pour \u00e9viter cela, les serveurs web sont con\u00e7us pour \u00eatre sans \u00e9tat. Cela signifie que les serveurs ne conservent pas les donn\u00e9es entre les sessions ; ils se contentent de les traiter et de les stocker dans la base de donn\u00e9es.<\/p>\n Les applications r\u00e9alis\u00e9es \u00e0 l’aide de ce mod\u00e8le sont certainement plus fiables que celles du mod\u00e8le pr\u00e9c\u00e9dent, car la pr\u00e9sence de plusieurs serveurs web ajoute de la tol\u00e9rance aux pannes de l’application web. Toutefois, comme la base de donn\u00e9es est toujours une instance commune, elle constitue le maillon faible de l’architecture et peut \u00eatre une source de d\u00e9faillance.<\/p>\n Ce mod\u00e8le est l’un des mod\u00e8les les plus courants et traditionnels de conception d’applications web.<\/p>\n Dans ce cas, d\u00e9ployez la logique de votre application sous la forme de plusieurs instances de serveurs web identiques regroup\u00e9es derri\u00e8re un \u00e9quilibreur de charge. Votre stockage de donn\u00e9es est \u00e9galement maintenu sur plusieurs instances de base de donn\u00e9es pour une tol\u00e9rance accrue aux pannes.<\/p>\n Vous pouvez \u00e9galement choisir de r\u00e9partir votre base de donn\u00e9es entre les instances disponibles pour am\u00e9liorer les performances ou de maintenir des doubles de l’ensemble du stockage de donn\u00e9es pour la redondance. Dans les deux cas, la d\u00e9faillance d’une instance de votre base de donn\u00e9es n\u2019entrainera pas l’interruption compl\u00e8te de l’application.<\/p>\n Ce mod\u00e8le est tr\u00e8s appr\u00e9ci\u00e9 pour sa fiabilit\u00e9 et son \u00e9volutivit\u00e9. Toutefois, le d\u00e9veloppement et la maintenance d’applications utilisant ce mod\u00e8le sont relativement compliqu\u00e9s et n\u00e9cessitent des d\u00e9veloppeurs chevronn\u00e9s et co\u00fbteux<\/a>. En tant que tel, ce mod\u00e8le n’est sugg\u00e9r\u00e9 que lorsque vous construisez \u00e0 grande \u00e9chelle.<\/p>\n Si les trois mod\u00e8les mentionn\u00e9s ci-dessus sont bien adapt\u00e9s aux applications monolithiques, il existe un autre mod\u00e8le pour les applications modulaires.<\/p>\n Le mod\u00e8le des services d’application d\u00e9compose une application en modules plus petits bas\u00e9s sur la fonctionnalit\u00e9 commerciale. Ces modules peuvent \u00eatre aussi petits qu’une fonction ou aussi grands qu’un service.<\/p>\n L’id\u00e9e ici est de rendre chaque fonctionnalit\u00e9 m\u00e9tier ind\u00e9pendante et \u00e9volutive. Chacun de ces modules peut se connecter \u00e0 la base de donn\u00e9es de mani\u00e8re autonome. Vous pouvez m\u00eame avoir des instances de base de donn\u00e9es d\u00e9di\u00e9es pour r\u00e9pondre aux besoins d’\u00e9volutivit\u00e9 de votre module.<\/p>\n Parmi les applications non monolithiques, ce mod\u00e8le est assez populaire. Les anciennes applications monolithiques sont souvent migr\u00e9es vers ce mod\u00e8le pour profiter de ses avantages en termes d’\u00e9volutivit\u00e9 et de modularit\u00e9. Cependant, la gestion des applications construites sur un tel mod\u00e8le n\u00e9cessite souvent des d\u00e9veloppeurs chevronn\u00e9s<\/a>, notamment une exp\u00e9rience en DevOps et CI\/CD.<\/p>\n Voici quelques bonnes pratiques que vous pouvez mettre en \u0153uvre dans votre projet d’application web pour tirer le meilleur parti de l’architecture d’application web que vous avez choisie.<\/p>\n On ne le dira jamais assez : Visez toujours des frontends responsives<\/a>. Quelle que soit l’ampleur et la complexit\u00e9 de votre application web en interne, tout est expos\u00e9 \u00e0 vos utilisateurs via des pages web, des applications et des \u00e9crans frontend.<\/p>\n Si vos utilisateurs trouvent ces \u00e9crans peu intuitifs ou lents, ils ne resteront pas assez longtemps pour voir et admirer la merveille d’ing\u00e9nierie qu’est votre application web.<\/p>\n Par cons\u00e9quent, il est tr\u00e8s important de concevoir des frontends accessibles, faciles \u00e0 utiliser et l\u00e9gers.<\/p>\n Il existe de nombreuses meilleures pratiques UI\/UX<\/a> disponibles sur le web pour vous aider \u00e0 comprendre ce qui fonctionne le mieux pour vos utilisateurs. Vous pouvez trouver des professionnels comp\u00e9tents pour r\u00e9aliser des conceptions et des architectures conviviales qui permettront \u00e0 vos utilisateurs de tirer le meilleur parti de vos applications.<\/p>\n Nous vous conseillons de r\u00e9fl\u00e9chir s\u00e9rieusement \u00e0 la r\u00e9activit\u00e9 de votre frontend avant de d\u00e9ployer votre produit aupr\u00e8s de vos utilisateurs.<\/p>\n En plus d’\u00eatre faciles \u00e0 comprendre, vos interfaces publiques doivent \u00e9galement \u00eatre rapides \u00e0 charger<\/a>.<\/p>\n Selon Portent<\/a>, les taux de conversion eCommerce les plus \u00e9lev\u00e9s se produisent sur les pages dont le temps de chargement est compris entre 0 et 2 secondes, et selon Unbounce<\/a>, environ 70 % des consommateurs admettent que le temps de chargement des pages est un facteur important dans leur choix d’acheter aupr\u00e8s d’un vendeur en ligne.<\/p>\n Lorsque vous concevez des applications natives mobiles, vous ne pouvez g\u00e9n\u00e9ralement pas \u00eatre certain des sp\u00e9cifications de l’appareil de vos utilisateurs. Tout appareil qui ne r\u00e9pond pas aux exigences de votre application est g\u00e9n\u00e9ralement d\u00e9clar\u00e9 comme ne supportant pas l’application.<\/p>\n Cependant, il en va tout autrement avec le web.<\/p>\n Lorsqu’il s’agit d’applications web, vos utilisateurs peuvent utiliser n’importe quoi, du dernier Macbook M1 Pros d’Apple aux t\u00e9l\u00e9phones Blackberry et Nokia vintage, pour visualiser votre application. Optimiser votre exp\u00e9rience frontend pour un tel \u00e9ventail d’utilisateurs peut parfois \u00eatre difficile.<\/p>\n Des services comme LightHouse et Google PageSpeed<\/a> viennent \u00e0 l’esprit lorsqu’on parle de performances d’interfaces publiques. Vous devriez utiliser ces outils<\/a> pour \u00e9valuer votre application frontend avant de la d\u00e9ployer en production. La plupart de ces outils vous fournissent une liste de conseils pratiques pour vous aider \u00e0 am\u00e9liorer les performances de votre application autant que possible.<\/p>\n Les derniers 5 \u00e0 10 % des performances de l’application sont g\u00e9n\u00e9ralement sp\u00e9cifiques \u00e0 votre cas d’utilisation et ne peuvent \u00eatre corrig\u00e9s que par quelqu’un qui connait bien votre application et ses technologies. Cela ne fait jamais de mal d’investir dans les performances web<\/a> !<\/p>\n Comme nous l’avons vu pr\u00e9c\u00e9demment, les PWA sont les designs de l’avenir. Elles s’adaptent bien \u00e0 la plupart des cas d’utilisation et offrent l’exp\u00e9rience la plus uniforme sur les principales plates-formes.<\/p>\n Vous devriez envisager d’utiliser les PWA pour votre application aussi souvent que possible. L’exp\u00e9rience native sur le web et le mobile a un impact consid\u00e9rable sur vos utilisateurs et peut \u00e9galement r\u00e9duire votre propre charge de travail.<\/p>\n Les PWA sont \u00e9galement rapides \u00e0 charger, faciles \u00e0 optimiser et rapides \u00e0 construire. Opter pour les PWA peut vous aider \u00e0 d\u00e9placer une grande partie de votre attention du d\u00e9veloppement vers les affaires d\u00e8s le d\u00e9but.<\/p>\n Une base de code propre peut vous aider \u00e0 rep\u00e9rer et \u00e0 r\u00e9soudre la plupart des probl\u00e8mes avant qu’ils ne causent des d\u00e9g\u00e2ts. Voici quelques conseils que vous pouvez suivre pour vous assurer que votre base de code ne vous cause pas plus de probl\u00e8mes qu’il ne devrait.<\/p>\n CI\/CD est l’abr\u00e9viation de Continuous Integration\/Continuous Deployment (int\u00e9gration continue\/d\u00e9ploiement continu). Les processus CI\/CD sont cruciaux pour le d\u00e9veloppement de votre application car ils vous aident \u00e0 construire, tester et d\u00e9ployer votre projet en toute simplicit\u00e9.<\/p>\n Cependant, vous ne voulez pas avoir \u00e0 les ex\u00e9cuter manuellement \u00e0 chaque fois. Vous devriez plut\u00f4t mettre en place des pipelines qui se d\u00e9clenchent automatiquement en fonction des activit\u00e9s de votre projet. Par exemple, vous pourriez mettre en place un pipeline qui ex\u00e9cute vos tests automatiquement chaque fois que vous livrez votre code \u00e0 votre syst\u00e8me de contr\u00f4le de version<\/a>. Il existe \u00e9galement de nombreux cas d’utilisation plus complexes, comme la g\u00e9n\u00e9ration d’artefacts multiplateformes \u00e0 partir de votre d\u00e9p\u00f4t de code chaque fois qu’une version est cr\u00e9\u00e9e.<\/p>\n Les possibilit\u00e9s sont infinies, il ne tient qu’\u00e0 vous de trouver comment tirer le meilleur parti de vos pipelines CI\/CD.<\/p>\n La plupart des applications modernes sont constitu\u00e9es de plusieurs composants. Prenez l’application suivante comme exemple :<\/p>\n Les requ\u00eates des clients sont achemin\u00e9es 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, \u00e0 l’avenir, permettre l’acc\u00e8s \u00e0 davantage de composants sans passer par le module d’accueil.<\/p>\n Ensuite, le module d’accueil v\u00e9rifie un BaaS d’authentification externe avant d’autoriser l’acc\u00e8s. Une fois authentifi\u00e9, le client peut acc\u00e9der aux pages \u00ab Mettre \u00e0 jour le profil \u00bb ou \u00ab Voir le profil \u00bb. Ces deux pages interagissent avec une solution de base de donn\u00e9es commune et g\u00e9r\u00e9e qui traite les donn\u00e9es du profil.<\/p>\n Comme vous pouvez le constater, l’application ressemble \u00e0 une version tr\u00e8s basique et minimale d’un annuaire de personnes en ligne<\/a>. Vous pouvez ajouter\/mettre \u00e0 jour votre propre profil ou consulter les autres profils disponibles.<\/p>\n Voici une rapide l\u00e9gende des diff\u00e9rents composants de l’architecture :<\/p>\n Les composants de chacune des couleurs ci-dessus sont vuln\u00e9rables \u00e0 divers types de menaces de s\u00e9curit\u00e9. Voici quelques constructions de s\u00e9curit\u00e9 que vous pouvez mettre en place pour minimiser votre exposition :<\/p>\n Bien qu’il ne s’agisse que de quelques suggestions, elles d\u00e9montrent que la s\u00e9curit\u00e9 des applications est complexe et qu’il est de votre responsabilit\u00e9 de vous assurer que vous ne laissez aucune marge de man\u0153uvre aux attaquants. Vous ne pouvez pas compter sur un composant de s\u00e9curit\u00e9 central pour prot\u00e9ger votre entreprise ; la s\u00e9curit\u00e9 des applications est r\u00e9partie sur l’ensemble de votre architecture d’applications.<\/p>\n Le retour d’information des utilisateurs<\/a> est un outil crucial pour comprendre l’efficacit\u00e9 de votre application en termes de performances commerciales et techniques. Vous pouvez construire l’application la plus l\u00e9g\u00e8re et la plus fluide du monde, mais si elle ne permet pas \u00e0 vos utilisateurs de faire ce qu’ils attendent, tous vos efforts seront r\u00e9duits \u00e0 n\u00e9ant.<\/p>\n Il existe de multiples fa\u00e7ons de recueillir les commentaires des utilisateurs. Si une enqu\u00eate rapide et anonyme<\/a> est l’approche classique, vous pouvez \u00e9galement opter pour une solution plus sophistiqu\u00e9e, comme une carte thermique de l’activit\u00e9 de vos utilisateurs.<\/p>\n![\"Diagramme](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/10\/web-app-architecture-components.jpg\")
Pourquoi l’architecture d’application web est-elle importante ?<\/h2>\n
Adaptation ais\u00e9e aux besoins de l’entreprise<\/h3>\n
D\u00e9veloppement organis\u00e9<\/h3>\n
Meilleure gestion de la base de code<\/h3>\n
S\u00e9curit\u00e9 renforc\u00e9e<\/h3>\n
Comment fonctionne l’architecture d’application web ?<\/h2>\n
\n
\n
Types d’architecture d’application web<\/h2>\n
Architecture \u00e0 page unique<\/h3>\n
Les avantages de l’architecture SPA<\/h4>\n
\n
Inconv\u00e9nients de l’architecture SPA<\/h4>\n
\n
Architecture d’application web progressive<\/h3>\n
Les avantages de l’architecture PWA<\/h4>\n
\n
Inconv\u00e9nients de l’architecture PWA<\/h4>\n
\n
Architecture \u00e0 rendu c\u00f4t\u00e9 serveur<\/h3>\n
Avantages de l’architecture SSR<\/h4>\n
\n
Inconv\u00e9nients de l’architecture SSR<\/h4>\n
\n
Architecture d’applications pr\u00e9-rendues<\/h3>\n
https:\/\/myapp.com\/search\/foo+bar<\/code>), vous \u00eates au mauvais endroit.<\/p>\nAvantages de l’architecture pr\u00e9-rendue<\/h4>\n
\n
Inconv\u00e9nients de l’architecture pr\u00e9-rendue<\/h4>\n
\n
Architecture d’application isomorphe<\/h3>\n
Les avantages de l’architecture isomorphe<\/h4>\n
\n
Inconv\u00e9nients de l’architecture isomorphe<\/h4>\n
\n
Architecture orient\u00e9e services<\/h3>\n
Les avantages de l’architecture orient\u00e9e services<\/h4>\n
\n
Les inconv\u00e9nients de l’architecture orient\u00e9e services<\/h4>\n
\n
L’architecture micro-services<\/h3>\n
Avantages de l’architecture micro-services<\/h4>\n
\n
Inconv\u00e9nients de l’architecture micro-services<\/h4>\n
\n
Architecture sans serveur<\/h3>\n
Les avantages de l’architecture sans serveur<\/h4>\n
\n
Inconv\u00e9nients de l’architecture sans serveur<\/h4>\n
\n
Couches de l’architecture d’application web<\/h2>\n
Couche de pr\u00e9sentation<\/h3>\n
Couche m\u00e9tier<\/h3>\n
Couche de persistance<\/h3>\n
Composants de l’application web<\/h2>\n
Composants c\u00f4t\u00e9 serveur<\/h3>\n
DNS et routage<\/h4>\n
Stockage des donn\u00e9es<\/h4>\n
\n
La mise en cache<\/h4>\n
\n
Les t\u00e2ches et les services<\/h4>\n
Composants c\u00f4t\u00e9 client<\/h3>\n
Interface utilisateur frontend<\/h4>\n
Logique d’entreprise c\u00f4t\u00e9 client<\/h4>\n
Mod\u00e8les de composants d’applications web<\/h3>\n
Un serveur, une base de donn\u00e9es<\/h4>\n
Plusieurs serveurs, une base de donn\u00e9es<\/h4>\n
Serveurs multiples, bases de donn\u00e9es multiples<\/h4>\n
Services d’applications<\/h4>\n
Meilleures pratiques pour l’architecture des applications web<\/h2>\n
1. Rendez votre frontend responsive<\/h3>\n
2. Surveillez les temps de chargement<\/h3>\n
3. Pr\u00e9f\u00e9rez les PWA chaque fois que c’est possible<\/h3>\n
4. Gardez votre base de code propre et succincte<\/h3>\n
\n
5. Automatisez vos processus CI\/CD<\/h3>\n
6. Incorporez des fonctions de s\u00e9curit\u00e9<\/h3>\n
![\"Exemple](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/09\/example-serverless-architecture.png\")
\n
\n
\n
\n
\n
\n
7. Collectez les commentaires des utilisateurs<\/h3>\n