Mon travail en ce moment consiste a coder un serveur de jeu multijoueur temps réel (dans le sens "pas tour par tour", pas dans le sens système de "temps réel"). On le code en Node.js . Et on est assez content, ca marche pas mal.
On a hésité a un moment entre Node.js et Python+Twisted. On a choisi Node.js parce que l'environnement de Node.js est bien plus cohérent en ce qui concerne l'asynchronicité : tous les modules sont asynchrone, ou quand ils ne les ont pas, c'est écrit en gros dessus (et ils sont rares). Ce n'est pas le cas avec Python+Twisted, ou des qu'on utilise un module qui ne vient pas de Twisted, on retombe dans des échanges synchrone qui cassent un peut tout l'intérêt du truc (par exemple je me souviens qu'a l'époque ou on avait testé Twisted, on avait pas trouve de lib pour se connecter a une base Postgres asynchrone…)
En plus, je trouve que la syntaxe du Javascript est bien plus adaptés a l'écriture de code asynchrone que Python+Twisted (note: j'adore Python aussi, je ne fais pratiquement que du JS et du Python).
Pour autant, je n'utiliserais pas Node.js pour faire un site web "classique" (en tous cas pas encore), car mis a part les domaines ou il a un net avantage, sur le reste, c'est moins facile de le faire en Node.js qu'en Django par exemple.
La ou Node.js est fort:
- Si on veut garder une connexion permanente avec le serveur (Websocket)
- Si on veut garder des datas sous le coude entre deux requêtes: dans un web-serveur classique, on doit passer par un fichier ou une DB quelconque, avec Node.js on peut le stocker en ram aussi longtemps qu'on veut (bon, aussi avec les complications que ca peut impliquer, mais dans certaines situation c'est très pratique).
- Si on a des contraintes de scalabilites très fortes, avec des requêtes tres simples (dans le sens pas CPU-intensives).
- Si on a besoin de faire tourner le même code dans le browser et dans le serveur (exemple: un jeu très asynchrone: une partie se déroule a 100% sur le client, a la fin le client envoie tous les évènements au serveur. Le serveur est capable de vérifier s'il n'y a pas eu triche pendant la parte en re-executant toutes les actions, en utilisant exactement la même implémentation (Javascript donc) que sur le client.
Bref, ce n'est pas (encore) la vocation de Node.js de remplacer Apache sur nos port 80, mais ca reste un outil très intéressant, et non ce n'est pas que du hype…
# Mon expérience
Posté par case42 . En réponse au journal Réflexions à propos de NodeJS et de Javascript plus globalement. Évalué à 10.
Mon travail en ce moment consiste a coder un serveur de jeu multijoueur temps réel (dans le sens "pas tour par tour", pas dans le sens système de "temps réel"). On le code en Node.js . Et on est assez content, ca marche pas mal.
On a hésité a un moment entre Node.js et Python+Twisted. On a choisi Node.js parce que l'environnement de Node.js est bien plus cohérent en ce qui concerne l'asynchronicité : tous les modules sont asynchrone, ou quand ils ne les ont pas, c'est écrit en gros dessus (et ils sont rares). Ce n'est pas le cas avec Python+Twisted, ou des qu'on utilise un module qui ne vient pas de Twisted, on retombe dans des échanges synchrone qui cassent un peut tout l'intérêt du truc (par exemple je me souviens qu'a l'époque ou on avait testé Twisted, on avait pas trouve de lib pour se connecter a une base Postgres asynchrone…)
En plus, je trouve que la syntaxe du Javascript est bien plus adaptés a l'écriture de code asynchrone que Python+Twisted (note: j'adore Python aussi, je ne fais pratiquement que du JS et du Python).
Pour autant, je n'utiliserais pas Node.js pour faire un site web "classique" (en tous cas pas encore), car mis a part les domaines ou il a un net avantage, sur le reste, c'est moins facile de le faire en Node.js qu'en Django par exemple.
La ou Node.js est fort:
- Si on veut garder une connexion permanente avec le serveur (Websocket)
- Si on veut garder des datas sous le coude entre deux requêtes: dans un web-serveur classique, on doit passer par un fichier ou une DB quelconque, avec Node.js on peut le stocker en ram aussi longtemps qu'on veut (bon, aussi avec les complications que ca peut impliquer, mais dans certaines situation c'est très pratique).
- Si on a des contraintes de scalabilites très fortes, avec des requêtes tres simples (dans le sens pas CPU-intensives).
- Si on a besoin de faire tourner le même code dans le browser et dans le serveur (exemple: un jeu très asynchrone: une partie se déroule a 100% sur le client, a la fin le client envoie tous les évènements au serveur. Le serveur est capable de vérifier s'il n'y a pas eu triche pendant la parte en re-executant toutes les actions, en utilisant exactement la même implémentation (Javascript donc) que sur le client.
Bref, ce n'est pas (encore) la vocation de Node.js de remplacer Apache sur nos port 80, mais ca reste un outil très intéressant, et non ce n'est pas que du hype…