Choisir entre les applications web traditionnelles et les applications monopage (SPA)

Conseil / Astuce

Ce contenu est un extrait du livre électronique, architecte d’applications web modernes avec ASP.NET Core et Azure, disponible sur .NET Docs ou en tant que PDF téléchargeable gratuitement qui peut être lu hors connexion.

Télécharger le PDF

« Loi d’Atwood : toute application qui peut être écrite en JavaScript sera finalement écrite en JavaScript. »
- Jeff Atwood

Il existe deux approches générales pour créer des applications web aujourd’hui : les applications web traditionnelles qui exécutent la plupart de la logique d’application sur le serveur et les applications monopage qui effectuent la plupart de la logique d’interface utilisateur dans un navigateur web, communiquent 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 riches de type SPA au sein d’une application web traditionnelle plus grande.

Utilisez des applications web traditionnelles quand :

• Les exigences côté client de votre application sont simples ou même en lecture seule.

• Votre application doit fonctionner dans les navigateurs sans prise en charge de JavaScript.

• Votre application est accessible au public et bénéficie de la découverte et des références du moteur de recherche.

Utilisez une application SPA quand :

• Votre application doit exposer une interface utilisateur riche avec de nombreuses fonctionnalités.

• Votre équipe est familiarisée avec JavaScript, TypeScript ou BlazorWebAssembly développement.

• Votre application doit déjà exposer une API pour d’autres clients (internes ou publics).

En outre, les infrastructures SPA nécessitent une plus grande expertise architecturale et de sécurité. Ils connaissent une plus grande évolution en raison de mises à jour fréquentes et de nouvelles infrastructures clientes que les applications web traditionnelles. La configuration des processus de génération et de déploiement automatisés et l’utilisation d’options de déploiement comme les conteneurs peuvent être plus difficiles avec les applications SPA que les applications web traditionnelles.

Les améliorations apportées à l’expérience utilisateur rendues possibles par l’approche SPA doivent être évaluées par rapport à ces considérations.

Blazor

ASP.NET Core inclut un modèle permettant de créer des interfaces utilisateur riches, interactives et composables appelées Blazor. Blazor côté serveur permet aux développeurs de créer une 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. Blazor WebAssembly introduit une autre option pour Blazor les applications, ce qui leur permet d’exécuter dans le navigateur à l’aide WebAssemblyde . Étant donné qu’il s’agit d’un code .NET réel en WebAssemblycours d’exécution, vous pouvez réutiliser du code et des bibliothèques à partir de parties côté serveur de votre application.

Blazor fournit une nouvelle, troisième option à prendre en compte lors de l’évaluation de la création d’une application web purement rendue par le serveur ou d’une spa. Vous pouvez créer des comportements riches et de type SPA côté client à l’aide Blazorde , sans avoir besoin d’un développement JavaScript significatif. Blazor les applications peuvent appeler des API pour demander des données ou effectuer des opérations côté serveur. Ils peuvent interagir avec JavaScript si 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 de formulaires web existante que vous envisagez de migrer vers .NET Core ou la dernière version de .NET, vous souhaiterez peut-être passer en revue le livre électronique gratuit, Blazor pour que les développeurs Web Forms puissent voir s’il est judicieux de le migrer vers Blazor.

Pour plus d’informations sur Blazor, consultez Prise en main Blazor.

Quand choisir des applications web traditionnelles

La section suivante fournit une explication plus détaillée des raisons mentionnées précédemment pour la sélection d’applications web traditionnelles.

Votre application a des exigences simples, éventuellement en lecture seule, côté client

De nombreuses applications web sont principalement consommées 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 gèrent et manipulent un grand nombre d’états. Par exemple, un moteur de recherche peut se composer d’un point d’entrée unique avec une zone de texte et une deuxième page pour afficher les résultats de recherche. Les utilisateurs anonymes peuvent facilement effectuer des requêtes et il n’y a pas besoin de logique côté client. De même, l’application publique d’un blog ou d’un système de gestion de contenu se compose généralement de contenu avec peu de comportement côté client. Ces applications sont facilement créées en tant qu’applications web basées sur un serveur traditionnel, qui effectuent une logique sur le serveur web et affichent le code HTML à afficher dans le navigateur. Le fait que chaque page unique du site possède sa propre URL qui peut être marquée et indexée par les moteurs de recherche (par défaut, sans avoir à ajouter cette fonctionnalité en tant que fonctionnalité distincte de l’application) est également un avantage clair dans ces 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 une prise en charge limitée ou sans JavaScript doivent être écrites à l’aide de flux de travail d’application web traditionnels (ou au moins être en mesure de revenir à ce comportement). Les spAs nécessitent javaScript côté client pour fonctionner ; s’il n’est pas disponible, les spAs ne sont pas un bon choix.

Votre équipe n’est pas familiarisé avec les techniques de développement JavaScript ou TypeScript

Si votre équipe n’est pas familiarisée avec JavaScript ou TypeScript, mais qu’elle est familiarisée avec le développement d’applications web côté serveur, elle sera probablement en mesure de fournir une application web traditionnelle plus rapidement qu’une spa. À moins d’apprendre à programmer des contrats spAs comme objectif, ou que l’expérience utilisateur offerte par un spa est requise, les applications web traditionnelles sont un choix plus productif pour les équipes qui sont déjà familiarisées avec leur création.

Quand choisir des spAs

La section suivante explique plus en détail quand choisir un style d’application monopage pour votre application web.

Votre application doit exposer une interface utilisateur riche avec de nombreuses fonctionnalités

Les spAs peuvent prendre en charge des fonctionnalités côté client enrichies qui ne nécessitent pas de rechargement de la page lorsque les utilisateurs effectuent des actions ou naviguent entre les zones de l’application. Les fournisseurs de services peuvent charger plus rapidement, extraire des données en arrière-plan et les actions utilisateur individuelles sont plus réactives, car les rechargements de pages complètes sont rares. Les spAs peuvent prendre en charge les mises à jour incrémentielles, l’enregistrement de formulaires ou de documents partiellement terminés sans que l’utilisateur ait à cliquer sur un bouton pour envoyer un formulaire. Les fournisseurs de services peuvent prendre en charge des comportements riches côté client, tels que le glisser-déplacer, beaucoup plus facilement que les applications traditionnelles. Les spAs peuvent être conçus pour s’exécuter en mode déconnecté, en effectuant des mises à jour vers un modèle côté client qui sont finalement synchronisées avec le serveur une fois qu’une connexion est rétablie. Choisissez une application de style SPA si les exigences de votre application incluent des fonctionnalités enrichies qui vont au-delà de ce que proposent les formulaires HTML classiques.

Fréquemment, les autorités de service doivent implémenter des fonctionnalités intégrées à des applications web traditionnelles, telles que l’affichage d’une URL significative dans la barre d’adresses reflétant l’opération actuelle (et permettre aux utilisateurs de signet ou de lien profond vers cette URL de revenir). Les spAs doivent également permettre aux utilisateurs d’utiliser les boutons précédent et avant du navigateur avec des résultats qui ne les surpriseront pas.

Votre équipe est familiarisée avec le développement JavaScript et/ou TypeScript

L’écriture de spAs nécessite une connaissance de JavaScript et/ou De TypeScript et des techniques et bibliothèques de programmation côté client. Votre équipe doit être compétente pour écrire javaScript moderne à l’aide d’une infrastructure SPA comme Angular.

Références – Frameworks 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 à utiliser par d’autres clients, il peut nécessiter moins d’efforts pour créer une implémentation SPA qui tire parti de ces API plutôt que de reproduire la logique sous forme côté serveur. Les spAs utilisent largement les API web pour interroger et mettre à jour des données lorsque les utilisateurs interagissent avec l’application.

Quand choisir Blazor

La section suivante explique plus en détail quand choisir Blazor votre application web.

Votre application doit exposer une interface utilisateur riche

Comme les SPAs javaScript, Blazor les applications peuvent prendre en charge un comportement client enrichi sans rechargement de page. Ces applications sont plus réactives pour les utilisateurs, récupérant uniquement les données (ou HTML) requises pour répondre à une interaction utilisateur donnée. Conçues correctement, les applications côté Blazor serveur peuvent être configurées pour s’exécuter en tant qu’applications côté Blazor 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 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 suivant récapitule certains des facteurs de base à prendre en compte lors du choix entre une application web traditionnelle, un spa ou une Blazor application.

Facteur	Application web traditionnelle	Application monopage	Blazor Appli
Connaissance requise de l’équipe avec JavaScript/TypeScript	Minimal	Obligatoire	Minimal
Prise en charge des navigateurs sans script	Pris en charge	Non pris en charge	Pris en charge
Comportement minimal de l’application Client-Side	Bien adapté	Surpuissance	Viable
Exigences en matière d’interface utilisateur complexes	Limité	Bien adapté	Bien adapté

Autres considérations

Les applications web traditionnelles ont tendance à être plus simples et ont de meilleurs critères d’optimisation du moteur de recherche (SEO) que les applications SPA. Les bots de moteur de recherche peuvent facilement consommer du contenu à partir d’applications traditionnelles, tandis que la prise en charge de l’indexation des spAs peut manquer ou limitée. Si votre application tire parti de la découverte publique par les moteurs de recherche, il s’agit souvent d’une considération importante.

En outre, sauf si vous avez créé un outil de gestion pour le contenu de votre spa, il peut nécessiter des développeurs pour apporter des modifications. Les applications web traditionnelles sont souvent plus faciles pour les non-développeurs d’apporter des modifications, car la majeure partie du contenu est simplement HTML et peut ne pas nécessiter un processus de génération pour afficher un aperçu ou même déployer. Si les non-développeurs de votre organisation doivent probablement conserver le contenu de l’application, une application web traditionnelle peut être un meilleur choix.

Les spAs brillent lorsque l’application a des formulaires interactifs complexes ou d’autres fonctionnalités d’interaction utilisateur. Pour les applications complexes qui nécessitent l’authentification à utiliser et ne sont donc pas accessibles par les araignées du moteur de recherche public, les spAs sont une excellente option dans de nombreux cas.

PrécédentSuivant