Avantages / inconvénients entre mettre l'accent sur le traitement côté client ou côté serveur

Pourquoi voudrais-je écrire une application web avec beaucoup de traitement côté serveur?

Pour moi, l'écriture du programme côté client est un énorme avantage car elle enlève autant de charge serveur que possible car elle n'a qu'à envoyer des données au client avec un traitement minimal.

Je vois très peu de choses sur l'écriture d'applications Web, à part l'écriture côté serveur et le traitement côté client comme une simple vue . Pourquoi voudrais-je jamais faire ça? Le seul avantage que je vois est que je peux écrire dans la langue que je veux ( http://www.paulgraham.com/avg.html ).

Il y a deux problèmes majeurs.

1. La première est simple: vous ne savez généralement pas quel type de ressources sont disponibles côté client. S'il nécessite 1,5 Go pour traiter quelque chose, pouvez-vous vraiment le pousser sur un navigateur client inconnu (IE, Safari, Opera, Firefox, etc.) sur une plate-forme cliente inconnue? Le client appréciera-t-il son système quand vous le submergez?

2. La seconde est plus architecturale - quelles couches souhaitez-vous exposer au monde extérieur? La plupart conviendraient qu'il est incroyablement risqué d'exposer votre couche de données. Que diriez-vous de votre couche de service? Voulez-vous vraiment livrer cette logique là-bas? Si vous le faites, exposez-vous également les points d'entrée à votre couche de données? Si vous conservez le côté serveur de la couche de service, que reste-t-il? L'interface utilisateur, non? Voir la raison 1 sur pour des considérations sur la quantité de ce qui vit sur le serveur et sur le client.

La sécurité est d'abord et avant tout . Poussez toute votre logique vers le client et c'est un jeu équitable pour les pirates et les exploits.

Tout ce qui a une valeur perçue ne durera pas 5 minutes, en particulier la valeur monétaire, et sera joué ou piraté ou exploité et cassera votre système assez mal. Même s'il n'a que peu ou pas de valeur monétaire, il y a une classe de gens qui le pirateront juste pour casser votre système parce qu'ils s'ennuient.

Côté client versus côté serveur

Le traitement côté client est conforme aux normes REST les plus populaires ainsi qu'à MVC par opposition aux approches basées sur les pages et SOAP. L'émergence de ces tendances et l'accent mis sur AJAX et Html-RIA, les scripts côté client sont en hausse et plus populaires; cependant, en raison de problèmes de sécurité et de la capacité du client, les scripts côté client ont une niche particulière et ne doivent pas être utilisés pour tout.

Considérations:

Mobile

Si une grande partie de votre public cible sera constituée d'utilisateurs mobiles, le traitement lourd doit être laissé au serveur.

Cohérence entre les navigateurs

Les normes Web ont parcouru un long chemin et cela peut ne pas être aussi préoccupant, mais chaque développeur Web sait que IE 6,7 et 8 et parfois Safari peuvent agir de manière amusante du côté client - certaines fonctions peuvent ne pas fonctionner à cause de restrictions de sécurité et autres en raison de normes non mises en œuvre. Il est également important de noter que l'utilisateur final peut configurer un navigateur pour avoir certaines restrictions ou même désactiver complètement le traitement côté client (pas de javascript!). Si la cohérence est une exigence pour 100% des utilisateurs (et surtout si vous faites quelque chose de peu orthodoxe) côté serveur est le plus important.

Sécurité

Toute manipulation de données que vous souhaitez sécuriser doit être effectuée sur le serveur. Toutes les données traitées côté client sont absolument ouvertes à la manipulation. Par exemple, si vous avez une fonction javascript qui traite certaines informations qui sont ensuite publiées dans le système - il serait très facile de manipuler le résultat juste avant qu'il ne soit affiché, même si vous disposez d'une sécurité back-end exemplaire

UI / UX

Le traitement côté client est laissé à l'interface utilisateur et à la création d'applications Internet riches (RIA). Il est utilisé pour créer des animations, des effets, des interactions avec les utilisateurs, ainsi que pour charger dynamiquement du contenu via des appels AJAX au lieu de recharger une page entière.

Ce sera principalement une duplication des efforts. Très probablement, toutes les données du client auront été vérifiées et traitées à nouveau au niveau du serveur.

Le serveur ne peut pas supposer que votre client riche / robuste a envoyé les données, donc avec tout ce qui est envoyé, le serveur doit le valider et le traiter. Il est donc logique de le mettre là.

Cependant, je crois qu'une certaine logique peut être faite au niveau du client pour une meilleure expérience d'interface utilisateur.

Vous avez raison, pourquoi envoyer des données au serveur si elles ne sont pas complètes ou incorrectes. Il est facile de vérifier les champs obligatoires ou les téléphones ou adresses e-mail correctement formatés. Je n'ai jamais aimé soumettre un formulaire puis attendre 5 secondes pour me dire que j'avais oublié de saisir un champ. Ce type de traitement, bien sûr, faites-le sur le client et assurez-vous qu'il est correct et en utilisant la logique côté client pour une réponse rapide à l'utilisateur. Comme vous l'avez souligné, un effet secondaire bonus serait que votre serveur devrait traiter moins de mauvaises demandes de données. MAIS, le serveur doit encore valider aussi, donc vous dupez la logique. Mais vos utilisateurs seront plus heureux.

Il y a une ligne fine ici. Logique de validation simple OK, logique métier de base pas OK.

1. Tout d'abord, vous devez comprendre l'architecture des applications Web, la plupart sinon toutes sont à 3 niveaux:

   a) Client / Présentation - HTML et Javascript, peuvent contenir des applets ActiveX / Flash / Java / Silverlight. Je vais sortir sur un membre et ajouter des applications mobiles natives qui communiquent avec un serveur principal. Fondamentalement, le rôle de cette couche est de fournir une interface permettant à l'utilisateur du système d'interagir avec lui.

   b) Logique d'entreprise - PHP / RoR / Java où les données du client sont collectées, traitées et stockées et où les demandes de données du client sont traitées et renvoyées au client

   c) Backend Data Store - fournit un stockage persistant pour les informations système

2. Alors, où faites-vous la validation, dans toutes les couches. Pourquoi?

   a) Côté client - assurez-vous que l'utilisateur saisit les données correctes, les champs obligatoires, etc.

   b) Logique métier - filtrer, assainir et valider les données client. Exécutez des règles métier plus complexes pour vous assurer que les données sont bien formées pour le stockage. Une partie de la validation effectuée à l'avant est répétée ici, car il peut y avoir différents clients, par exemple les navigateurs Javascript peuvent être désactivés. Il peut également accepter des données provenant de différentes sources via des API par exemple, donc tout doit être validé.

   c) Stockage de données dorsales - les contraintes garantissent que les données sont bien formées pour le stockage et la récupération ultérieure.

Alors, où concentrez-vous vos efforts de validation, utilisez chaque couche pour effectuer la validation qui lui convient le mieux, et laissez des règles plus complexes pour la couche qui peut la gérer

Une grande partie est de garder votre traitement proche de vos données. Si vous avez des centaines de Go de données, vous n'allez évidemment pas les envoyer à un client. Avec l'augmentation des vitesses d'accès aux données, cela devient moins un problème, mais si vous avez un site Big Data, vous voulez toujours faire autant de filtrage et de rétrécissement sur le serveur que vous pouvez avant de l'expédier.

Lorsque vous créez complètement votre comportement côté client (par exemple, avec Javascript), le référencement peut devenir un problème.

Les solutions Web qui gardent beaucoup du côté serveur sont plus facilement en mesure de conserver un contenu spécifique publié sur une URL spécifique (généralement RESTful), d'une manière qui soit visible pour les moteurs de recherche.

Cela signifie également qu'un visiteur peut mettre en signet une page spécifique. Avez-vous essayé cela sur Facebook?

Ce truc peut être résolu, mais il est généralement intégré à des applications qui font beaucoup sur le serveur (RAILS, WordPress, etc.), alors que si vous construisez dans REACT, vous devrez sauter à travers des cerceaux.

La raison en est la stabilité .

Côté serveur, je peux choisir des composants stables. Habituellement, cela signifie que je choisis Java et un tas de bibliothèques soigneusement sélectionnées telles que FreeMarker. Inutile de dire que chaque bibliothèque, à l'exception des bibliothèques standard de Java, est traitée comme jetable, donc j'accède aux bibliothèques externes via un wrapper self-made. Cela signifie que je peux facilement passer d'une bibliothèque à l'autre si l'exigence se présente.

Chaque fois que je mets à jour Java vers une nouvelle version, cela fonctionne généralement bien car Java est un composant extrêmement stable, même sur les principales mises à jour de version. Et aussi, chaque serveur que j'ai utilise la même version Java. Tous les clients n'exécutent pas la même implémentation JavaScript.

Côté client, je ne peux pas choisir de composants stables. Les créateurs de navigateurs me forceront à choisir JavaScript, un langage que je n'aime pas particulièrement, mais que je suis obligé d'utiliser. (Et ne me parlez pas des langages compilés en JavaScript, ils sont horribles!) L'implémentation JavaScript de chaque navigateur est différente. Cela signifie que c'est un enfer total de tester mon produit avec toutes les versions de navigateur prises en charge.

Ma solution? J'effectue autant de traitement que possible du côté serveur, et le côté client n'est qu'un wrapper léger qui envoie des données au serveur et reçoit des données du serveur sous forme de fragments JSON et HTML. Évitez XML; utilisez plutôt JSON.

Je ne fais pas de modèles côté client; Je rend le contenu sur le serveur dans un fragment HTML que j'attribue ensuite en utilisant l' .innerHTMLattribut à divers éléments d'espace réservé côté client. Cela permet de garder la pile technologique aussi simple que possible, car je n'ai pas besoin de deux moteurs de modèle (un Java et un JavaScript).

L'inconvénient est évidemment la latence de la vitesse de la lumière; une demi-seconde de latence n'est pas rare entre les continents.

Considérez que vos clients de nos jours peuvent être des smartphones. Les smartphones ont une autonomie de batterie limitée, donc si vous effectuez des calculs lourds, il vaut mieux les décharger sur vos serveurs. Cependant, les choses simples peuvent être plus éconergétiques lorsqu'elles sont effectuées du côté client, car vous pouvez alors éviter l'accès radio. Mais l'argument principal, la stabilité, peut signifier qu'il peut être judicieux de décharger même un simple calcul sur le serveur.

En complément, comme déjà observé dans certaines réponses, vous gagnez également en sécurité . Si la logique d'application est entièrement du côté client, quelqu'un peut, par exemple, fixer un prix pour tout ce qu'il va acheter dans votre boutique en ligne.