9 utilisations mortelles pour les WebSockets

À tous mes lecteurs: Heureusement pour moi, je suis actuellement dans les systèmes de mise à l'échelle du Brésil, absorbant le temps de 90 ° F (32,2 ° C) et faisant le plein de feijoada et de caipirinha. Pendant ce temps, pour garder ce blog conforme à vos normes, j'ai demandé à mon homme principal Jonathan Freeman de vous éduquer pendant mon absence. Sans plus tarder, voici Jonathan - gourou du front-end, spécialiste du big data et musicien de jazz. Profitez-en et à bientôt dans quelques semaines! - ACO

Les utilisateurs demandent désormais des informations dès qu'elles sont disponibles. Si vous devez actualiser la page pour obtenir de nouvelles informations, il est déjà trop tard. Heureusement, un protocole pris en charge par tous les navigateurs modernes permet un échange direct de données: les WebSockets.

Aucune autre solution n'existe qui fournit une véritable communication bidirectionnelle comme WebSockets, mais de nombreux développeurs Web s'appuient toujours sur des hacks comme le long sondage AJAX. (Pour mémoire, je pense qu'un long sondage est très créatif et fonctionnel, mais c'est néanmoins un hack.) Le manque d'enthousiasme pour les WebSockets peut être lié à une vulnérabilité de sécurité il y a des années ou au manque de prise en charge du navigateur à l'époque, mais les deux problèmes ont été adressé.

[Travaillez plus intelligemment, pas plus dur - contient les conseils et les tendances que les programmeurs doivent connaître dans le Guide de survie des développeurs. Téléchargez le PDF dès aujourd'hui! | Tenez-vous au courant des dernières actualités des développeurs grâce à la newsletter Developer World. ]

Déterminer s'il faut utiliser WebSockets pour le travail en cours est simple:

  • Votre application implique-t-elle plusieurs utilisateurs qui communiquent entre eux?
  • Votre application est-elle une fenêtre sur les données côté serveur en constante évolution?

Si vous avez répondu oui à l'une de ces questions, envisagez d'utiliser WebSockets. Si vous n'êtes toujours pas sûr et que vous voulez de l'inspiration, voici quelques cas d'utilisation époustouflants.

1. Flux sociaux

L'un des avantages des applications sociales est de savoir ce que font tous vos amis lorsqu'ils le font. Bien sûr, c'est un peu effrayant, mais nous l'aimons tous. Vous ne voulez pas attendre quelques minutes pour savoir qu'un membre de votre famille a gagné un concours de pâtisserie ou qu'un ami s'est fiancé. Vous êtes en ligne, votre flux doit donc être mis à jour en temps réel.

2. Jeux multijoueurs

Le Web devient rapidement une plate-forme de jeu. Sans avoir à compter sur des plug-ins (je vous regarde, Flash), les développeurs Web sont désormais en mesure d'implémenter et d'expérimenter des jeux haute performance dans le navigateur. Que vous utilisiez des éléments DOM, des animations CSS, du canevas HTML5 ou que vous expérimentiez WebGL, une interaction efficace entre les joueurs est cruciale. Je ne veux pas découvrir que mon adversaire a bougé après avoir appuyé sur la détente.

3. Édition / codage collaboratif

Nous vivons à l'ère des équipes de développement distribuées. Travailler sur une copie d'un document suffisait auparavant, mais il fallait ensuite trouver un moyen de fusionner toutes les copies éditées ensemble. Les systèmes de contrôle de version comme Git peuvent vous aider avec certains fichiers, mais vous devrez toujours retrouver des personnes lorsque Git trouve un conflit qu'il ne peut pas gérer. Avec une solution collaborative comme WebSockets, nous pouvons travailler sur le même document et ignorer toutes les fusions. Il est facile de voir qui édite quoi et si vous travaillez sur la même partie d'un document que quelqu'un d'autre.

4. Données Clickstream

Il est essentiel de pouvoir analyser comment les utilisateurs interagissent avec votre site Web pour l'améliorer. Le coût de HTTP nous a obligés à prioriser et à ne collecter que les données les plus importantes. Ensuite, six mois plus tard, nous réalisons que nous aurions dû collecter une métrique différente - une métrique qui ne semblait pas importante mais qui éclairerait maintenant une décision critique. Avec la surcharge des requêtes HTTP à l'écart, vous pouvez être moins restrictif sur le type de données que vous envoyez du client. Vous voulez suivre le mouvement de la souris en plus des chargements de page? Envoyez simplement les données via une connexion WebSocket au back-end et conservez-les dans votre magasin NoSQL préféré. (MongoDB est idéal pour enregistrer des événements comme celui-ci.) Vous pouvez maintenant lire les interactions des clients pour voir ce qui se passait réellement.