Application à page unique : avantages et inconvénients

Question

J'ai lu des articles sur le SPA et ses avantages. Je trouve la plupart d'entre eux peu convaincants. Il y a 3 avantages qui suscitent mes doutes.

Question : Pouvez-vous agir en tant que défenseur de la SPA et prouver que je me trompe sur les trois premières affirmations ?

                              === ADVANTAGES ===

1. SPA est extrêmement bien pour les sites très réactifs :

Le rendu côté serveur est difficile à mettre en œuvre pour tous les intermédiaires. intermédiaires - les petits états de vue ne correspondent pas bien aux URL.

Les applications à page unique se distinguent par leur capacité à redessiner n'importe quelle partie de la page. de l'interface utilisateur sans qu'il soit nécessaire de faire un aller-retour avec le serveur pour récupérer le code HTML. Ce site Ceci est obtenu en séparant les données de la présentation des données en ayant une couche modèle qui gère les données et une couche vue qui lit les données. à partir des modèles.

Qu'y a-t-il de mal à conserver une couche modèle pour les non-SPA ? SPA est-elle la seule architecture compatible avec MVC du côté client ?

2. Avec le SPA, nous n'avons pas besoin d'utiliser des requêtes supplémentaires au serveur pour télécharger les pages.

Hah, et combien de pages les utilisateurs peuvent-ils télécharger en visitant votre site ? Deux, trois ? Au lieu de cela, d'autres problèmes de sécurité apparaissent et vous devez séparer votre page de connexion, votre page d'administration, etc. en plusieurs pages. A son tour, cela entre en conflit avec l'architecture SPA.

3. y a-t-il d'autres avantages ? Je n'ai pas entendu parler d'autres avantages.

                            === DISADVANTAGES ===

1. Le client doit activer le javascript.
2. Un seul point d'entrée sur le site.
3. Sécurité.

P.S. J'ai travaillé sur des projets SPA et non-SPA. Et je pose ces questions parce que j'ai besoin d'approfondir ma compréhension. Je ne veux pas nuire aux partisans de SPA. Ne me demandez pas de lire un peu plus sur SPA. Je veux juste entendre vos considérations à ce sujet.

Answer 1

Examinons l'un des sites SPA les plus populaires, GMail.

1. Le rendu côté serveur n'est pas aussi difficile qu'il ne l'était auparavant avec des techniques simples comme le maintien d'un #hash dans l'URL, ou plus récemment HTML5 pushState . Avec cette approche, l'état exact de l'application web est intégré dans l'URL de la page. Comme dans GMail, chaque fois que vous ouvrez un courrier, une balise hash spéciale est ajoutée à l'URL. Si elle est copiée et collée dans une autre fenêtre de navigateur, elle peut ouvrir exactement le même courrier (à condition qu'elle puisse s'authentifier). Cette approche correspond directement à une chaîne de requête plus traditionnelle, la différence se situant simplement au niveau de l'exécution. Avec la fonction pushState() de HTML5, vous pouvez éliminer la fonction #hash et utiliser des URL tout à fait classiques qui peuvent être résolues sur le serveur lors de la première demande, puis chargées via ajax lors des demandes suivantes.

2. le nombre de pages téléchargées par l'utilisateur lors de sa visite sur mon site web ?? vraiment combien de mails une personne lit-elle lorsqu'elle ouvre son compte mail. je lis >50 en une seule fois. maintenant la structure des mails est presque la même. si vous utilisez un schéma de rendu côté serveur, le serveur le rendra à chaque requête (cas typique).

   • problème de sécurité - vous devriez/ne devriez pas garder des pages séparées pour les admins/login cela dépend entièrement de la structure de votre site prenez paytm.com par exemple aussi faire un site web SPA ne signifie pas que vous ouvrez tous les endpoints pour tous les utilisateurs je veux dire que j'utilise des formes auth avec mon site web spa.
   • dans le framework spa angular js, probablement le plus utilisé, le développeur peut charger le temple html entier depuis le site web, ce qui peut être fait en fonction du niveau d'authentification des utilisateurs. le préchargement du html pour tous les types d'authentification n'est pas un SPA.
3. • De nos jours, vous pouvez supposer sans risque que le client aura des navigateurs compatibles avec le javascript.
   • un seul point d'entrée du site. Comme je l'ai mentionné précédemment, le maintien de l'état est possible. Vous pouvez avoir autant de points d'entrée que vous le souhaitez, mais vous devez en avoir un à coup sûr.
   • Même dans un SPA, l'utilisateur ne voit que ce qu'il a le droit de voir. Il n'est pas nécessaire d'injecter tout en même temps. Le chargement asynchrone de différents modèles html et de javascript est également une partie valide d'un SPA.

les avantages que je pense être :-

1. le rendu du html prend évidemment des ressources maintenant chaque utilisateur visitant votre site le fait. de plus, pas seulement le rendu, les logiques majeures sont maintenant faites côté client au lieu de côté serveur.
2. problèmes de date et d'heure - je donne simplement au client l'heure exacte dans un format prédéfini et je ne me soucie même pas des fuseaux horaires.
3. Pour moi, l'état est mieux maintenu dans un SPA parce qu'une fois que vous avez défini une variable, vous savez qu'elle sera là. Cela donne l'impression de développer une application plutôt qu'une page web. Cela aide beaucoup, typiquement, à créer des sites comme foodpanda, flipkart, amazon. parce que si vous n'utilisez pas l'état côté client, vous utilisez des sessions coûteuses.
4. Les sites web sont sûrement extrêmement réactifs - je vais prendre un exemple extrême pour cela : essayez de faire une calculatrice dans un site web non SPA (je sais que c'est bizarre).

Answer 2

Inconvénients

1. Oui, c'est un inconvénient évident de la SPA. Dans mon cas, je sais que je peux m'attendre à ce que mes utilisateurs aient activé JavaScript. Si ce n'est pas le cas, vous ne pouvez pas faire de SPA, point final. C'est comme si vous essayiez de déployer une application .NET sur une machine sans le Framework .NET installé.

2. Je résous ce problème en utilisant SammyJS . Deux ou trois jours de travail pour configurer correctement votre routage, et les gens seront en mesure de créer des signets de liens profonds dans votre application qui fonctionneront correctement. Votre serveur ne devra exposer qu'un seul point de terminaison - le point de terminaison "donnez-moi le HTML + CSS + JS pour cette application" (considérez-le comme un emplacement de téléchargement/mise à jour d'une application précompilée) - et le JavaScript côté client que vous écrirez gérera l'entrée réelle dans l'application.

3. Ce problème n'est pas propre aux SPA, vous devez gérer la sécurité exactement de la même manière que pour une application client-serveur de la "vieille école" (le modèle HATEOAS qui utilise l'hypertexte pour établir des liens entre les pages). C'est juste que c'est l'utilisateur qui fait les requêtes plutôt que votre JavaScript, et que les résultats sont en HTML plutôt qu'en JSON ou un autre format de données. Dans une application non-SPA, vous devez sécuriser les pages individuelles sur le serveur, alors que dans une application SPA, vous devez sécuriser les points de terminaison des données. (Et, si vous ne voulez pas que votre client ait accès à tout le code, vous devez également séparer le JavaScript téléchargeable en zones distinctes. Je lie simplement cela à mon système de routage basé sur SammyJS afin que le navigateur ne demande que les choses auxquelles le client sait qu'il devrait avoir accès, sur la base d'un chargement initial des rôles de l'utilisateur, et cela devient alors un problème inexistant).

Avantages

1. L'un des principaux avantages architecturaux d'un SPA (qui est rarement mentionné) est, dans de nombreux cas, la réduction considérable de l'aspect "chat" de votre application. Si vous le concevez correctement pour qu'il gère la plupart des traitements sur le client (ce qui est le but, après tout), le nombre de requêtes au serveur (lire "possibilités d'erreurs 503 qui nuisent à votre expérience utilisateur") est considérablement réduit. En fait, un SPA permet d'effectuer un traitement entièrement hors ligne, ce qui est énorme dans certaines situations.

2. Les performances sont certainement meilleures avec le rendu côté client si vous le faites correctement, mais ce n'est pas la raison la plus convaincante pour construire un SPA. (Les vitesses de réseau s'améliorent, après tout.) N'argumentez pas en faveur des SPA sur cette seule base.

3. La flexibilité dans la conception de votre interface utilisateur est peut-être l'autre avantage majeur que j'ai trouvé. Une fois que j'ai défini mon API (avec un SDK en JavaScript), j'ai pu réécrire entièrement mon interface avec le logiciel zéro impact sur le serveur à part quelques fichiers de ressources statiques. Essayez de faire ça avec une application MVC traditionnelle ! :) (Cela devient précieux lorsque vous devez vous préoccuper des déploiements en direct et de la cohérence des versions de votre API).

Donc, en résumé : Si vous avez besoin d'un traitement hors ligne (ou si vous voulez au moins que vos clients puissent survivre à des pannes de serveur occasionnelles) - ce qui réduit considérablement vos propres coûts matériels - et si vous pouvez assumer JavaScript et les navigateurs modernes, alors vous avez besoin d'un SPA. Dans d'autres cas, il s'agit plutôt d'un compromis.