Quel est l'inconvénient d'utiliser websocket/socket.io là où ajax fera l'affaire ?

Question

Des questions similaires ont été posées auparavant et elles ont toutes abouti à la conclusion qu'AJAX ne deviendra pas obsolète. Mais en quoi AJAX est-il meilleur que les websockets ?

Avec socket.io, il est facile de se rabattre sur le flash ou le polling long, de sorte que la compatibilité avec les navigateurs ne semble pas être un problème.

Les websockets sont bidirectionnels. Là où ajax ferait une demande asynchrone, le client websocket enverrait un message au serveur. Les paramètres POST/GET peuvent être encodés en JSON.

Alors, qu'y a-t-il de mal à utiliser 100 % de websockets ? Si chaque visiteur maintient une connexion websocket persistante avec le serveur, cela serait-il plus coûteux que de faire quelques requêtes ajax tout au long de la session de visite ?

Answer 1

Je pense que ce serait un plus grand gaspillage. Pour chaque client connecté, il faut une sorte d'objet/fonction/code/quelque chose sur le serveur associé à ce client. Un gestionnaire de socket, ou un descripteur de fichier, ou n'importe quelle autre configuration de votre serveur pour gérer les connexions.

Avec AJAX, vous n'avez pas besoin d'une correspondance 1:1 entre les ressources côté serveur et les clients. Votre nombre de clients peut évoluer de manière moins dépendante que vos ressources côté serveur. Même node.js a ses limites quant au nombre de connexions qu'il peut gérer et garder ouvertes.

L'autre élément à prendre en compte est que certaines réponses AJAX peuvent également être mises en cache. Lorsque vous augmentez la taille de votre site, vous pouvez ajouter un cache HTTP pour réduire la charge des fréquentes requêtes AJAX.

Answer 2

Réponse courte
Maintenir une websocket active a un coût, tant pour le client que pour le serveur, alors qu'Ajax n'aura un coût qu'une seule fois, en fonction de ce que vous en faites.

Réponse longue
Les Websockets sont souvent mal compris à cause de cette idée de "Hey, utilisez Ajax, ça fera l'affaire !". Non, les Websockets ne remplacent pas Ajax. Ils peuvent potentiellement être appliqués aux mêmes champs, mais il y a des cas où utiliser Websocket est absurde.

Prenons un exemple simple : une page dynamique qui charge des données après le chargement de la page du côté client. C'est simple, faites un appel Ajax. Nous n'avons besoin que d'une seule direction, du serveur vers le client. Le client demandera ces données, le serveur les enverra au client, terminé. Pourquoi implémenter des websockets pour une telle tâche ? Vous n'avez pas besoin que votre connexion soit ouverte en permanence, vous n'avez pas besoin que le client demande constamment au serveur, vous n'avez pas besoin que le serveur notifie le client. La connexion restera ouverte, elle gaspillera des ressources, car pour garder une connexion ouverte, il faut constamment la vérifier.

Pour une application de chat, les choses sont totalement différentes. Il faut que le client soit informé par le serveur au lieu de l'obliger à demander au serveur toutes les x secondes ou millisecondes s'il y a du nouveau. Cela n'aurait aucun sens.

Pour mieux comprendre, voyez cela comme deux personnes. L'une des deux est le serveur, l'autre est le client. Ajax est comme envoyer une lettre. Le client envoie une lettre, le serveur répond avec une autre lettre. Le fait est que, pour une application de chat la conversation serait comme ça :
"Hé, serveur, tu as quelque chose pour moi ?
- Non.
- Hé, serveur, tu as quelque chose pour moi ?
- Non.
- Hé, serveur, tu as quelque chose pour moi ?
- Oui, c'est ici."
Le serveur ne peut pas réellement envoyer une lettre au client, si le client n'a jamais demandé de réponse. C'est un énorme gaspillage de ressources. Parce que pour chaque requête Ajax, même si elle est mise en cache, vous devez effectuer une opération du côté du serveur.

Maintenant le cas que j'ai discuté plus tôt avec les données chargées avec Ajax. Imaginez que le client est au téléphone avec le serveur. Garder la connexion active a un coût. Cela coûte de l'électricité et vous devez payer votre opérateur. Maintenant, pourquoi auriez-vous besoin d'appeler quelqu'un et de le garder au téléphone pendant une heure, si vous voulez juste que cette personne vous dise 3 mots ? Envoyez une putain de lettre.

En conclusion, les Websockets ne sont pas un remplacement total d'Ajax !
Parfois, vous besoin de Ajax où l'utilisation de Websocket est absurde.

Answer 3

Personnellement, je pense que les websockets seront de plus en plus utilisés dans les applications web au lieu d'AJAX. Ils ne sont pas bien adaptés à sites web où la mise en cache et le référencement sont plus importants, mais ils feront des merveilles pour les applications web.

Des projets tels que DNode et socketstream aident à éliminer la complexité et permettent un codage simple de type RPC. Cela signifie que votre code client appelle simplement une fonction sur le serveur, en passant toutes les données qu'il souhaite à cette fonction. Et le serveur peut appeler une fonction sur le client et lui transmettre des données également. Vous n'avez pas besoin de vous préoccuper des détails de TCP.

En outre, les appels AJAX entraînent une surcharge importante. Par exemple, une connexion doit être établie et des en-têtes HTTP (cookies, etc.) sont transmis avec chaque requête. Les websockets éliminent une grande partie de ces coûts. Certains disent que les websockets sont plus coûteux, et ils ont peut-être raison. Mais je ne suis pas convaincu que la différence soit vraiment si importante.

J'ai répondu en détail à une autre question connexe, en incluant de nombreux liens vers des ressources connexes. Vous pouvez y jeter un coup d'œil :

api websocket pour remplacer l'api rest ?

Answer 4

Je pense que tôt ou tard, les frameworks basés sur websocket commenceront à apparaître, non seulement pour écrire des parties d'applications web en temps réel comme des chats, mais aussi comme des frameworks web autonomes. Une fois que la connexion permanente est créée, elle peut être utilisée pour recevoir toutes sortes de choses, y compris les parties de l'interface utilisateur de l'application web qui sont maintenant servies par exemple par des requêtes AJAX. Cette approche peut nuire au référencement dans une certaine mesure, mais elle permet de réduire le trafic et la charge générés par les requêtes asynchrones, qui comprennent des en-têtes HTTP redondants.

Cependant, je doute que les websockets remplacent ou mettent en danger AJAX car il existe de nombreux scénarios où les connexions permanentes sont inutiles ou indésirables. Par exemple, les applications mashup qui utilisent (une seule fois) des services REST à usage unique qui n'ont pas besoin d'être connectés en permanence avec les clients.

Answer 5

Il n'y a rien de "mal" à cela.

La seule différence est surtout la lisibilité. Le principal avantage d'Ajax est qu'il vous permet un développement rapide car la plupart des fonctionnalités sont écrites pour vous.

Il y a un grand avantage à ne pas avoir à réinventer la roue chaque fois que vous voulez ouvrir une prise.