Choisir entre des applications web traditionnelles et des applications monopages
Conseil
Ce contenu est un extrait du livre électronique, Architect Modern Web Applications with ASP.NET Core and Azure (Architecturer des applications web modernes avec ASP.NET Core et Azure), disponible dans la documentation .NET ou en tant que PDF téléchargeable gratuitement qui peut être lu hors connexion.
« Loi d’Atwood : Toute application pouvant être écrite en JavaScript sera au bout du compte écrite en JavaScript. »
- Jeff Atwood
Aujourd’hui, vous avez le choix entre deux approches pour créer des applications web : les applications web traditionnelles qui effectuent la plupart de la logique d’application sur le serveur, et les applications monopages (SPA) qui effectuent la plupart de la logique d’interface utilisateur dans un navigateur web en communiquant avec le serveur web principalement à l’aide d’API web. Une approche hybride est également possible, la plus simple étant d’héberger une ou plusieurs sous-applications de type SPA au sein d’une application web classique plus grande.
Utilisez des applications web traditionnelles quand :
Les exigences côté client de votre application sont simples (voire même lecture seule).
Votre application doit fonctionner dans les navigateurs sans prise en charge de JavaScript.
Utilisez une application SPA quand :
Votre application doit exposer une interface utilisateur élaborée offrant de nombreuses fonctionnalités.
Votre équipe connaît bien les techniques de développement JavaScript, TypeScript ou BlazorWebAssembly.
Votre application doit déjà exposer une API pour d’autres clients (internes ou publics).
De plus, les frameworks SPA demandent de plus grandes connaissances en architecture et en sécurité. Elles subissent davantage de modifications que les applications web traditionnelles en raison des mises à jour fréquentes et des nouveaux frameworks clients. La configuration de processus de déploiement et de génération automatisés et l’utilisation d’options de déploiement telles que des conteneurs peuvent être plus difficiles avec les applications SPA qu’avec les applications web traditionnelles.
Les améliorations de l’expérience utilisateur rendues possibles avec l’approche SPA doivent être comparées à ces considérations.
Blazor
ASP.NET Core comprend un modèle pour créer des interfaces utilisateur riches, interactives et composables appelées Blazor. Blazor côté serveur permet aux développeurs de créer l’interface utilisateur avec C# et Razor sur le serveur et pour que l’interface utilisateur soit connectée de manière interactive au navigateur en temps réel à l’aide d’une connexion SignalR persistante. BlazorWebAssembly introduit une autre option pour les applications Blazor, ce qui leur permet de s’exécuter dans le navigateur à l’aide de WebAssembly. Étant donné qu’il s’agit d’un code .NET réel exécuté sur WebAssembly, vous pouvez réutiliser du code et des bibliothèques à partir d’éléments côté serveur de votre application.
Blazor fournit une troisième option nouvelle dont il faut tenir compte lors de l’évaluation de la nécessité de créer une application web purement rendue par le serveur ou d’une SPA. Vous pouvez créer des comportements côté client de type SPA enrichis à l’aide de Blazor, sans avoir besoin de développement JavaScript significatif. Les applications Blazor peuvent appeler des API pour demander des données ou effectuer des opérations côté serveur. Elles peuvent interagir avec JavaScript lorsque c’est nécessaire pour tirer parti des bibliothèques et infrastructures JavaScript.
Envisagez de créer votre application web avec Blazor quand :
Votre application doit exposer une interface utilisateur riche
Votre équipe est plus à l’aise avec le développement .NET que le développement JavaScript ou TypeScript
Si vous disposez d’une application Web Forms existante que vous envisagez de migrer vers .NET Core ou la dernière version de .NET, vous pouvez consulter le livre électronique gratuit, Blazor pour les développeurs Web Forms pour voir s’il est judicieux de la migrer vers Blazor.
Pour plus d’informations sur Blazor, consultez Prise en main de Blazor.
Quand choisir les applications web traditionnelles
La section suivante offre une explication plus détaillée des raisons indiquées précédemment justifiant le choix des applications web traditionnelles.
Votre application présente des exigences côté client simples, éventuellement de lecture seule
De nombreuses applications web sont consommées principalement en lecture seule par la grande majorité de leurs utilisateurs. Les applications en lecture seule (ou en lecture principalement) ont tendance à être beaucoup plus simples que celles qui tiennent à jour et manipulent de nombreuses données d’état. Par exemple, un moteur de recherche peut être constitué d’un seul point d’entrée avec une zone de texte et d’une deuxième page pour afficher les résultats de recherche. Les utilisateurs anonymes peuvent facilement effectuer des requêtes, et peu de logique côté client est nécessaire. De même, une application publique de blog ou de système de gestion de contenu est généralement surtout constituée de contenu avec peu de comportement côté client. Il est facile de créer ce genre d’application en tant qu’application web traditionnelle basée sur un serveur, qui exécute la logique sur le serveur web et restitue le code HTML à afficher dans le navigateur. Le fait que chaque page unique du site ait sa propre URL qui peut être ajoutée aux Favoris et indexée par des moteurs de recherche (par défaut, sans avoir à ajouter cette fonctionnalité comme fonction distincte de l’application) est également un avantage évident dans de tels scénarios.
Votre application doit fonctionner dans les navigateurs sans prise en charge de JavaScript
Les applications web qui doivent fonctionner dans les navigateurs avec peu ou aucune prise en charge de JavaScript doivent être écrites à l’aide de workflows d’applications web traditionnelles (ou au moins être en mesure de revenir à un comportement de ce type). Les applications SPA nécessitent JavaScript côté client pour pouvoir fonctionner. S’il n’est pas disponible, elles ne constituent pas un bon choix.
Votre équipe ne connaît pas très bien les techniques de développement JavaScript ou TypeScript
Si votre équipe ne connaît pas bien JavaScript ou TypeScript, mais sait comment développer des applications web côté serveur, elle pourra probablement générer une application web traditionnelle plus rapidement qu’une application SPA. Les applications web traditionnelles sont un choix plus productif pour les équipes qui ont l’habitude de créer ce genre d’application, à moins que l’apprentissage de la programmation d’applications SPA soit un objectif ou que l’expérience utilisateur offerte par une application SPA soit absolument nécessaire.
Quand choisir des applications SPA
La section suivante offre une explication plus détaillée précisant quand il est préférable de choisir un style de développement d’application SPA pour votre application web.
Votre application doit exposer une interface utilisateur élaborée offrant de nombreuses fonctionnalités
Les applications SPA peuvent prendre en charge des fonctionnalités avancées côté client qui ne nécessitent pas le rechargement de la page quand les utilisateurs effectuent des actions ou naviguent parmi les zones de l’application. Les applications SPA peuvent se charger plus rapidement et récupérer des données en arrière-plan, et les différentes actions utilisateur sont plus réactives car les rechargements de page complète sont rares. Les applications SPA peuvent prendre en charge les mises à jour incrémentielles, l’enregistrement de formulaires ou de documents partiellement remplis sans que l’utilisateur ne doive cliquer sur un bouton pour envoyer un formulaire. Les applications SPA peuvent prendre en charge des comportements avancés côté client, tels que le glisser-déplacer, beaucoup plus facilement que les applications traditionnelles. Les applications SPA peuvent être conçues pour s’exécuter en mode déconnecté afin d’effectuer des mises à jour d’un modèle côté client qui sont par la suite synchronisées sur le serveur une fois qu’une connexion a été rétablie. Choisissez une application de style SPA si les exigences de votre application incluent des fonctionnalités avancées qui vont au-delà de celles offertes par les formulaires HTML classiques.
Souvent les applications SPA doivent implémenter des fonctionnalités qui sont intégrées aux applications web traditionnelles, comme l’affichage d’une URL significative dans la barre d’adresse reflétant l’opération en cours (et permettant aux utilisateurs de créer un Favori ou un lien ciblé afin de pouvoir revenir à cette URL). Les applications SPA doivent aussi permettre aux utilisateurs de cliquer sur les boutons Précédent et Suivant du navigateur avec des résultats auxquels ils doivent s’attendre.
Votre équipe connaît bien les techniques de développement JavaScript et/ou TypeScript
L’écriture d’applications SPA nécessite une bonne connaissance des bibliothèques et des techniques de programmation côté client et JavaScript et/ou TypeScript. Votre équipe doit savoir écrire du code JavaScript moderne à l’aide d’un framework SPA comme Angular.
Références – Frameworks de SPA
- Angular: https://angular.io
- React: https://reactjs.org/
- Vue.js: https://vuejs.org/
Votre application doit déjà exposer une API pour d’autres clients (internes ou publics)
Si vous prenez déjà en charge une API web pour une utilisation par d’autres clients, il peut être plus facile de créer une implémentation de SPA qui tire parti de ces API, plutôt que de reproduire la logique côté serveur. Les applications SPA utilisent beaucoup les API web pour interroger et mettre à jour des données quand les utilisateurs interagissent avec l’application.
Quand choisir Blazor
La section suivante est une explication plus détaillée du moment où choisir Blazor pour votre application web.
Votre application doit exposer une interface utilisateur élaborée
Comme les SPA basées sur JavaScript, les applications Blazor peuvent prendre en charge un comportement client enrichi sans rechargement de page. Ces applications sont plus réactives pour les utilisateurs, en ne récupérant que les données (ou le code HTML) requis pour répondre à une interaction utilisateur donnée. Conçues correctement, les applications Blazor côté serveur peuvent être configurées pour s’exécuter en tant qu’applications Blazor côté client avec des modifications minimales une fois cette fonctionnalité prise en charge.
Votre équipe est plus à l’aise avec le développement .NET que le développement JavaScript ou TypeScript
De nombreux développeurs sont plus productifs avec .NET et Razor qu’avec des langages côté client comme JavaScript ou TypeScript. Étant donné que le côté serveur de l’application est déjà développé avec .NET, l’utilisation de Blazor garantit que chaque développeur .NET de l’équipe peut comprendre et potentiellement générer le comportement du serveur frontal de l’application.
Table de décision
Le tableau de décision ci-dessous récapitule certains facteurs à prendre en compte lors du choix entre une application web traditionnelle, une application SPA ou une application Blazor.
| Factor | Application web traditionnelle | Applications monopage | Application Blazor |
|---|---|---|---|
| Connaissances de l’équipe de JavaScript/TypeScript | Minimal | Obligatoire | Minimal |
| Prise en charge des navigateurs sans script | Pris en charge | Non pris en charge | Pris en charge |
| Comportement d’application côté client minimal | Adapté | Non adapté | Viable |
| Exigences d’une interface utilisateur riche et complexe | Limité | Adapté | Adapté |