JavaScript frontal pur avec API Web et vues MVC avec ajax

C'était plus une discussion pour savoir ce que les gens pensent de nos jours sur la façon de diviser une application Web.

J'ai l'habitude de créer une application MVC avec toutes ses vues et contrôleurs. Je créais normalement une vue complète et la transmettais au navigateur sur une demande de page complète, sauf s'il y avait des zones spécifiques que je ne voulais pas remplir immédiatement et j'utilisais ensuite des événements de chargement de page DOM pour appeler le serveur pour charger d'autres zones en utilisant AJAX.

De plus, en ce qui concerne le rafraîchissement partiel de la page, j'appellerais une méthode d'action MVC qui retournerait le fragment HTML que je pourrais ensuite utiliser pour remplir des parties de la page. Ce serait pour les zones que je ne voulais pas ralentir le chargement initial des pages, ou les zones qui correspondaient mieux aux appels AJAX. Un exemple serait pour la pagination de table. Si vous souhaitez passer à la page suivante, je préférerais qu'un appel AJAX reçoive ces informations plutôt que d'utiliser une actualisation de la page complète. Mais l'appel AJAX retournerait toujours un fragment HTML.

Ma question est. Mes réflexions sur cet archaïque parce que je viens d'un arrière-plan .net plutôt que d'un arrière-plan purement frontal?

Un développeur frontal intelligent avec qui je travaille, préfère ne rien faire dans les vues MVC, et préfère tout faire sur le front. Jusqu'aux appels d'API Web remplissant la page. Ainsi, plutôt que d'appeler une méthode d'action MVC, qui retourne du HTML, il préférerait retourner un objet standard et utiliser javascript pour créer tous les éléments de la page.

La méthode du développeur frontal signifie que tous les avantages que j'obtiens normalement avec la validation de modèle MVC, y compris la validation côté client, disparaîtraient. Cela signifie également que tous les avantages que j'obtiens avec la création des vues, avec des modèles html fortement saisis, etc. seraient disparus.

Je crois que cela signifierait que j'aurais besoin d'écrire la même validation pour la validation front-end et back-end. Le javascript devrait également avoir beaucoup de méthodes pour créer toutes les différentes parties du DOM. Par exemple, lorsque j'ajoute une nouvelle ligne à une table, j'utilise normalement la vue partielle MVC pour créer la ligne, puis la renvoie dans le cadre de l'appel AJAX, qui est ensuite injecté dans la table. En utilisant une manière frontale pure, le javascript prendrait un objet (pour, disons, un produit) pour la ligne de l'appel api, puis créerait une ligne à partir de cet objet. Création de chaque partie individuelle de la ligne du tableau.

Le site Web en question comportera de nombreux domaines différents, depuis l'administration, les formulaires, la recherche de produits, etc. Un site Web qui, selon moi, ne nécessite pas d'être architecturé en une seule page d'application.

Quelles sont les opinions de tout le monde à ce sujet?

Je suis intéressé à entendre les développeurs front-end et les développeurs back-end.

Je suis également quelque peu sceptique quant au fait que chaque nouvelle application Web doit être un SPA, mais une chose à laquelle je suis vendu à 100% en tant que généraliste avec la majeure partie de son expérience côté client est qu'une architecture orientée services qui transmet le brut les données plutôt que HTML au client est la voie à suivre, que vous chargiez des pages / vues prédéfinies à partir du serveur et que vous fassiez beaucoup de choses dynamiques avec des données après le chargement de la page ou que vous construisiez presque tout à 100% avec JavaScript.

Les raisons pour lesquelles cela est préférable à un développement côté client sont à peu près les mêmes que celles pour lesquelles personne ne veut HTML dans la base de données. Qu'est-ce que le développeur côté client est censé faire quand il veut utiliser une table par exemple quand on lui a remis du HTML? Le coût des performances de la gestion de tout cela sur le client est trivial par rapport à la demande d'un autre serveur de le faire pour vous. De plus, la construction HTML est assez bien couverte dans JS-land. Le tri des données et la création de nouvelles lignes de tableau HTML à partir de celles-ci est un travail assez trivial pour un développeur expérimenté côté client.

Et à quoi sert l'architecture back-end d'un frontal pour un autre appareil qui pourrait avoir besoin de faire quelque chose d'exotique comme implémenter des widgets qui sont 100% canvas ou une structure HTML totalement différente? Pourquoi un développeur côté client devrait-il charger Visual Studio ou frapper à la porte des développeurs arrière pour effectuer un ajustement strictement présentationnel?

En ce qui concerne vos préoccupations concernant la perte de la validation de modèles fortement typés, croyez-moi quand je dis que si vous avez affaire à un développeur compétent côté client, vous ne trouverez aucun framework .NET ou outil de studio visuel plus charbonneux. diamant-à-poussière écrasant analement sur HTML bien formé et valide que lui.

Du point de vue de la pile complète, je l'aime parce que cela signifie que je n'aurai jamais à pêcher pour la logique commerciale ou d'application, certains yutz ont décidé de passer dans la couche de modèles. Sans parler de la charge par utilisateur qu'il enlève de vos serveurs tout en améliorant dans de nombreux cas l'expérience de chargement pour l'utilisateur dans les navigateurs modernes avec des ordinateurs modernes.

Je pense qu'il est également plus facile de raisonner sur l'architecture back-end lorsque vous l'avez complètement isolée de toutes les choses de présentation. Vous ne saisissez plus de données pour les écraser dans du HTML. Vous le rassemblez pour créer une structure de données indépendante de l'implémentation qui se préoccupe plus d'une utilisation générale que de ce qui va être fait de l'autre côté. OMI, cela tend à conduire à plus de cohérence dans la façon dont les choses sont traitées, car les données sont désormais un objectif final plutôt que l'avant-dernière étape d'un processus et il y a moins d'occasions pour des préoccupations indépendantes de se croiser les fils.

Je vais offrir ma valeur très subjective de 2 penny (pour ce que ça vaut;)). Il n'y a pas de bonne ou de mauvaise réponse à cela et il y a beaucoup de considérations du monde réel en plus de vos points, par exemple:

• Avez-vous l'expérience pertinente en interne? la création d'une application orientée client est très différente d'une application principalement basée sur un serveur avec un ensemble de compétences complètement différent.
• Combien de temps voulez-vous qu'il prenne et quels navigateurs devez-vous prendre en charge? - plus vous en faites sur le client, plus vous rencontrerez de problèmes de navigateur; IE8 est pénible et les performances JavaScript sont assez médiocres, mais de nombreuses entreprises exécutent des configurations XP / IE.
• Sur quels appareils vos utilisateurs vont-ils consulter le site? L'analyse et l'exécution de JavaScript peuvent être rapides sur une version récente de Chrome, mais ce n'est pas le cas sur un appareil mobile plus ancien, en particulier pas une grande quantité de JavaScript avec une charge de logique métier.
• Quelle est l'importance de la charge initiale? Le modèle de serveur est plus rapide que le modèle de client

Cette liste n'est en aucun cas exhaustive et sonne comme un dénigrement côté client, ce qui n'est pas mon intention, j'ai créé des sites avec un fort accent sur le front end.

Pour moi, cela se résume vraiment à l'expérience utilisateur et à la réutilisation des API. Pour répondre à chacun d'eux.

Si vous allez créer une application ou proposer une API, il est très judicieux d'utiliser un projet d'API .Net, cela constitue alors la logique, la vérification et la mise en œuvre multiplateforme. Dans ce scénario, une approche complète côté client peut être favorable, l'API peut être maintenue séparément et fournit simplement une interface à votre application. Vous pouvez modifier la logique et la refonte confortablement et simplement garder l'interface la même. Vous pouvez facilement écrire différentes applications pour différents supports en utilisant le même code d'arrière-plan.

L'argument le plus fort pour une solution frontale pure (à mon avis) est celui de l'expérience utilisateur.

Est-ce que (en considérant tous les inconvénients) une application de navigateur JavaScript pure offre une amélioration substantielle de la convivialité et de l'expérience utilisateur sur un site Web traditionnel?

Lors de la création de sites qui fonctionnent comme des applications natives; Je dirais que la réponse est un oui évident. Cependant, la plupart des sites ne sont pas aussi nets, il s'agit donc d'évaluer si les flux de travail des utilisateurs individuels bénéficient d'une interface hautement dynamique.

J'adopte une vision assez pragmatique de cela, ce n'est ni un problème ni une question; JavaScript jouera évidemment très bien avec les technologies de serveur et vous n'avez pas à choisir l'une ou l'autre - chaque site n'est pas une application web d'une seule page - mais rien ne vous empêche d'utiliser Knockout, backbone et autres sur des pages individuelles pour améliorer les choses là où cela est jugé nécessaire.

J'ai une relation amour-haine avec les applications lourdes frontales.

D'une part, j'aime écrire JavaScript et j'aime le navigateur comme environnement d'exécution.

D'un autre côté, les deux se sentent comme une voiture de course de Formule 1 avec des trous dans le moteur. Cela se résume vraiment à ceci: pouvez-vous empêcher la duplication de la logique métier entre C # et JavaScript? Si c'est le cas, utilisez n'importe quelle méthode pour générer la vue que vous jugez digne. Si vous dupliquez la logique métier dans deux langues, vous pouvez avoir un développeur front-end qui veut juste écrire JavaScript et ne voit pas tout à fait la situation.

Quant aux différences techniques:

Rendu partiel et livraison au client:

• Mise en œuvre simple et rapide
• Empêche la duplication de la logique métier du backend
• Peut entraîner une charge utile HTTP beaucoup plus importante pour le navigateur. Pas une mauvaise chose sur un bureau avec une connexion à large bande passante. Très mauvais sur un téléphone mobile faible alors que vous êtes assis sur un train aux heures de pointe qui accélère sur la piste à 60 mph et 1000 autres téléphones mobiles se déconnectent simultanément d'une tour de cellule et tentent de se reconnecter à la tour de cellule suivante.

Fourniture de JSON et rendu d'un modèle côté client:

• Peut entraîner une charge utile HTTP plus petite que HTML, ce qui peut rendre l'application plus réactive sur des connexions réseau peu fiables ou lentes
• De nombreux langages de modèles JavaScript sont entièrement disponibles, ce qui signifie que nous n'avons pas besoin d' un backend juste pour générer du HTML

Parfois, je pense que les nouveaux cadres JavaScript jettent le bébé avec l'eau du bain --- mec j'espère que je ne deviens pas un programmeur grognon grincheux ...

Dans ma dernière application, j'ai combiné l'api REST et le front-end JavaScript.

Ce que j'ai fait, c'est:

• J'ai créé une API REST pour les opérations CRUD.
• J'ai créé une application Javascript qui charge des modèles HTML prédéfinis et remplit les données renvoyées par l'API REST.

Fondamentalement, le front-end JS communique avec l'API REST pour les opérations CRUD et remplit le code HTML avec les données renvoyées ou créées, ou supprime les données supprimées ou met à jour les données modifiées.

Ainsi, nous avons du HTML pur, nous avons le traitement effectué sur le client, nous avons moins de bande passante en n'ayant pas à charger tout le HTML et pouvons donner une expérience vraiment Web 2.0 aux utilisateurs.

Je ne fais pas de validations commerciales sur le front-end pour la sécurité et la duplication de code, car n'importe qui peut modifier les données avant de les envoyer au serveur et nous devons valider à nouveau les données sur le serveur. Par conséquent, cela serait facilement piraté. Toutes les validations sont effectuées sur le back-end. Les validations côté client sont effectuées uniquement pour les types d'entrée.

Avantages:

• Possibilité de faire des changements dans le HTML car il n'est pas généré par JS;
• Réduction de la consommation de bande passante en utilisant ajax et JSON;
• Consommation moindre du traitement du serveur, car le HTML est peuplé côté client;
• Expérience utilisateur améliorée en utilisant JS pour changer l'écran, permettant l'utilisation d'effets et augmentant la vitesse de rendu.
• Meilleure utilisation du protocole HTTP, en utilisant REST.

Les inconvénients:

• 2 demandes à maintenir;
• Dépend du traitement client, qui peut être mauvais en raison d'un matériel médiocre.

J'espère que cela t'aides.

Cordialement,

Concernant l' validationaspect dans Web Api - Il est possible de faire une "validation de modèle" et de répondre avec une réponse http 400 de mauvaise requête.

Reportez-vous à /programming/11686690/handle-modelstate-validation-in-asp-net-web-api/25050285#25050285