• 1 août 2013

    Apérotech #5 : node.js -Traitement des données en temps réel

    Node.js

    Pour la 5ème édition, nous avons cette fois-ci traité un thème plus technique : le Node.Js.

    C’est un environnement créé par Ryan Dahl en 2009 qui s’appuie sur le JavaScript exécuté côté serveur. Sa puissance réside dans son traitement en temps réel d’un grand nombre de requêtes. (Tchat, système upload rapide, etc.). Elle est principalement basée sur le moteur JavaScript V8 de Google et d’un fonctionnement non-bloquant (requêtes asynchrones).

    aperotech

    Node.js remet le Javascript au goût du jour par son positionnement de bas niveau. Une technologie prometteuse sur le papier, mais qu’en est-il de la mise en pratique et de son exploitation en production ? Pour y répondre, nous avons réuni AF83, Fasterize, Skilld et Toxicode autour de notre apéro, animé par Sébastien Lucas Directeur Associé d’Oxalide.

    sebastien_lucas_oxalide

    Le programme

    • 18h30 : Node.JS de A à Z par Pierre Lancien de Toxicode – 30min
    • 19h00 : Table ronde – Node.JS quelle stratégie pour quel besoin ? – 1h
    • 20h00 : Apéritif Dînatoire

    Pierre Lancien de Toxicode a presenté Node.js en 6 points :

    PierreLancien
    Pierre Lancien – Toxicode : « Le javascript est un peu comme l’assembleur du web »

    Toxicode est une société d’innovation web conçue comme un laboratoire du web, qui mène des projets de R&D pour son propre compte. Toxicode réalise des prestations de conseil et de formation sur Ruby on Rails et JavaScript. Aujourd’hui, Pierre et son équipe ont développé une forte expertise sur le temps réel en HTML5 et Node.Js.

    1. Javascript est un langage de script exécuté dans le navigateur, non compilé et interprété : il est plus souple que du C et du Java.
    2. Côté serveur : Avec Node.Js, le JavaScript peut être exécuté sur un serveur.
    3. Le moteur JavaScript V8 : un moteur de Google capable d’exécuter du JavaScript très rapidement
    4. Programmation événementielle : la détection d’une action du client et lancement d’une action.
    5. Asynchrone (non-bloquant) : Ce mode permet de lancer un grand nombre des requêtes très rapidement. Il permet de ne pas attendre la réponse du serveur pour exécuter une autre requête.
    6. Écosystème : Node.Js est un environnement léger, il n’a pas besoin d’un apache pour fonctionner. La documentation de Node.Js est complète et décrit l’état de stabilité de chaque fonctionnalité, de plus la communauté prend plus de maturité. Sur Github, Node.Js est le repository qui a le plus d’étoiles. Des NPM (Node Packaged Modules) sont disponibles et permettent d’étendre les fonctionnalités de bases (ex : Express, Mocka, Jade, Socket IO).

    Pourquoi faire du Node.Js ?

    • Être amoureux du JavaScript.
    • Avoir des contraintes de forte liées aux terminaux (bande passante limitée ou puissance ou batterie limitées) : le code JavaScript peut-être exécuté en partie côté serveur.
    • Appeler intensivement des Web-services (Facebook, Twitter, notification Apple, etc… ).
    • Réaliser des Web-services qui répondent rapidement grâce au mode non bloquant.
    • Réaliser du bas niveau sur les serveurs par exemple faire du streaming, un serveur de jeux en ligne, manipuler du HTTP à bas niveau.
    • Faire des websockets, node.Js et ouvrir une connexion permanente entre le client et le serveur permettant de gérer des événements. (démo en temps réel avec des points déplaçables pour tous les utilisateurs connectés avec leurs smartphones : on est monté à une dizaine de personnes sur l’application.)
    • Réaliser des API Mobile efficientes, par exemple : Linkedin a constaté une rapidité de réponse multipliée par 20 et une réduction du nombre de serveurs de 30 à 3.

    Pourquoi ne pas faire du Node.Js ?

    • Faire des calculs intensifs.
    • Avoir un gros projet nécessitant une architecture logicielle non conçue pour Node.Js.
    • S’appuyer sur des frameworks comme Ruby on Rails, Symphony et réinventer la roue.
    • Avoir besoin d’une importante équipe de développeurs.

    Pourquoi avoir choisi Node.Js ?

    « Je suis tombé sur Node.Js pour faire du communautaire, du jeu temps réel et du tchat. J’ai commencé par Erlang : en une semaine, mais après avoir fais la démo proposée Node.Js, j’ai arrêté Erlang. En une demi-heure, j’avais déjà un petit tchat et à peu près tout ce que je voulais ! C’était basique mais rapide à mettre en place. De plus, je voulais faire coder des jeux par le plus de monde possible, avec un seul et même langage : Node.Js, car c’est la solution la plus appropriée. Aujourd’hui, il s’est imposé à moi car j’ai des projets appelant intensivement Twitter et Push Apple. Synthétiquement, j’ai utilisé Node.Js pour les usages suivants :

    • Des problématiques de temps réel sur des jeux vidéos en HTML5.
    • Des applications mobiles qui tiennent la charge, pour discuter avec des mobiles qui ont un comportement plus connecté que le Web. »

    Les compétences : « Je fais du Node.Js depuis 2 ans et je n’avais jamais fait du Node.Js mais du JavaScript. Le JavaScript n’est pas un petit langage ou un sous-langage, il y a tout un contexte et un historique à comprendre autour pour l’utiliser efficacement. En JavaScript, si vous savez faire de l’objet, vous êtes un expert et faire du Node.Js c’est faire du (bon) JavaScript (orienté objet). La compétence JavaScript est rare, beaucoup de personnes affirment être expertes mais ne le sont pas. Par exemple : être compétent en Jquery, ce n’est pas être compétent en JavaScript. 2 solutions sont possibles pour avoir de bonnes compétences :

    • La formation d’une personne sur JavaScript/Node.JS (environ de 4 – 5 mois)
    • Le recrutement de développeurs expérimentés dans d’autres langages mais qui se heurteront aux gros a priori sur le JavaScript. »

    La taille d’équipe sur projet en Node.Js ? « Depuis 2 ans, je travaille sur un gros projet de frameworks de jeux-vidéo et je manquais d’expérience. Mes habitudes, venant du Ruby on Rails ont changé, car en Node.Js j’ai tout écrit « from strach » : gérer les queues, les callbacks, les concepts de compositions et d’héritage en JavaScript. Je voulais des modules avec des compostions, et je me suis bien amusé. Mais quand j’ai essayé de composer l’équipe, j’ai dû expliquer ma cuisine aux autres et c’est très difficile. Sur des projets Node.Js, il ne faut pas dépasser une équipe de 3 personnes. »

    Les limites : « Certains NPM ne sont pas très stables ou bien maintenus, il faut faire attention aux mises à jour hâtives. Il faut rester prudent sur la montée en version et faire des tests avec Mocka. Néanmoins, les évolutions et la maintenance du cœur de Node.Js sont séparées du développement des NPM. Cette séparation rend le coeur de Node.Js stable. »

    La communauté : « Beaucoup de gens sont là pour s’amuser et expérimenter. Aujourd’hui, trouver des bibliothèques bien maintenues est rare. Je me rappelle quand j’ai débuté sur Rails, je venais du Java et j’étais en Ruby on Rails version 1. Au départ, les Gems étaient un cauchemar. Pour Node.Js, c’est un peu la même chose et ça va se stabiliser car la technologie et la communauté prennent de la maturité. »

    Conseil : « N’ayez pas peur de JavaScript, soyez ambitieux avec et ne le méprisez pas : on peut faire des trucs intéressants comme dans tous les langages. Une référence sur le JavaScript pour les développeurs expérimentés : The Good Parts. Doug Crockford décrit ce qu’il y a de bon et de mauvais dans JavaScript. L’évolution JavaScript va suivre quelque-unes de ses recommandations. » Bonus vidéo : Conférence The Good Parts.

    bruno-michel
    Directeur Technique d’AF83 – Bruno Michel « Je fais du Node.Js depuis 2009, depuis le début de Node.Js »

    AF83 est une société de services web autour de la communication, l’expérience client et la production technique. Bruno et son équipe ont adopté Node.Js en interne depuis sa sortie en 2009, pour des projets en production depuis 2011 comme : une application de sondage pour la télé-connectée d’une chaîne du PAF, de génération albums photo en PDF et une borne interactive.

    Pour quoi avoir choisi Node.Js ? « Le critère principal a été de pouvoir utiliser du code JavaScript des 2 côtés (serveur et client). Par exemple pour le traitement d’image (rotation, redimensionnement, disposition, etc ..), on a utilisé codeBase côté navigateur et Node-codeBase pour émuler codeBase du côté Node.Js. Pour les autres projets, c’était surtout pour du temps réel et de API REST avec de hautes performances. »

    Quelles compétences et quelle taille d’équipe sur projet en Node.Js ? « Sur un projet de 10 personnes, 3 personnes sont des développeurs Node.Js. La taille de l’équipe en Node.JS ne doit pas être importante car le debug est très compliqué surtout dans un projet de grande taille. »

    Les limites ? « C’est compliqué faire du Node.Js à plusieurs car lorsque l’on débugge, il faut faire des callbacks, et bien passer les contextes. Lorsque l’on tombe sur une exception, on ne sait pas trop d’où elle vient, la plupart du temps, elle est liée au mode asynchrone de Node.Js. »

    Des conventions à respecter dans Node.Js (comme Rails, Symphony, Django, des frameworks) ? « C’est encore assez exploratoire, ça laisse beaucoup de flexibilité et de liberté, il n’y pas énormément de convention. Il existe des frameworks comparables à Sinatra, mais pas réellement de convention. »

    Bluffé par Node.Js sur des enjeux en production ? « Pour l’application de sondage, nous avions eu un cahier des charges avec une contrainte technique de 10 000 connexions à la seconde. Au début, on voulait le faire en Rails, mais on s’est vite aperçu que ce n’était pas possible. Lorsque l’on a testé la montée en charge de l’application Node.Js, on a été bluffé par les performances avec un seul processus et un seul CPU. Mais pour plus de sûreté, nous avons répartis la charge sur 2 serveurs permettant d’avoir du failover. Cependant, l’application n’est pas très complexe : récupérer des sondages, des votes. Dans ce cas simple, Node.Js est rapide qu’avec du Ruby, du Rails ou du Sinatra. »

    Les projets éligibles ou pas à Node.Js ? Le mobile ? « Faire un gros projet en Node.Js est possible à condition de bien le découper en petites applications. Pour le mobile, on fait plus attention à la latence plus que des sites Desktop et le Node.Js permet de répondre en partie à cette contrainte. »

    La communauté et la pérennité de Node.Js : « Node.Js est bien stabilisé depuis 2 ou 3 ans. Mais les modules ne suivent pas correctement les montées de version, on lock les versions et on teste et reteste les montées en version. »

    Conseil : « Commencer par un petit projet annexe voir un projet personnel pour faire son expérience. La courbe d’apprentissage est longue et il ne faut pas ruiner la marge d’un projet, car Node.Js est complexe et peut-être vite consommateur de temps lorsque l’on est novice. »

    Stephane Rios - Fasterize
    Fondateur de Fasterize – Stéphane Rios

    Fasterize est un accélérateur web en SAAS, c’est un super proxy qui réécrit en temps réel les pages HTML et en injectant les bonnes pratiques de webperformance. Le cœur du moteur est écrit en Javascript et traite des millions de requêtes par jour.

    Pourquoi choisir Node.Js ? « Nous connaissions déjà Node.Js et nous devions traiter de la page HTML et du donc DOM : cela a posé des problème de performance, mais côté proxy. Nous avons hésité avec le C car nous avions besoin de performance (entre 50 et 100 ms). De plus il est difficile de trouver un bon codeur en C donc finalement nous sommes resté sur Node.Js. »

    Des conventions à respecter dans Node.Js (comme Rails, Symphony, Django, des frameworks) ? « Pas de convention, nous utilisons le moteur car il est difficile de faire nos traitements avec un framework pour des questions de performance. Néanmoins, Node.Js a une approche module. Nous utilisons le NPM : Express pour les requêtes web (comparable à Sinatra), Vows puis Mocha pour les tests unitaires. Il y a quelques frameworks disponibles mais peu sont bien maintenues. »

    Est-ce que le Node.Js se répand assez vite dans une équipe ? Quelles compétences et taille d’équipe sur projet en Node.Js ? « 6 personnes au bootstrap, il y avait des personnes qui venaient de Ruby, de Rails et Java et on était 2 à bien connaître JavaScript. L’apprentissage ne pose pas trop de problème pour des personnes qui ont l’habitude de coder dans d’autres langages. Ma plus grande fierté est d’avoir converti une personne réticente qui aujourd’hui code des modules. Néanmoins, Node.Js a des subtilités liées à JS et à Node.Js, il faut bien quelques mois pour s’y mettre et même après l’on tombe dans les pièges du JavaScript et de l’asynchrone. »

    Limites : « Le plus compliqué est lors des montées de version : il faut que toute la communauté monte de version en même temps que le cœur de Node.Js. Pour débug, c’est aussi compliqué : nous avons quelques modules pour faire du débug. Il y a 2 philosophies : celui qui catch toutes les exceptions pour les traiter et celui qui redémarre lorsque l’on a une exception. De notre côté, nous catchons les erreurs et les traitons, mais nous avons eu pas mal d’erreurs incompréhensibles (comme des memory leak et des erreurs un peu ésotériques. Node.JS est un produit jeune.). »

    Bluffé par Node.Js sur des enjeux en production ? « En production les taux d’utilisation sont à des taux très bas. Le ratio entre la performance, le CPU et la RAM utilisé est très bon. C’est LA différence avec les autres technos : comment en faire plus avec moins. »

    Les projets éligibles ou pas à Node.Js ? Le mobile ? « On l’utilise pour dans un cas qui n’est pas prévu pour : nous l’utilisons en tant que proxy mais l’optimisation de la webperformance est traitée par des workers qui font du CPU intensif. C’est typiquement ce qu’il ne faut pas faire en Node.Js … mais nous l’avons fait car nous ne connaissions que Node.Js. Mais c’est plus une question d’architecture que de langage : on a conçu notre architecture pour que le traitement ne soit pas bloquant. Nous avons fait nos workers pour faire de la compression d’image, de la minification et ainsi que tout ce qui demande du CPU. »

    La communauté ? « Elle est fantastique et je vous conseille de mettre les mains dans cambouis de Node.Js et les modules. Même dans le cœur, car il est écrit en JavaScript. La communauté prend le temps de réfléchir sur les évolutions du cœur. »

    Conseil : « Premier point, il faut avoir une très forte culture de test. L’intégration continue et de test doivent être important surtout lors de montée en version. La communauté est très active et pour rien casser, il faut tout tester. Deuxième point, il faut faire attention à l’asynchrone. Même aujourd’hui, on oublie vite que tout est asynchrone et on ne se doute pas que même un listen sur le port 8888 est asynchrone. Troisième point, il faut s’investir dans la communauté car elle est très productive et active. »

    JBGuerraz

    Jean-Baptiste Guerraz – Responsable Technique – Skilld

    SkillD est agence experte Drupal et mobile qui s’appuie sur Node.Js pour ses composants en temps réel. Node.Js est utilisé sur des projets de notification et intégration avec Drupal, sur des notifications Facebook mobile et du WebRTC en lab tchat vidéo.

    Pourquoi utiliser Node.Js ? « Pour un besoin de système de notification en temps réel pour un réseau social d’entreprise. Plusieurs solutions étaient mises en concurrence système :

    • Des anciennes pratiques comme le PHP avec du poll : une solution lourde.
    • Des technologies de temps réel comme Twist en Python, Red5 avec du flash et Node.Js.

    Mais le site était déjà très lent, donc tout naturellement le choix s’est porté Node.Js. Mais la solution était jeune et nous avons d’abord fonctionné avec notre lab pour vérifier la capacité de Node.Js à répondre aux besoins. »

    Est-ce que le Node.Js se répand assez vite dans une équipe ? Quelles compétences et taille d’équipe sur projet en Node.Js ? « Petite anecdote : à l’époque, on avait un codeur Drupal qui connaissait JavaScript. On s’était mis en binôme pour monter en compétence sur Node.Js. Je l’ai revu et aujourd’hui, il ne fait que du Node.Js. Je rejoins Pierre sur les compétences, une personne qui fait du JQuery n’est pas forcément un bon codeur en JavaScript. »

    Des conventions à respecter dans Node.Js (comme Rails, Symphony, Django, des frameworks) ? « Node.Js n’est pas encore mainstream, il n’y a pas encore de bonnes pratiques répandues dans la communauté, mais il y a quelques solutions empiriques, mais lorsque la technologie deviendra mainstream : des conventions vont émerger grâce à l’augmentation des codeurs sur Node.Js. »

    Limites ? « Ce sont les mêmes limites que JavaScript avec une couche d’entrée/sortie, réseau, fichier, etc… On retrouve les mêmes outils comme node-inspector basés sur le debuggeur de V8 disponible dans Chrome, avec des breakpoints, etc … »

    Bluffé par Node.Js sur des enjeux en production ? « Node.Js est asynchrone, il ne dort jamais, il fait de l’IDLE, du coup, il est toujours disponible. J’ai testé le cluster Node.Js et après avoir eu un master et N-workers, on se retrouve avec un worker par core, les limites sont loin. Attention, le module est expérimental et a encore quelques bugs. »

    Les projets éligibles ou pas à Node.Js ? Le mobile ? « Sur un mobile, les utilisateurs ne supportent pas les lags, alors que sur un site web, une demi-seconde de plus ne se voit pas. Je déconseille de générer des Web avec du Node.Js : si l’on doit le faire c’est avec un serveur REST, et avec du Backbone pour construire des templates côté client. Mais aussi pour les performances et l’expérience utilisateur. Le mieux reste de templater côté client, plutôt que toujours appeler un serveur pour récupérer une page HTML. »

    La communauté ? « La communauté est incroyable, elle est très outillée : les NPM, les évolutions sont très très rapides. »

    Conseil ?

    1. Apprendre la programmation événementielle
    2. Aller voir Javascript
    3. Finalement aller voir Node.Js

    Compléments : Node.Js n’est pas que du JavaScript, on peut aussi coder en Typescript, en Coffescript, et écrire des modules en C. Les fonctionnements de JavaScript/Node.Js ne peuvent pas être supplantés par des couches d’abstraction : Pour le moment, il faut connaître ce qu’il se passe dans les couches basses.

    Le JavaScript est le langage de 2013 est un peu l’assembleur du web par ses côtés : bas niveau, efficient et multi-plateforme (desktop, mobile, tv, serveur).

    , , ,

Newsletter

Inscrivez-vous et tenez vous au courant de l’actualité Oxalide