Application sur une seule page: avantages et inconvénients [fermé]

J'ai lu sur 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 SPA et prouver que je me trompe sur les trois premières déclarations?

                              === ADVANTAGES ===

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

Le rendu côté serveur est difficile à implémenter pour tous les états 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 l'interface utilisateur sans nécessiter un aller-retour de serveur pour récupérer le HTML. Ceci est réalisé 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 à partir des modèles.

Quel est le problème avec la tenue d'une couche modèle pour les non-SPA? SPA est-il la seule architecture compatible avec MVC côté client?

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

Hah, et combien de pages les utilisateurs peuvent télécharger lors de la visite de votre site? Deux trois? Au lieu de cela, il apparaît un autre problème de sécurité et vous devez séparer votre page de connexion, votre page d'administration, etc. en pages distinctes. À son tour, il entre en conflit avec l'architecture SPA.

3.Peut-il y avoir d'autres avantages? N'entends rien d'autre ..

                            === DISADVANTAGES ===

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

PS J'ai travaillé sur des projets SPA et non SPA. Et je pose ces questions parce que je dois approfondir ma compréhension. Aucun moyen de nuire aux supporters du SPA. Ne me demandez pas de lire un peu plus sur SPA. Je veux juste entendre vos réflexions à ce sujet.

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

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

Le rendu côté serveur n'est plus aussi difficile qu'avant avec des techniques simples comme garder un #hash dans l'URL, ou plus récemment HTML5pushState . 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 de hachage spéciale est ajoutée à l'URL. S'il est copié et collé dans une autre fenêtre du navigateur, il peut ouvrir exactement le même courrier (à condition qu'il puisse s'authentifier). Cette approche correspond directement à une chaîne de requête plus traditionnelle, la différence réside simplement dans l'exécution. Avec HTML5 pushState (), vous pouvez éliminer #hashet utiliser des URL complètement classiques qui peuvent être résolues sur le serveur à la première demande, puis charger via ajax sur les demandes suivantes.

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

Le nombre de pages téléchargées par l'utilisateur lors de la visite de mon site Web ?? vraiment combien de mails certains lisent quand il / elle ouvre son compte de messagerie. J'ai lu> 50 d'un coup. maintenant la structure des mails est presque la même. si vous utilisez un schéma de rendu côté serveur, le serveur le restitue à chaque demande (cas typique). - problème de sécurité - vous devez / ne devez pas conserver des pages distinctes pour les administrateurs / connexion qui dépendent entièrement de la structure de votre site. utilisateurs Je veux dire que j'utilise les formulaires d'authentification avec le site Web de mon spa. - Dans le framework SPA Angular JS probablement le plus utilisé, le développeur peut charger l'intégralité du temple html à partir du site Web, ce qui peut être fait en fonction du niveau d'authentification des utilisateurs. pré-chargement html pour tous les types d'authentification isn '

3. Peut-il y avoir d'autres avantages? N'entends rien d'autre ..

• ces jours-ci, vous pouvez supposer en toute sécurité que le client aura des navigateurs compatibles 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 utilisateur SPA voir seulement ce qu'il a des droits appropriés. vous n'avez pas besoin de tout injecter en même temps. le chargement de modèles html diff et async javascript est également une partie valide de SPA.

Les avantages auxquels je peux penser sont:

1. le rendu html prend évidemment quelques ressources maintenant chaque utilisateur visitant votre site le fait. non seulement le rendu des logiques majeures est désormais effectué côté client au lieu du côté serveur.
2. problèmes de date et d'heure - Je donne juste au client l'heure UTC est un format prédéfini et ne se soucient même pas des fuseaux horaires que je laisse javascript gérer. c'est un grand avantage à l'endroit où je devais deviner les fuseaux horaires en fonction de l'emplacement dérivé de l'IP des utilisateurs.
3. pour moi, l'état est plus bien maintenu dans un SPA car 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 à créer des sites comme foodpanda, flipkart, amazon. car 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 essayer de faire une calculatrice dans un site Web non SPA (je sais que c'est bizarre).

Mises à jour des commentaires

Il ne semble pas que quiconque ait mentionné les sockets et les longues interrogations. Si vous vous déconnectez d'un autre client, par exemple l'application mobile, votre navigateur doit également se déconnecter. Si vous n'utilisez pas SPA, vous devez recréer la connexion socket à chaque fois qu'il y a une redirection. Cela devrait également fonctionner avec toutes les mises à jour de données telles que les notifications, la mise à jour du profil, etc.

Une autre perspective: en dehors de votre site Web, votre projet impliquera-t-il une application mobile native? Si oui, vous allez très probablement fournir des données brutes à cette application native à partir d'un serveur (c'est-à-dire JSON) et effectuer un traitement côté client pour le rendre, n'est-ce pas? Donc, avec cette assertion, vous faites DÉJÀ un modèle de rendu côté client. Maintenant, la question devient: pourquoi ne pas utiliser le même modèle pour la version site Web de votre projet? C'est une évidence. Ensuite, la question devient de savoir si vous souhaitez afficher les pages côté serveur uniquement pour les avantages SEO et la commodité des URL partageables / pouvant être mises en signet.

Je suis pragmatique, je vais donc essayer de voir cela en termes de coûts et d'avantages.

Notez que pour tout inconvénient que je donne, je reconnais qu'ils sont résolubles. C'est pourquoi je ne considère rien en noir et blanc, mais plutôt les coûts et les avantages.

Les avantages

• Suivi de l'état plus facile - pas besoin d'utiliser des cookies, la soumission de formulaires, le stockage local, le stockage de session, etc. pour se souvenir de l'état entre 2 chargements de page.
• Le contenu de la plaque de la chaudière qui se trouve sur chaque page (en-tête, pied de page, logo, bannière de copyright, etc.) ne se charge qu'une fois par session de navigateur classique.
• Aucune latence de surcharge lors du changement de "pages".

Désavantages

• Surveillance des performances - mains liées: La plupart des solutions de surveillance des performances au niveau du navigateur que j'ai vues se concentrent exclusivement sur le temps de chargement de la page uniquement, comme le temps jusqu'au premier octet, le temps de construire DOM, l'aller-retour réseau pour le HTML, l'événement onload, etc. la post-charge via AJAX ne serait pas mesurée. Il existe des solutions qui vous permettent d'instrumenter votre code pour enregistrer des mesures explicites, comme lorsque vous cliquez sur un lien, démarrez un chronomètre, puis terminez un chronomètre après avoir rendu les résultats AJAX et envoyez cette rétroaction. New Relic, par exemple, prend en charge cette fonctionnalité. En utilisant un SPA, vous ne vous êtes lié qu'à quelques outils possibles.
• Tests de sécurité / pénétration - mains liées: les analyses de sécurité automatisées peuvent avoir des difficultés à découvrir des liens lorsque votre page entière est créée dynamiquement par un framework SPA. Il existe probablement des solutions à cela, mais encore une fois, vous vous êtes limité.
• Regroupement: il est facile de se retrouver dans une situation lorsque vous téléchargez tout le code nécessaire pour l'ensemble du site Web lors du chargement initial de la page, ce qui peut être extrêmement efficace pour les connexions à faible bande passante. Vous pouvez regrouper vos fichiers JavaScript et CSS pour essayer de charger des morceaux plus naturels au fur et à mesure, mais maintenant vous devez maintenir ce mappage et surveiller que les fichiers involontaires soient récupérés via des dépendances non réalisées (ce qui m'est arrivé). Encore une fois, résoluble, mais avec un coût.
• Refactorisation du Big Bang: Si vous voulez apporter un changement architectural majeur, comme par exemple passer d'un framework à un autre, pour minimiser les risques, il est souhaitable de faire des changements incrémentiels. Autrement dit, commencez à utiliser le nouveau, migrez sur une certaine base, comme par page, par fonctionnalité, etc., puis supprimez l'ancien après. Avec l'application multi-pages traditionnelle, vous pouvez passer d'une page d'Angular à React, puis passer d'une autre page au sprint suivant. Avec un SPA, c'est tout ou rien. Si vous voulez changer, vous devez changer toute l'application en une seule fois.
• Complexité de la navigation: des outils existent pour aider à maintenir le contexte de navigation dans les SPA, comme history.js, Angular 2, dont la plupart reposent sur le cadre URL (#) ou sur la nouvelle API d'historique. Si chaque page était une page distincte, vous n'en avez pas besoin.
• Complexité de la détermination du code: nous considérons naturellement les sites Web comme des pages. Une application multipage partitionne généralement le code par page, ce qui facilite la maintenabilité.

Encore une fois, je reconnais que chacun de ces problèmes est résoluble, à un certain coût. Mais il arrive un moment où vous passez tout votre temps à résoudre des problèmes que vous auriez pu éviter en premier lieu. Cela revient aux avantages et à leur importance pour vous.

Désavantages

1. Le client doit activer javascript. Oui, c'est clairement un inconvénient du SPA. Dans mon cas, je sais que je peux attendre de mes utilisateurs que JavaScript soit activé. Si vous ne pouvez pas, vous ne pouvez pas faire de SPA, point final. Cela revient à essayer de déployer une application .NET sur une machine sans le .NET Framework installé.

2. Un seul point d'entrée sur le site. Je résous ce problème en utilisant SammyJS . 2-3 jours de travail pour configurer correctement votre routage, et les gens pourront créer des signets de lien profond dans votre application qui fonctionnent correctement. Votre serveur n'aura besoin d'exposer qu'un seul point de terminaison - le point de terminaison «Donnez-moi le HTML + CSS + JS pour cette application» (pensez-y comme un emplacement de téléchargement / mise à jour pour une application précompilée) - et le JavaScript côté client que vous écrivez sera gérer l'entrée réelle dans l'application.

3. Sécurité.Ce problème n'est pas unique aux SPA, vous devez traiter la sécurité exactement de la même manière lorsque vous avez une application client-serveur "à l'ancienne" (le modèle HATEOAS qui utilise Hypertexte pour établir un lien entre les pages). C'est juste que l'utilisateur fait les demandes plutôt que votre JavaScript, et que les résultats sont en HTML plutôt qu'en JSON ou dans un format de données. Dans une application non SPA, vous devez sécuriser les pages individuelles sur le serveur, tandis que dans une application SPA, vous devez sécuriser les points de terminaison de données. (Et, si vous ne voulez pas que votre client ait accès à tout le code, vous devez également diviser le JavaScript téléchargeable en zones distinctes. Je le relie simplement à mon système de routage basé sur SammyJS pour que le navigateur ne demande que les choses auxquelles le client sait qu'il devrait avoir accès, sur la base d'une charge initiale des rôles de l'utilisateur,

Les avantages

1. Un avantage architectural majeur d'un SPA (qui est rarement mentionné) dans de nombreux cas est l'énorme réduction du "bavardage" de votre application. Si vous le concevez correctement pour gérer la plupart des traitements sur le client (le tout, après tout), le nombre de demandes au serveur (lire "possibilités d'erreurs 503 qui détruisent votre expérience utilisateur") est considérablement réduit. En fait, un SPA permet de faire 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 créer un SPA. (Les vitesses du réseau s'améliorent, après tout.) Ne faites pas le cas du 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 complètement mon front-end sans impact sur le serveur à part quelques fichiers de ressources statiques. Essayez de le faire avec une application MVC traditionnelle! :) (Cela devient précieux lorsque vous devez vous soucier des déploiements en direct et de la cohérence des versions de votre API.)

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

Un inconvénient majeur du SPA - SEO. Récemment, Google et Bing ont commencé à indexer les pages basées sur Ajax en exécutant JavaScript lors de l'exploration, et dans de nombreux cas, les pages ne sont pas indexées correctement.

Lors du développement de SPA, vous serez obligé de gérer les problèmes de référencement, probablement en post-rendant tout votre site et en créant des instantanés html statiques à l'usage du robot. Cela nécessitera un investissement solide dans des infrastructures adéquates.

Mise à jour 19.06.16:

Depuis que j'ai écrit cette réponse il y a quelque temps, j'ai acquis beaucoup plus d'expérience avec les applications à page unique (à savoir AngularJS 1.x) - j'ai donc plus d'informations à partager.

À mon avis, le principal inconvénient des applications SPA est le référencement, ce qui les limite au type d'applications de «tableau de bord» uniquement. De plus, vous allez avoir beaucoup plus de mal avec la mise en cache, par rapport aux solutions classiques. Par exemple, dans ASP.NET, la mise en cache est extrêmement simple - il suffit d'activer OutputCaching et vous êtes bon: toute la page HTML sera mise en cache selon l'URL (ou tout autre paramètre). Cependant, dans SPA, vous devrez gérer vous-même la mise en cache (en utilisant certaines solutions comme le cache de deuxième niveau, la mise en cache de modèles, etc.).

Je voudrais plaider pour que SPA soit le meilleur pour les applications pilotées par les données. gmail, bien sûr, est une question de données et donc un bon candidat pour un SPA.

Mais si votre page est principalement destinée à l'affichage, par exemple une page de conditions de service, un SPA est complètement exagéré.

Je pense que le point idéal est d'avoir un site avec un mélange de pages de style SPA et statiques / MVC, en fonction de la page particulière.

Par exemple, sur un site que je construis, l'utilisateur atterrit sur une page d'index MVC standard. Mais ensuite, lorsqu'ils accèdent à l'application proprement dite, il appelle le SPA. Un autre avantage à cela est que le temps de chargement du SPA n'est pas sur la page d'accueil, mais sur la page de l'application. Le temps de chargement étant sur la page d'accueil pourrait être une distraction pour les nouveaux utilisateurs du site.

Ce scénario ressemble un peu à l'utilisation de Flash. Après quelques années d'expérience, le nombre de sites Flash uniquement est tombé à près de zéro en raison du facteur de charge. Mais en tant que composant de page, il est toujours utilisé.

Pour des sociétés telles que Google, Amazon, etc., dont les serveurs fonctionnent à pleine capacité en mode 24/7, la réduction du trafic signifie de l'argent réel - moins de matériel, moins d'énergie, moins de maintenance. Décaler l'utilisation du processeur du serveur vers le client est payant et les SPA brillent. Les avantages surpassent largement les inconvénients. Ainsi, SPA ou non SPA dépend beaucoup du cas d'utilisation.

Juste pour en mentionner un autre, probablement pas si évident (pour les développeurs Web), cas d'utilisation pour les SPA: je suis actuellement à la recherche d'un moyen d'implémenter des GUI dans des systèmes embarqués et une architecture basée sur un navigateur me semble attrayante. Traditionnellement, il n'y avait pas beaucoup de possibilités pour les interfaces utilisateur dans les systèmes embarqués - Java, Qt, wx, etc. ou les cadres commerciaux propriétaires. Il y a quelques années, Adobe a tenté de pénétrer le marché avec le flash, mais ne semble pas avoir autant de succès.

De nos jours, les «systèmes embarqués» étant aussi puissants que les mainframes il y a quelques années, une interface utilisateur basée sur un navigateur et connectée à l'unité de contrôle via REST est une solution possible. L'avantage est, l'énorme palette d'outils pour l'interface utilisateur sans frais. (Par exemple, Qt nécessite 20-30 $ par unité vendue sur les frais de redevance plus 3000-4000 $ par développeur)

Pour une telle architecture, le SPA offre de nombreux avantages - par exemple, une approche de développement plus familière pour les développeurs d'applications de bureau, un accès réduit au serveur (souvent dans l'industrie automobile, l'interface utilisateur et les confusions du système sont du matériel séparé, où la partie système a un système d'exploitation RT).

Comme le seul client est le navigateur intégré, les inconvénients mentionnés comme la disponibilité JS, la journalisation côté serveur, la sécurité ne comptent plus.

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

Je dois encore apprendre beaucoup mais depuis que j'ai commencé à apprendre le SPA, je les aime.

Ce point particulier peut faire une énorme différence.

Dans de nombreuses applications Web qui ne sont pas SPA, vous constaterez qu'elles continueront à récupérer et à ajouter du contenu aux pages faisant des demandes ajax. Je pense donc que SPA va au-delà en considérant: et si le contenu qui va être récupéré et affiché en utilisant ajax est la page entière? et pas seulement une petite partie d'une page?

Permettez-moi de présenter un scénario. Considérez que vous avez 2 pages:

1. une page avec la liste des produits
2. une page pour voir les détails d'un produit spécifique

Considérez que vous êtes sur la page de liste. Ensuite, vous cliquez sur un produit pour afficher les détails. L'application côté client déclenchera 2 requêtes ajax:

1. une demande pour obtenir un objet json avec les détails du produit
2. une demande pour obtenir un modèle html où les détails du produit seront insérés

Ensuite, l'application côté client insérera les données dans le modèle html et les affichera.

Ensuite, vous revenez à la liste (aucune demande n'est faite pour cela!) Et vous ouvrez un autre produit. Cette fois, il n'y aura qu'une demande ajax pour obtenir les détails du produit. Le modèle html sera le même, vous n'avez donc pas besoin de le télécharger à nouveau.

Vous pouvez dire que dans un non SPA, lorsque vous ouvrez les détails du produit, vous ne faites qu'une seule demande et dans ce scénario, nous en avons fait 2. Oui. Mais vous obtenez le gain d'une perspective globale, lorsque vous naviguez sur plusieurs pages, le nombre de demandes va être plus faible. Et les données qui sont transférées entre le côté client et le serveur vont également être inférieures car les modèles html vont être réutilisés. De plus, vous n'avez pas besoin de télécharger à chaque demande tous ces fichiers CSS, images, javascript qui sont présents dans toutes les pages.

Considérons également que le langage côté serveur est Java. Si vous analysez les 2 demandes que j'ai mentionnées, 1 télécharge des données (vous n'avez pas besoin de charger de fichier de vue et d'appeler le moteur de rendu de vue) et les autres téléchargements et le modèle html statique afin que vous puissiez avoir un serveur Web HTTP qui peut récupérer directement sans avoir à appeler le serveur d'applications Java, aucun calcul n'est fait!

Enfin, les grandes entreprises utilisent SPA: Facebook, GMail, Amazon. Ils ne jouent pas, ils ont les plus grands ingénieurs qui étudient tout ça. Donc, si vous ne voyez pas les avantages, vous pouvez initialement leur faire confiance et espérer les découvrir plus tard.

Mais il est important d'utiliser de bons modèles de conception SPA. Vous pouvez utiliser un framework comme AngularJS. N'essayez pas d'implémenter un SPA sans utiliser de bons modèles de conception, car vous pourriez finir par avoir un gâchis.

Inconvénients : Techniquement, la conception et le développement initial du SPA sont complexes et peuvent être évités. Les autres raisons de ne pas utiliser ce SPA peuvent être:

• a) Sécurité: L'application à page unique est moins sécurisée que les pages traditionnelles en raison de l'écriture de scripts intersites (XSS).
• b) Fuite de mémoire: une fuite de mémoire en JavaScript peut même ralentir un ordinateur puissant. Comme les sites Web traditionnels encouragent à naviguer entre les pages, toute fuite de mémoire causée par la page précédente est presque nettoyée, laissant moins de résidus.
• c) Le client doit activer JavaScript pour exécuter SPA, mais dans une application multipage, JavaScript peut être complètement évité.
• d) Le SPA atteint une taille optimale, ce qui entraîne un long temps d'attente. Par exemple: Travailler sur Gmail avec une connexion plus lente.

En dehors de ce qui précède, d'autres limitations architecturales sont la perte de données de navigation, aucun journal de l'historique de navigation dans le navigateur et la difficulté des tests fonctionnels automatisés avec du sélénium.

Ce lien explique les avantages et les inconvénients de l'application Single Page.

Dans mon développement, j'ai trouvé deux avantages distincts pour l'utilisation d'un SPA. Cela ne veut pas dire que ce qui suit ne peut pas être réalisé dans une application Web traditionnelle juste que je vois des avantages supplémentaires sans introduire d'inconvénients supplémentaires.

• Potentiel de moins de demandes de serveur car le rendu de nouveau contenu n'est pas toujours ou même jamais une demande de serveur http pour une nouvelle page html. Mais je dis potentiel parce que le nouveau contenu pourrait facilement nécessiter un appel Ajax pour extraire des données, mais ces données pourraient être progressivement plus légères que le balisage lui-même, offrant un avantage net.

• La capacité de maintenir «l'État». Dans ses termes les plus simples, définissez une variable à l'entrée de l'application et elle sera disponible pour d'autres composants tout au long de l'expérience de l'utilisateur sans la transmettre ou la définir sur un modèle de stockage local. La gestion intelligente de cette capacité est cependant la clé pour garder la portée de niveau supérieur épurée.

En plus de nécessiter JS (ce qui n'est pas une folie d'exiger des applications Web), d'autres inconvénients notés ne sont pas, à mon avis, spécifiques au SPA ou peuvent être atténués par de bonnes habitudes et des modèles de développement.

Essayez de ne pas envisager d'utiliser un SPA sans d'abord définir comment vous aborderez la sécurité et la stabilité de l'API côté serveur. Ensuite, vous verrez certains des vrais avantages de l'utilisation d'un SPA. Plus précisément, si vous utilisez un serveur RESTful qui implémente OAUTH 2.0 pour la sécurité, vous obtiendrez deux séparations fondamentales des préoccupations qui peuvent réduire vos coûts de développement et de maintenance.

1. Cela déplacera la session (et sa sécurité) sur le SPA et soulagera votre serveur de tous ces frais généraux.
2. Vos API deviennent à la fois stables et facilement extensibles.

Indiqué plus tôt, mais pas explicite; Si votre objectif est de déployer des applications Android et Apple, l'écriture d'un SPA JavaScript enveloppé par un appel natif pour héberger l'écran dans un navigateur (Android ou Apple) élimine la nécessité de maintenir à la fois une base de code Apple et une base de code Android.

Je comprends que c'est une question plus ancienne, mais je voudrais ajouter un autre inconvénient des applications à page unique:

Si vous créez une API qui renvoie des résultats dans un langage de données (tel que XML ou JSON) plutôt que dans un langage de formatage (comme HTML), vous activez une plus grande interopérabilité des applications, par exemple, dans les applications interentreprises (B2B). Une telle interopérabilité présente de grands avantages mais permet aux gens d'écrire des logiciels pour "miner" (ou voler) vos données. Cet inconvénient particulier est commun à toutes les API qui utilisent un langage de données, et non aux SPA en général (en effet, un SPA qui demande au serveur du HTML pré-rendu évite cela, mais au détriment d'une mauvaise séparation modèle / vue). Ce risque exposé par cet inconvénient peut être atténué par divers moyens, tels que la limitation des requêtes et le blocage des connexions, etc.