Rendu côté serveur et motifs MVC

Le Web est passé de sa phase 1.0, où l'utilisation principale était la visualisation de contenu composé de texte et d'images, à sa phase 2.0 d'interaction utilisateur. Au fur et à mesure de son évolution, trois technologies ont dominé le paysage de la programmation du Web, communément appelées la trifecta :

• langage de balisage hypertexte (HTML) (hypertext markup language (HTML)) : un langage de balisage standard utilisé pour décrire la structure et le contenu des pages web.
• feuilles de style en cascade (CSS) (cascading style sheets (CSS)) : un langage de feuilles de style standard utilisé pour modifier le style de présentation du contenu trouvé en HTML (ou d'autres langages de balisage).
• JavaScript (JS) : un langage de script qui ajoute de l'interactivité au contenu web et des fonctionnalités côté serveur. Divers autres langages de script et approches concurrentes ont été utilisés avant l'adoption de JavaScript.

L'adoption du HTML était déjà acquise sur le Web, et avec l'introduction des CSS en 1996, une impulsion plus forte pour la séparation du contenu et du style a été introduite afin que le style du contenu puisse être spécifié uniquement dans les feuilles de style plutôt que dans les balises HTML. Les pages web à cette époque consistaient principalement en du contenu statique, qui était généré et livré sur le serveur web. Essentiellement, l'utilisateur sélectionnait une action dans son navigateur qui envoyait une requête HTTP au serveur, comme suit :

• En cliquant sur un hyperlien sur une page web, le navigateur envoyait une requête HTTP GET au serveur web. Cette requête demandait une ressource spécifique (telle qu'une page web ou une image), et le serveur répondait en renvoyant les données demandées au navigateur.
• En remplissant un formulaire sur une page web et en cliquant sur le bouton de soumission, le navigateur envoyait une requête HTTP POST au serveur. Cette requête incluait les données saisies (comme un nom d'utilisateur et un mot de passe), et le serveur les traitait et répondait en conséquence.

Essentiellement, le serveur web effectuait tout le rendu du contenu HTML côté serveur, et le client (navigateur web) présentait ce qu'il recevait. Le navigateur dans ce modèle agit comme un client léger, car il a une fonctionnalité minimale. La Figure 11.4 illustre les composants d'une architecture Web 2.0 traditionnelle utilisant des technologies basées sur Java. Remarquez le changement dans l'interaction de l'utilisateur avec le site web par rapport à un site web Web 1.0. Notez également que les utilisateurs peuvent interagir avec des applications via un serveur d'applications qui peut récupérer des données d'une base de données ou d'un système de fichiers. Cela permet de prendre en charge la gestion des sessions web qui autorisent la navigation entre plusieurs pages.

Figure 11.4 Ceci illustre l'interaction d'un utilisateur avec une architecture Web 2.0 traditionnelle. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

De nombreuses applications web originales étaient sans état, ce qui signifie que les requêtes précédentes n'avaient aucune incidence sur les requêtes futures. Par exemple, il n'était pas possible de créer un panier d'achat dans le cadre d'une session web qui suivrait la session et ce qui a été acheté sur un site, et maintiendrait l'état (c'est-à-dire le contenu dans ce cas) du panier. En revanche, une application avec état (stateful application) est un logiciel qui maintient l'état d'une application au fil du temps, tandis que dans le cas d'une application sans état (stateless application), l'état n'est pas maintenu par le système et les actions précédentes n'ont pas d'impact sur les actions futures. Les applications sans état sont plus simples et plus faciles à implémenter et à maintenir, mais offrent des fonctionnalités limitées.

Comme mentionné précédemment, le Web 2.0 a été en partie motivé par la demande des utilisateurs pour des fonctionnalités plus interactives. L'interactivité nécessite le maintien d'un certain état (par exemple, la session web et le contenu du panier, comme dans l'exemple précédent), augmentant ainsi la complexité du système. Cela a accru les exigences sur le serveur web pour presque tout le traitement nécessaire à la génération et à la présentation du contenu du site web. L'augmentation des fonctionnalités a conduit à des systèmes plus complexes, et une séparation claire des responsabilités entre le rendu du site web, la logique métier (c'est-à-dire la logique implémentée dans l'application web) et les couches de persistance était nécessaire pour améliorer la qualité et les performances du site web tout en tirant parti de l'expertise en ingénierie dans des domaines donnés.

Comme vous l'avez appris au Chapitre 10 Gestion des architectures d'entreprise et de solution, le patron Modèle-Vue-Contrôleur est conçu pour aborder cette séparation des responsabilités. Dans le patron MVC, le Modèle est la couche de persistance responsable du stockage et de la récupération des données. Il possède une API bien définie que le Contrôleur utilise. La vue (View) est la couche de présentation qui gère l'interface utilisateur. Enfin, le Contrôleur agit comme la couche de logique métier qui effectue le traitement et applique les règles pour générer le contenu applicable dans un domaine d'application donné et sépare l'interface utilisateur des données. Il possède également une API bien définie que la Vue comprend. Le concept de conception de bonne pratique utilisé pour créer des systèmes logiciels de manière à assurer des associations faibles avec d'autres composants est appelé couplage faible (loose coupling). Ce concept permet la séparation des préoccupations entre les composants, ce qui conduit au maintien d'une forte cohésion au sein des fonctionnalités des sites web. Les composants MVC sont faiblement couplés en ce sens que les différents composants peuvent interagir les uns avec les autres pour accéder aux fonctionnalités spécifiques fournies par chaque composant. Une forte cohésion garantit que tout ce qui est nécessaire pour fournir une fonctionnalité spécifique est inclus dans l'un des composants. Par exemple, sur un site web bancaire, les fonctionnalités de dépôts et de retraits peuvent être colocalisées sur le serveur au sein du même composant pour assurer une forte cohésion ; cependant, les fonctionnalités de demande de prêt peuvent être situées dans un autre composant. Trois cadriciels d'applications web côté serveur populaires qui ont implémenté le patron MVC étaient Apache Struts, ASP.NET et Ruby on Rails.

Le côté serveur exécute la majorité des fonctionnalités. Il utilise une combinaison de HTML à gabarits, de technologies de contrôleur et de serveur d'applications (par exemple, ASP.NET, C#) et de SQL. JavaScript est envoyé au navigateur en utilisant jQuery pour la prise en charge multi-navigateurs, ou il peut utiliser Asynchronous JavaScript and XML pour communiquer avec le serveur web sans rafraîchir la page. JavaScript et XML asynchrones (AJAX) (Asynchronous JavaScript and XML (AJAX)) échange de petites quantités de données entre un client et un serveur. L'équipe d'ingénierie utilisant une telle plateforme web doit comprendre et faire respecter la séparation des responsabilités entre les composants MVC pour s'assurer que les modifications futures, en particulier les changements significatifs, peuvent être effectuées sans réarchitecturer le système. Parce que l'équipe d'ingénierie doit connaître différents langages de programmation pour différentes couches, il peut y avoir une certaine résistance interne à cela, et il peut être tentant de contourner une couche pour apporter une solution rapide. Essentiellement, s'assurer que l'architecture de la plateforme web est comprise et utilisée correctement, l'adhérence architecturale est basée sur l'expertise des membres de l'équipe d'ingénierie et davantage sur la nature des outils utilisés.

Applications Web 2.0 adaptatives

Au milieu des années 2000, JavaScript est devenu populaire pour les fonctionnalités côté client des navigateurs. Les technologies AJAX et jQuery ont permis aux développeurs de créer des applications monopages (SPA). Pour l'utilisateur final, les SPA offraient des fonctionnalités similaires à celles d'une application de bureau traditionnelle et amélioraient considérablement l'expérience utilisateur en réduisant la latence. Les requêtes coûteuses au serveur web, qui entraînaient des rafraîchissements complets de page dans le navigateur, n'étaient plus nécessaires. Au lieu de cela, de petites transmissions de données pouvaient être envoyées et reçues entre le navigateur et le serveur via AJAX. La Figure 11.5 compare le cycle de vie des SPA à celui d'une application Web 2.0 traditionnelle.

Figure 11.5 Ceci est une comparaison des cycles de vie entre les applications Web 2.0 traditionnelles et les SPA. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

jQuery, une bibliothèque JavaScript à code source ouvert, a garanti que les développeurs web pouvaient écrire du JavaScript pour un modèle objet de document (DOM) de navigateur générique qui fonctionnerait quel que soit le navigateur de l'utilisateur. Le DOM est une interface de programmation fournie par les navigateurs. Il permet aux scripts, écrits en JavaScript par exemple, d'interagir avec la structure d'une page web. Lorsqu'une page web est chargée dans le navigateur, le navigateur crée un DOM de la page. La structure du DOM est une structure hiérarchique arborescente qui organise les éléments de la page en tant qu'objets. Le modèle utilisé par le DOM permet un accès dynamique et facilite la manipulation du contenu, de la structure et du style des pages web. La Figure 11.6 illustre une architecture SPA typique où une seule page web est livrée au navigateur. Notez que dans ce modèle, l'interaction de l'utilisateur avec le site a augmenté en termes de quantité de contenu généré par l'utilisateur.

Figure 11.6 Ceci illustre l'interaction d'un utilisateur avec une application monopage (SPA). (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Les SPA plus sophistiquées nécessitaient de grandes quantités de JavaScript côté client. De nombreux utilisateurs finaux avaient des machines sous-puissantes ou des navigateurs web obsolètes, et les SPA fonctionnaient mal.

Au début des années 2010, des cadriciels d'applications web ont été introduits pour créer des applications web côté client complexes, performantes, offrant une expérience similaire à celle d'une application de bureau native, et plus faciles à créer pour les développeurs. Ces applications suivaient un patron Modèle-Vue-ViewModel (MVVM). La Figure 11.7 illustre la relation entre les composants Vue, ViewModel et Modèle.

Figure 11.7 Diverses liaisons de données, événements et actions se produisent entre les composants du patron Modèle-Vue-ViewModel. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Ce patron est similaire au patron MVC que nous avons précédemment exploré ; cependant, plusieurs différences clés existent. Voici quelques-unes des similitudes et des différences :

• La Vue est responsable de la présentation et n'interagit qu'avec le ViewModel. Ceci est similaire en termes de responsabilité au rôle de la Vue et à son interaction avec le Contrôleur dans le patron MVC. Ici, la Vue se lie aux fonctions et propriétés du ViewModel et reçoit des notifications sur les opérations et les changements de données. Elle n'interagit pas directement avec le Modèle.
• Le Modèle est similaire au Modèle dans le patron MVC et est responsable de la récupération et du stockage des données. Il ne sait rien du ViewModel.
• Le ViewModel est similaire au Contrôleur en ce sens qu'il découple la relation entre la Vue et le Modèle et gère la manipulation des données. Le ViewModel répond aux notifications du Modèle et enverra des événements à la Vue si nécessaire. Parce que la Vue se lie au ViewModel, le ViewModel ne sait rien de la Vue. Le ViewModel peut fonctionner avec un Modèle local dans le navigateur, un Modèle distant, ou les deux.

Contrairement au patron MVC précédent concernant le rendu côté serveur, le patron MVVM est exécuté entièrement côté client. Une API de transfert d'état représentationnel (REST) découple les composants Modèle et ViewModel côté client de la logique métier côté serveur et du magasin de persistance. Les API basées sur REST (également appelées RESTful) suivent le style architectural conçu pour le Web. Ces API utilisent le format de fichier Notation d'objet JavaScript (JSON) (JavaScript Object Notation (JSON)) qui représente les données sous forme d'informations attribut-valeur basées sur du texte. La Figure 11.8 illustre le patron MVVM tel qu'il s'applique à une SPA.

Figure 11.8 Ceci illustre le patron Modèle-Vue-ViewModel tel qu'appliqué à l'architecture SPA. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Comme vous pouvez le voir sur le diagramme, ce modèle est plus complexe que le patron MVC plus simple. La qualité des API détermine en partie l'efficacité de ce patron. Les API basées sur REST bénéficient d'être découvrables (c'est-à-dire que tous les URI d'API peuvent être trouvés à partir du nœud API racine) et devraient être versionnées (c'est-à-dire pour suivre les changements d'interfaces à des fins de compatibilité) afin que les mises à niveau ne cassent pas les utilisateurs d'API. Sans versioning d'API, le couplage entre le client et le serveur augmente (en raison du couplage sémantique et syntaxique), et les mises à niveau deviennent coûteuses. Similaire à une URL, un identifiant de ressource uniforme (URI) est une chaîne de caractères qui identifie une ressource sur le Web.

Malgré ces défauts, les premiers cadriciels basés sur le navigateur ont prouvé la valeur de la création d'applications riches côté client. Les standards web ont évolué, et de nouveaux cadriciels sont apparus qui adhéraient aux nouveaux standards et résolvaient de nombreux problèmes de leurs prédécesseurs. Les cadriciels SPA populaires incluent Angular, Ember.js, React et Vue.js. Ceux-ci sont souvent utilisés conjointement avec des outils côté serveur, créant une « pile complète » de technologies pour développer la solution. Une technologie côté serveur populaire dans cette pile est Node, un environnement d'exécution pour l'exécution de code JavaScript.

Les approches visant à minimiser les données transférées entre les API et le client pour réduire le trafic réseau ou simplifier l'accès aux données ont abouti à deux approches principales. L'une consistait à aplatir le modèle de données. Au lieu de renvoyer des données dans un format imbriqué (comme à partir d'une base de données relationnelle), les données renvoyées seraient « aplaties » en une série de paires clé-valeur, chacune résultant en une valeur de retour unique. Si la requête spécifique pouvait être faite, les données aplaties seraient préférées à la navigation dans les données imbriquées pour améliorer les performances. Cependant, la création d'API pour répondre à des requêtes spécifiques pourrait être difficile. Une autre solution consistait à utiliser GraphQL, un langage de requête et de manipulation à code source ouvert. Avec GraphQL, les appelants de son API pouvaient élaborer des requêtes spécifiques pour ne renvoyer que les données nécessaires, ce qui rendait l'accès à de nombreux services, tels que ceux fournis par les architectures de microservices, plus extensible.

Applications mobiles natives

Les applications mobiles natives sont conçues pour fonctionner sur des systèmes d'exploitation mobiles spécifiques (c'est-à-dire Android, iOS). Les systèmes d'exploitation Android et iOS dominent le marché des appareils mobiles. En 2023, Android détenait environ 70 % de la part de marché mondiale, avec iOS à environ 29 %. Samsung, KaiOS, Windows, Linux et d'autres constituent le 1 % restant du marché.2

Cependant, aux États-Unis en 2023, iOS était le système d'exploitation prédominant avec environ 61 % du marché et Android à 38 %. Ici, nous examinerons les spécificités du développement d'applications mobiles natives en nous concentrant sur Android et iOS.3

Applications Web 3.0

Le Web 3.0 est la prochaine phase du Web. Il est encore en cours de réalisation, et similaire aux Web 1.0 et 2.0, il ne peut être pleinement compris qu'avec le recul. La technologie et les utilisations du Web se chevauchent entre les phases, les phases plus récentes étant préférées à leurs phases précédentes. Si le Web 1.0 était le web en lecture seule, et le Web 2.0 le web de participation (écriture), alors le Web 3.0 pourrait être le web de lecture, écriture et exécution.

Tim Berners-Lee avait qualifié le Web 3.0 de Web sémantique (Semantic Web), un système d'agents autonomes, qui sont des programmes logiciels qui répondent à des événements. Ce modèle a évolué au fil des ans. Bien que l'IA (et d'autres technologies telles que la RA/RV) fera probablement partie du Web 3.0 ou du Web x.0, les principes qui régissent la prochaine phase devraient être centrés sur un web décentralisé, sans permission et fiable.

Le Web 3.0 voit un passage du modèle client-serveur plus traditionnel à un modèle de réseau pair à pair. Un réseau pair à pair est un réseau dans lequel les appareils se connectent et peuvent partager des données et des traitements sans avoir besoin d'un serveur centralisé. Les pairs dans ce schéma peuvent jouer le rôle d'un client traditionnel, d'un serveur, ou des deux. Ce changement favorisera un web fiable, décentralisé et ouvert, où les grandes entreprises ne possèdent pas les données, mais où chacun les possède collectivement. Des technologies telles qu'un contrat intelligent permettent un modèle fiable nécessaire dans un système décentralisé. L'intelligence artificielle et l'apprentissage automatique amélioreront l'accès à l'information en comprenant la signification du contenu disponible sur le Web. Les applications exemplaires de la phase Web 3.0 seront définies à l'avenir. Cependant, si les phases précédentes du Web sont une indication, cela changera fondamentalement la façon dont nous opérons dans un monde technologique en constante évolution.

Enfin, les applications Web 3.0 fonctionneront sur un web qui prend en charge les applications Web 1.0 et 2.0, le résultat probable étant des architectures hybrides qui sont partiellement Web 2.0 et 3.0.

Architectures d'applications Web 3.0

Les applications Web 3.0 sont architecturées sans serveur centralisé, elles sont donc considérées comme des applications décentralisées (DApps) (decentralized Apps (DApps)), qui sont des applications qui exécutent des contrats intelligents et fonctionnent sur une technologie de registre distribué (DLT). Les contrats intelligents sont des programmes qui peuvent être exécutés sur un registre distribué. Les registres distribués utilisent des nœuds de réseau indépendants pour enregistrer, partager et synchroniser les transactions dans leurs registres électroniques respectifs au lieu de les conserver sur un serveur centralisé. Le code est visible par toutes les parties, et la confiance est placée dans le code plutôt que dans un tiers centralisé. Les registres distribués consignent les transactions entre les comptes qui sont enregistrées à plusieurs endroits. La chaîne de blocs est un type de DLT.

Comparons une application Web 2.0 traditionnelle avec une DApp 3.0. Dans le Web 2.0, si vous créiez un site web permettant aux utilisateurs de publier des images et de faire des commentaires, vous auriez besoin de fonctionnalités pour authentifier les utilisateurs, autoriser leurs actions, générer une interface utilisateur pour ajouter des images, parcourir les images et publier des commentaires. Pour ce faire, vous auriez besoin d'un serveur web frontal et d'un traitement dorsal pour la logique métier et le stockage des données. Ces serveurs fonctionneraient dans le centre de données d'une entreprise ou chez un fournisseur de services infonuagiques. L'entreprise posséderait tout le code et les données, y compris les métadonnées sur la façon dont vous interagissez avec le site web (par exemple, ce que vous avez commenté, combien de temps vous avez regardé une image). Pour rappel, la Figure 11.4 illustre une architecture Web 2.0 traditionnelle (note : à nos fins, l'architecture SPA pourrait également être utilisée ici).

Dans une DApp Web 3.0, la fonctionnalité de création d'une application pour publier des images et les commenter resterait la même. Les principales différences seraient l'endroit où le code s'exécute et qui possède le code et les données. Décomposons cela en une série d'étapes qui s'éloignent d'une solution centralisée vers une solution distribuée.

Pour commencer, nous pouvons conserver le frontal du serveur web et remplacer le code dorsal par l'application distribuée. La chaîne de blocs Ethereum (Ethereum blockchain), par exemple, est une machine à états déterministe qui s'exécute sur un réseau pair à pair. Une machine à états déterministe possède un modèle de calcul qui repose sur un nombre fini d'états et de transitions entre eux pour répondre aux entrées. Elle garantit une seule transition d'un état à un autre en réponse à une entrée. Parce qu'elle est basée sur une machine à états déterministe, la chaîne de blocs Ethereum est souvent appelée un « ordinateur mondial » (world computer). Les transactions de la chaîne de blocs Ethereum sont des appels à des méthodes implémentées dans des contrats intelligents. Ces appels de méthode entraînent un changement des données (alias, état) qui est maintenu par les contrats au sein de la chaîne de blocs. La chaîne de blocs Ethereum enregistre les transactions dans des blocs qui sont ajoutés à sa chaîne de blocs. Les modifications de la machine à états elle-même (par exemple, la modification des structures de données de blocs ou de transactions utilisées dans la chaîne de blocs Ethereum) nécessitent un consensus entre les fournisseurs de nœuds qui prennent en charge le réseau de chaîne de blocs pair à pair. N'importe qui dans le monde peut lire ou écrire sur la machine — aucune autorité centrale ne la gouverne.

Les contrats intelligents forment le code et sont écrits dans des langages de haut niveau comme Solidity ou Vyper. Le code de contrat de haut niveau est compilé en bytecode qui peut être exécuté sur la Machine Virtuelle Ethereum (EVM). Chaque bloc contient un pointeur de hachage du bloc précédent, avec un horodatage et les données de transaction. Le pointeur de hachage inclut un hachage cryptographique (c'est-à-dire un condensat de taille fixe du bloc précédent qui permet de vérifier que le bloc précédent n'a pas été modifié depuis qu'il a été stocké dans la chaîne de blocs ; la partie cryptographique garantit que la valeur de hachage possède des propriétés spéciales et, en particulier, que les données originales ne peuvent pas être dérivées de la valeur de hachage).

La Figure 11.9 remplace les composants dorsaux traditionnels d'un site web par une chaîne de blocs. L'interaction de l'utilisateur avec le site web est cohérente avec un site web Web 2.0 traditionnel, car le traitement dorsal est caché à l'utilisateur, bien qu'il ait été remplacé par un nœud de chaîne de blocs.

Figure 11.9 Voici un site web Web 2.0 traditionnel avec des composants dorsaux remplacés par une DApp. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Dans la figure, le serveur web communique avec un nœud de la chaîne de blocs, appelé un nœud complet. Un nœud complet (full node) est un ordinateur qui maintient une copie de la chaîne de blocs et exécute le logiciel de la chaîne de blocs. L'exploitation d'un nœud complet peut devenir coûteuse car il faut fournir le matériel et payer des frais pour rejoindre le réseau Ethereum. Les utilisateurs finaux de la chaîne de blocs utilisent généralement un portefeuille logiciel tel que MetaMask pour accéder aux nœuds de la chaîne de blocs ou utilisent un portefeuille tiers proposé par des fournisseurs comme Infura, Alchemy ou QuickNode. MetaMask est une technologie de portefeuille qui stocke les clés privées d'un utilisateur dans son navigateur.

Les fournisseurs de chaînes de blocs utilisent la spécification JSON-RPC pour gérer la communication des clients/utilisateurs finaux. Cet appel de procédure distante (RPC) est léger et agnostique au transport.

Comme mentionné précédemment, tout client peut accéder à la chaîne de blocs via un fournisseur de portefeuille, ce qui nécessite la création d'un compte et l'obtention d'un identifiant de portefeuille. Une fois connectés à leurs portefeuilles, les clients peuvent effectuer des transactions de chaîne de blocs, qui finissent par lire et/ou écrire sur la chaîne de blocs et modifier l'état des contrats intelligents. L'identifiant du portefeuille est utilisé pour signer les transactions afin qu'elles puissent être tracées jusqu'au portefeuille client. Dans notre exemple, la navigation de photos sur l'application Web 3.0 est une transaction de lecture qui ne nécessiterait aucune signature ; cependant, l'ajout de photos et de commentaires en nécessiterait.

L'ajout de données à la chaîne de blocs entraîne un coût car les nœuds doivent maintenant stocker ces données. L'utilisateur supporte cette dépense. Imaginez payer chaque fois que vous téléchargez une photo sur votre application de médias sociaux préférée. Au lieu de stocker les données sur la chaîne de blocs, une approche rentable consisterait à stocker les données en utilisant le protocole InterPlanetary File System (IPFS). IPFS est un protocole de partage de fichiers distribué pair à pair. Vous pouvez passer par un fournisseur comme Pinata pour obtenir une valeur de hachage pour les données (c'est-à-dire un condensat de longueur fixe des données qui ne peut pas être utilisé pour obtenir les données originales) que vous téléchargez sur l'IPFS et stocker cette valeur de hachage dans la chaîne de blocs via une interface de contrat intelligent, réduisant ainsi le coût de stockage des données au sein de la chaîne de blocs.

La Figure 11.10 montre l'ajout de :

• le fournisseur entre le serveur web et la DApp
• un signataire pour quand l'utilisateur veut écrire dans l'application
• l'inclusion de l'IPFS pour le stockage des données

Figure 11.10 Cette architecture a ajouté un signataire, un fournisseur et IPFS. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Jusqu'à présent, nous avons conservé la logique frontale sur un serveur web hébergé dans un emplacement centralisé. C'est une bonne approche temporaire pour une organisation qui souhaite faire évoluer une solution existante vers une DApp au fil du temps. Étant donné qu'IPFS hébergera une partie des données de la DApp, déplaçons le HTML, le CSS et le JavaScript frontaux là-bas et chargeons-les dans le navigateur comme une application SPA.

Comme une SPA, nous voulons que l'application s'exécute de manière asynchrone et réponde aux événements (comme le changement de données) au fur et à mesure qu'ils se produisent. Web3.js est une bibliothèque JavaScript qui utilise le JSON-RPC pour répondre aux événements déclenchés lors de l'exécution de contrats intelligents. Alternativement, The Graph est une solution qui utilise GraphQL pour faciliter l'interrogation des données sur la chaîne de blocs.

La Figure 11.11 montre l'architecture mise à jour avec le frontal résidant dans IPFS et l'ajout de The Graph (listé comme GraphQL) pour une meilleure interrogation de la chaîne de blocs.

Figure 11.11 La page web frontale a été déplacée vers IPFS, et des capacités de requête graphique ont été ajoutées. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Cela aboutit à une application Web 3.0 ; cependant, cette architecture présente des problèmes que nous examinerons ensuite.

Défis des applications Web 3.0

Les chaînes de blocs ont actuellement un problème d'extensibilité. La taille moyenne d'un bloc a augmenté au fil des ans, et des frais de transaction sont associés à chaque transaction. Un frais courant est le prix du gaz (gas price), qui est le coût de validation des transactions et de mise à jour des registres. De plus, des performances négatives peuvent survenir sur une chaîne de blocs avec de grandes quantités de transactions.

Une approche pour aider à l'extensibilité est l'utilisation de chaînes latérales. Une chaîne latérale (sidechain) est une chaîne de blocs secondaire (c'est-à-dire de niveau 2 ou L2) qui augmente les performances du réseau de chaîne de blocs en agrégeant les transactions hors chaîne (c'est-à-dire hors du réseau principal/Ethereum) et en les validant sur le réseau principal en une seule fois. Polygon est un système de mise à l'échelle L2 populaire pour les chaînes latérales. D'autres techniques de mise à l'échelle L2 incluent les rollups de chaîne de blocs, qui sont des protocoles conçus pour permettre un débit élevé et des coûts réduits. Ils abordent l'extensibilité en regroupant les transactions et en réduisant la taille des données pour augmenter l'efficacité des transactions et limiter les coûts de stockage. Des exemples de rollups de chaîne de blocs incluent les rollups optimistes et les rollups à divulgation nulle de connaissance. Un rollup optimiste (optimistic rollup) est un protocole qui augmente le débit des transactions en regroupant plusieurs transactions en lots, qui sont traités hors chaîne. Dans ce cas, les données de transaction sont enregistrées sur le réseau principal via des techniques de compression de données qui réduisent les coûts et augmentent la vitesse des transactions. Les rollups optimistes sur Ethereum peuvent améliorer l'extensibilité d'un facteur de 10 à 100. Un rollup à divulgation nulle de connaissance (zk-rollup) (zero-knowledge rollup (zk-rollup)) est un protocole qui regroupe les transactions en lots qui sont exécutés hors du réseau principal. Pour chaque lot, un opérateur de zk-rollup soumet un résumé des changements requis une fois que les transactions du lot ont été exécutées. Les opérateurs ont également produit des preuves de validité qui démontrent que les changements sont exacts. Ces preuves sont significativement plus petites que les données de transaction, il est donc plus rapide et moins cher de les vérifier. De plus, les zk-rollups sont utilisés sur Ethereum pour réduire la taille des données de transaction via des techniques de compression, ce qui finit par réduire les frais d'utilisateur.

La Figure 11.12 montre l'ajout de chaînes latérales à l'architecture pour atténuer certains des défis associés aux DApps Web 3.0. Remarquez comment l'interaction de l'utilisateur avec l'application Web 3.0 est passée de la lecture de contenu dans un modèle Web 1.0 à une participation plus complète au contenu et aux fonctionnalités de l'application Web 3.0.

Figure 11.12 L'interaction de l'utilisateur avec l'application Web 3.0 complète est mise en évidence ici. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Comme vous pouvez le constater, l'architecture est devenue plutôt complexe pour prendre en charge efficacement les DApps. Cependant, le Web 3.0 est encore dans une phase naissante, et plusieurs solutions et outils sont actuellement développés pour faciliter encore davantage la construction et le déploiement des DApps Web 3.0. Hardhat est un écosystème de développeurs pour la construction et le déploiement de contrats intelligents sur un réseau local à des fins de test.

Cette architecture s'est concentrée sur les chaînes de blocs et a utilisé Ethereum comme implémentation principale. Cependant, il existe d'autres solutions DLT. Hashgraph est une approche où seuls les nœuds sélectionnés stockent l'intégralité de la chaîne de blocs, et des mécanismes de vote sont introduits pour valider si les blocs sont corrects. Stacks est une autre DLT où seuls les contrats intelligents sont décentralisés, et les données sont contrôlées par leur propriétaire. Les propriétaires peuvent les partager ou les supprimer, garantissant ainsi la confidentialité des données.

La technologie au quotidien

Utilisation des cadriciels

Les applications web sont utilisées aujourd'hui pour alimenter des sites web commerciaux auxquels les gens accèdent pour effectuer des transactions en ligne afin d'acheter des biens de toute nature. Les applications web mobiles et leurs versions natives sont également disponibles sur les smartphones et les montres pour aider à faire de même. Comment l'utilisation des cadriciels d'applications web et natives aide-t-elle les gens dans la vie de tous les jours ? Fournissez quelques scénarios illustratifs pour expliquer votre opinion. Vos scénarios ne devraient pas se limiter à décrire comment les cadriciels sont utilisés, mais plutôt décrire des situations où ces cadriciels sont appliqués dans la vie réelle.

Applications hybrides Web 2.0/3.0

En raison des qualités et des limitations des architectures Web 2.0 et 3.0, il est probable que nous verrons des solutions qui sont une combinaison des deux approches et qui exploitent leurs meilleurs attributs. Une façon de procéder serait d'avoir des processus de flux de travail qui nécessitent un taux de changement élevé implémentés dans une architecture Web 2.0, tandis que les processus qui bénéficieraient de l'utilisation d'un registre distribué seraient exécutés dans le Web 3.0. Par exemple, les sites web commerciaux traditionnels peuvent continuer à utiliser l'architecture Web 2.0, tandis que les solutions de paiement peuvent être étendues en accédant à l'architecture Web 3.0 pour effectuer des paiements en utilisant des cryptomonnaies (par exemple, Bitcoin).

Considérons une application pour générer des œuvres d'art par IA. De nombreuses solutions existent aujourd'hui pour ce faire ; cependant, nous voulons que notre application confère la « propriété » à l'œuvre d'art numérique qu'une personne génère. Les modèles d'IA sont entraînés à reconnaître des œuvres d'art existantes (par exemple, des peintures disponibles via l'API wikiart.org) qui peuvent être protégées par le droit d'auteur — la propriété est donc encore en cours de détermination devant les tribunaux. Ici, le terme propriété est utilisé pour attribuer la création d'images par IA et rien de plus. Bien que les modèles d'IA soient très populaires, certaines entreprises ne veulent pas partager de données avec les créateurs de modèles d'IA et préfèrent que les modèles d'IA soient déployés dans leur propre infrastructure pour garantir une confidentialité totale. Un jeton non fongible (NFT) (non-fungible token (NFT)) est un identifiant numérique unique sur une chaîne de blocs qu'un utilisateur peut vouloir créer à partir de son image et éventuellement vendre (c'est-à-dire transférer la propriété) sur une place de marché. Un cas d'utilisation courant pour cette application pourrait être :

1. Un utilisateur se connecte au site web et entre une invite pour générer une image.
2. Après plusieurs séries d'ajustements de leurs invites, ils obtiennent une image qu'ils désirent.
3. L'utilisateur paie pour qu'un jeton non fongible soit créé à partir de l'image, qui est stocké sur une place de marché de chaîne de blocs pour la vente.

Comme vous pouvez l'imaginer, l'exécution d'un générateur d'images IA sur une chaîne de blocs pourrait ne pas être très performante. De même, créer des NFT sans technologies de chaîne de blocs est contre-intuitif. Par conséquent, l'architecture de cette solution doit englober les approches Web 2.0 et 3.0.

La Figure 11.13 montre comment les API feront le gros du travail avec le modèle d'IA pour générer l'œuvre d'art. Une fois l'utilisateur satisfait, il interagira avec des aspects de l'interface utilisateur qui exécutent des contrats intelligents pour générer et ajouter le NFT à la chaîne de blocs. Les transactions se produiront sur la chaîne de blocs. Les API peuvent interagir directement avec la chaîne de blocs, à la recherche d'œuvres similaires.

Figure 11.13 Ceci décrit l'interaction de l'utilisateur avec une application hybride Web 2.0/3.0. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Ce modèle dispose toujours d'un serveur Web 2.0 centralisé pour la génération d'œuvres d'art et la gestion des comptes ; cependant, les parties qui traitent de la propriété des NFT et de la vente de cette propriété sont gérées au sein de l'infrastructure de chaîne de blocs Web 3.0. Cette approche répond aux besoins de nombreuses entreprises qui souhaitent tirer parti des fonctionnalités du Web 3.0 tout en préservant leurs sites web Web 2.0 originaux.