Côté serveur - Côté client : comment les différencier ?

Bien chers tous,

Après avoir lu cet article :

http://www.technologies-ebusiness.co...nce-javascript

je me suis posé la question suivante : dans un projet informatique, comment faites-vous pour comprendre que
1) "telle partie relève du back end" ? ( donc doit être développée, par exemple, en Java ) ;
2) "telle partie relève du front end" ? ( donc doit être développée, par exemple, en JavaScript ).

En effet, j'ai l'impression que l'on peut faire en JavaScript presque tout ce que l'on peut faire en Java et réciproquement.

Est-ce que je me trompe ?

Merci.

Bien à vous.

Sophie

Pour moi je pense que la partie serveur s'exécute au profit d'un certain nombre de clients comme un web service peut l'illustrer.
En général on met dans un serveur ce qui requiert le pus de ressource, de sécurité, de disponibilité ......
Et donc, dans un client on met tout ce qui ne concerne que le dit "Client", c'est à dire essentiellement l'affichage dans le navigateur.

Quant au langage, on peut en effet faire en JavaScript tout ce qu'on peut faire en java grâce à de nouveaux Framework server comme node.js

Mais tous les projets de grosses envergure utilisent coté serveur JEE .NET ou PHP

Bonsoir,

Merci pour votre réponse.

Je pensais qu'il fallait faire le contraire :
1) exécuter le maximum chez le client pour réduire les frais de gestion du serveur ;
2) exécuter uniquement sur le serveur le code critique : le code qui ne peut être donné au client.

Très cordialement

Sophie

Coucou,

Traditionnellement on ne s'occuppe que de l'affichage côté client. Question de sécurité. Le client est manipulbale facilement. D'ailleurs une autre règle est de ne pas faire confiance des données qui viennent du client.

Bête exemple : tu reçois des données d'un formulaire, tu penses que tu as tout vérifié côté client parce que tu as mis un peu de code Javascript pour vérifier les données de ton formulaire. Hé bien, pas de bol, j'ai modifié ta page sur mon PC (c'est facile avec Firebug par exemple) et j'ai bypassé ta vérification. Si côté serveur tu ne fais pas de vérification alors j'ai gagné.

Donc tout ce qui est traitement de données, logique, ... doit se faire côté serveur!
De plus les serveurs actuels sont surpuisants comparés au PC des gens qui accéderont à ton application.

Donc pour résumé :
Max sur le serveur!
Affichage unqiuement côté client.

Citation:

---

Envoyé par Sophie 2015

1) exécuter le maximum chez le client pour réduire les frais de gestion du serveur ;
2) exécuter uniquement sur le serveur le code critique : le code qui ne peut être donné au client.

---

Ca dépend complètement du contexte et surtout du besoin !
Dans tous les cas, tu auras des échanges entre le serveur et le client. Et à un moment, le serveur devra de toute façon envoyer toutes les données pour faire afficher des données lisibles, que ce soit du HTML déjà formaté, ou des fichiers javascript et un échange de données JSON/XML

Si tu es dans une démarche de limitation des coûts serveur, tu commences à t'orienter vers une architecture avec un client riche quand effectivement tu as besoin d'un niveau d'optimisation de ton application qui fasse en sorte que tu n'échange plus que le minimum d'informations. Mais c'est surtout un problème de bande passante et de quantité de données échangées, pas tellement de coût côté serveur (ça va plus vite d'envoyer juste du json pour mettre à jour des infos par rapport à une page entière de donnée, mais côté serveur ça coûte pas beaucoup plus cher en terme de CPU/IO... Voir même ça coûte plus cher parce que la plupart des moteurs de génération de XML/JSON se basent sur la réflexivité et c'est TRES coûteux).

Si tu es en train de travailler sur une application web locale qui sera utilisée par 10 utilisateurs, tu n'auras aucun gain réel niveau coût serveur à utiliser un client riche.

Le vrai point de différence, c'est surtout un point d'architecture : est-ce que tu as envie d'avoir un serveur applicatif qui ne fait qu'échanger des données avec ceux qui le demandent, où est-ce que tu veux fournir des pages web? Dans le premier cas, tu pourras interfacer d'autres applications (mobile, application lourde), tandis que dans le deuxième tu ne feras qu'une application web.


Sinon, quoi qu'il en soit, sur des questions de sécurité, il vaut mieux ne RIEN mettre côté client... Ou uniquement le minimum vital.
La logique applicative, mieux vaut la mettre à un seul niveau plutôt que de la répartir sur plusieurs niveaux différents de ton application.

Bonjour,

Merci à tous,

Vos explications sont très claires et très instructives.

Très cordialement

Sophie