Archives du blog

Angular, Express et Socket.io

Vous savez, si vous lisez le blog de Ninja Squad régulièrement, que nous donnons des cours dans différents établissements, de la fac aux écoles d’ingé, en passant par l’IUT. Avec cette nouvelle année scolaire, nous voici repartis!

Je donne depuis quelques années un cours sur les web services à l’INSA, à l’invitation du Docteur Ponge : c’est l’occasion de parler SOAP (beurk), REST (yay!) et Websocket (re-yay!).

Cette année, je veux faire une démo des websockets pour que cela soit un peu moins mystérieux. Faire un peu de code live est toujours un exercice périlleux, mais c’est un bon moyen pour échanger avec les étudiants et leur présenter un certain nombre de technologies, qu’ils connaissent parfois de nom ou pas du tout.

Les websockets sont l’occasion idéale de faire une application web basique, mais permettant d’introduire quelques concepts du Web parfois mal connus (HTML, CSS, Javascript) et un peu de code plus innovant (Node.js, Express, Socket.io, AngularJS, Bootstrap), de discuter sur l’histoire du Web, le fonctionnement des navigateurs (Chrome, Firefox, V8…) et quelques outils pratiques (npm, Git). Bref, d’apporter un peu de culture générale de notre métier, chose que j’appréciais beaucoup lors des interventions de professionnels lorsque j’étais étudiant.

Après cette remise en contexte, passons aux choses sérieuses!

Il me fallait donc un exemple d’application, qui me prenne une trentaine de minutes à réaliser au maximum. J’ai choisi de faire simple : une application de vote qui permet de choisir votre framework Javascript préféré, et de voir les résultats en temps réel. Nous allons voir les différentes étapes pour y parvenir.

Vous trouverez le nécessaire pour utiliser l’application sur le repo Github de Ninja Squad.

Express/Angular

La première branche Git, nommée `express` met en place une application Node.js/Express minimale.

    var express = require('express')
      , app = express()
      , server = require('http').createServer(app);
    
    app.use(express.static(__dirname + '/'));
    
    server.listen(9003);

L’application Node.js va servir les ressources statiques sur le port 9003. On peut alors ajouter le fichier HTML de notre application, qui contient basiquement :

    <div class="row">
      <div class="col-xs-4 vote"> {{ vote.choice }} </div>
      <div class="col-xs-4 vote"> {{ vote.votes }} </div> 
      <div class="btn btn-primary col-xs-4">+1</div>
    </div>

Pour chaque vote de la collection `votes`, le choix (VanillaJS, AngularJS, BackboneJS ou EmberJS), le nombre de vote pour ce choix et un bouton pour ajouter un vote seront affichés. Cela est réalisé en utilisant la directive `ng-repeat` d’Angular.

Le bouton de vote comporte l’attribut `ng-click` qui permet de lui lier une fonction à exécuter. Cette fonction `voteFor` est définie dans le controller :

	function VoteCtrl($scope){
      $scope.votes = [ { choice: 1, label: 'VanillaJS', votes: 0 }, { choice: 2, label: 'AngularJS', votes: 0 }, { choice: 3, label: 'BackboneJS', votes: 0 }, { choice: 4, label: 'EmberJS', votes: 0 }];

      $scope.voteFor = function(choice){ $scope.votes[choice-1].votes++; }
    }

Le controller Angular initialise les votes et définit la fonction de vote, qui ajoute simplement 1 aux votes du choix cliqué.

Etape 1 terminée! Passons maintenant à l’intégration de Socket.io.

Socket.io

Socket.io est l’une des librairies les plus utilisées pour les websockets dans Node (même si elle est maintenant concurrencée par d’autres comme SockJS). Elle a l’avantage de gérer le fallback si les websockets ne sont pas disponibles, et d’être très simple à utiliser à la fois côté client et côté serveur.

La branche `websocket` contient le code correspondant. Outre l’installation de socket.io (`npm install` is your best friend), il nous faut modifier un peu le serveur :

    io.sockets.on('connection', function (socket) {
      socket.emit('votes', { votes: votes });
      socket.on('vote', function(msg){
      	votes[msg.vote-1].votes++;
      	io.sockets.emit('votes', { votes: votes });
      })
    });

L’implémentation est naïve mais suffit à la démonstration : à la connexion d’un nouveau client (`socket.on(‘connection’, …)`), on envoie les votes dans l’état du moment (`socket.emit`). Puis, lorsque l’on recevra un vote (`socket.on(‘vote’, …)`), on incrémente les votes du choix correspondant et on informe tous les participants avec les nouvelles valeurs (`io.sockets.emit`).

Reste à mettre à jour le client pour communiquer avec les sockets :

    var socket = io.connect('http://localhost:9003');

    $scope.voteFor = function(choice){
      socket.emit('vote', {vote : choice })
    }

    socket.on('votes', function(msg){
      $scope.votes = msg.votes;
      $scope.$apply();
    });

On commence par se connecter aux websockets (`io.connect`). La fonction `voteFor` est modifiée pour maintenant envoyer un évenement de vote au serveur (`socket.emit`). Enfin, à chaque fois que les votes sont reçus, les votes du `$scope` Angular sont mis à jour. Petite subtilité : comme cette mise à jour intervient en dehors de la boucle d’exécution d’Angular, il nous faut appeler la fonction `$apply()` pour que le framework prenne les nouvelles valeurs en compte et rafraîchisse les vues.

Nous sommes prêts : si vous ouvrez cette application dans deux onglets, vous pourrez la voir se mettre à jour en temps réel!

A noter que le brillant Brian Ford de l’équipe Angular propose un service Angular pour Socket.io, afin de simplifier son utilisation et notamment les appels à `$apply()`.

Vous pouvez voir une démo en ligne, déployé sur Heroku (le code nécessaire pour cette partie est également sur le repo Github).

Espérons que ce petit essai vous plaise et plaise à nos étudiants!

Publicités

What’s next

Ce vendredi 27 Mai était l’occasion de découvrir l’avenir de notre métier à la conférence What’s Next organisée à Paris. De beaux locaux (le Grand Rex) et de bons speakers étaient au rendez vous !

Neal Gafter
Pour entamer la journée, un talk de Neal Gafter qui commence par rappeler l’histoire de Java, l’origine des disputes avec Google etc… Il nous parle ensuite des nouveautés de Java7 et des possibilités de Java8. Pas forcément la peine d’entrer dans le détail, rien de très nouveau ici. Sa conclusion : c’est mieux d’avoir quelqu’un comme Oracle qui dirige l’innovation et les progrès sur la plateforme Java, et que les efforts soient concentrés sur un seul projet open source (OpenJDK). Cela va dans la bonne direction et il pense que nous assistons a un renouveau de Java. Thomas Conté, architecte chez Microsoft, termine en nous parlant de Azure qui se veut ouvert non pas seulement a .Net mais aussi a Java, Ruby, Python, Php. L’intégration à l’IDE semble aussi bien penser. Pour plus détails si vous êtes intéressés, consultez le whitepaper Azure pour les javaistes.

Rob Harrop
On enchaine avec Rob Harrop qui nous présente RabbitMQ. Cette présentation est probablement l’une de mes préférées de la journée, on a vu des concepts et des démos, le tout dans 5 langages différents (Java, Python, Ruby, Erlang, Javascript !). RabbitMQ se base sur le protocole de messaging AMQP et supporte également STOMP, protocole de plus bas niveau. RabbitMQ est écrit en Erlang et fait partie du portfolio VMWare. Les démos s’enchaine avec des consumers/producers de messages dans des langages différents, avec des protocoles différent. La dernière démonstration montre un serveur node.js qui récupère des messages d’une queue et utilise le protocole websocket pour afficher en live les messages dans le browser.
Speaker très impressionnant et intéressant, si vous avez l’occasion de le voir, je le recommande chaudement !

Theo Schlossnagle
Si le nom du speaker m’était inconnu, son activité n’en est pas moins impressionnante : contributeur à une vingtaine de projets open source, dans différents langages, il est là pour nous parler architecture scalable. Son point de vue est intéressant car il a également travaillé dans les teams ‘ops’ et pas seulement ‘dev’. Il rappelle que le cloud et NoSQL ne sont pas des solutions miracles et que nos applications doivent avant tout être bien pensées pour scaler.
Il prône un modèle d’application ou chaque composant est entièrement découplé et communique avec les autres composants par messages déposés dans des queues. On retrouve là les propos du speaker précédent. Ce découplage permet ensuite de tester chaque partie en isolation, et ainsi grâce à la puissance du cloud, de vérifier des hypothèses sur le dataflow, le cheminement de vos données dans les traitements.
Il faut également vérifier la consistance du comportement en effectuant plusieurs fois la même action : si cela se passe mieux ou moins bien que prévu, il faut enquêter pour trouver la cause et on apprendra forcément quelque chose sur le fonctionnement de l’application. Il insiste également beaucoup sur les traitements asynchrones afin que l’expérience utilisateur soit fluide. Le monitoring (nombre de messages, de connections parallèles, etc…) est également important. Pour terminer il rappelle le ‘Fail often, fail early’ pour garder une expérience utilisateur la moins dégradée possible. Speaker intéressant également !

Michael Chaize
La présentation tourne autour de Flex 4.5, un peu la même que l’on avait pu voir dans nos JUGs. Il faut dire que Michael est français (le seul à nous faire une conférence dans la langue de Molière!) et que c’est un habitué des présentations Flex. Sa démo, un client Twitter, réalisé en live, nécessite très peu de code. Le déploiement peut se faire sur de nombreuses plateformes : navigateurs évidemment mais aussi tablettes android, playbook, ios…
La présentation se termine par le retour d’expérience d’un développeur Flex. Pas mal, un peu de UI ca change…

Jonas Boner
Créateur du framework Akka, travaille maintenant pour TypeSafe (pour ceux qui n’ont pas suivi voir article précédent). Scala est intéressant pour faire des applications… scalables! Et Akka permet de tirer profit de la puissance a notre disposition (Boner vient d’acheter une machine 48 coeurs pour tester pour 5000$, un prix relativement faible pour une telle machine). Petite déception pour ma part, la présentation est à peu près la même que celle de Viktor Klang à Devoxx. Celle ci étant disponible sur Parley’s, je vous conseille d’y jeter un oeil si vous êtes intéressés. La première partie nous présente le fonctionnement des acteurs, puis la seconde des ‘remote actors’ qui permettent de faire du distribué (basé sur NIO, Netty plus précisement et ProtoBuf). Akka 2.0 permettra de faire des ‘clustered actors’ et de gérer notamment la configuration de déploiement.

Shay Banon
La présentation portait sur Elastic Search un moteur d’indexation et de recherche très puissant. On pourrait dire que c’est un SolR sous stéroïdes. Pour tous ceux qui ont travaillé avec un outil de ce genre, la présentation est passionnante : aucun slide mais un enchainement de petits cas pour montrer la puissance de l’outil. Tout commence par le démarrage d’une instance d’Elastic Search en console, puis un enchaînement de commande ‘curl’ pour l’utiliser ! Elastic Search est en effet entièrement exposé par une API REST à laquelle on envoie du JSON, que ce soit pour ajouter des documents à indexer ou faire des requêtes. On passe ensuite en mode distribué en ajoutant plus de noeuds ce qui déclenche une répartition automatique de la charge ainsi que la réplication des données. Tout cela sans que cela dérange vos requêtes : impressionnant ! Si on coupe un noeud, la charge est bien évidement à nouveau répartie de manière uniforme entre les nœuds restants. Point marrant : les instances d’Elastic Search sont nommées aléatoirement à leur création pour simplifier leur suivi : nous avions donc Docteur Sun, Torso et Pasco lors de la démo. Un ajout de document ne nécessite pas de déclaration des différents champs : ES se charge pour vous d’interpréter de quel type est chaque champ. Mais il est également possible de faire cette configuration par l’API REST et de définir soi même les types. L’indexation peut faire appel à un ensemble d’analyzer : phonétique, ngram, etc (on retrouve les analyzer Lucene). Les requêtes offrent elles une véritable DSL qui permet de combiner filtre, analyzer etc… On retrouve également la gestion des facettes : par terme (nombre de fois ou chaque terme est utilisé), statistiques sur un champ (min, max, moyenne, etc…), valeur dans un intervalle donné, histogramme (voir blog ES). La dernière fonctionnalité présentée est le ‘percolator’ qui permet d’enregistrer les requêtes et voir si un document répond à l’une d’entre elles (le document n’est pas indexé mais renvoie les requêtes matchées). Une solution à surveiller si vos besoins d’indexation exige de la scalabilité (le speaker annonce des temps de requêtes de l’ordre la centaine de ms pour plusieurs millions de documents).

Kohsuke Kawaguchi
La journée se termine par une présentation de Koshuke Kawazaki sur Jenkins et son futur. On retrouve pas mal d’idées autour de la gestion des DVCS, les builds distribués exploitant la puissance des machines, les outils de revue de code comme Gerrit. Rien d’exceptionnel mais il est bon de voir que le papa de Jenkins est encore plein d’idées pour la suite !

Une belle journée donc, avec bien sûr l’occasion de rencontrer les fidèles des conférences autour d’un café à la pause. Merci à la société Zenika qui prenait en charge l’organisation de cette journée !