6 réponses à ce sujet

[Bussiere]

Voila cela fait quelques temps que je vois pas mal de news sur Node.js

Et du coup je me demande si ca peut m'etre utile pour mon boulot.
Sauf que j'ai un peu du mal a cerner le bousin.
Par contre quand je vois cela :
http://sylvainzimmer...rgest-chess-ai/

Ca laisse reveur.

Du coup des gens l'utilisent et peuvent un peu me dire pourquoi comment dans quel but ?
Avantages / inconvenients ?


Merci
Bussiere

[Rabban]

C'est un peu le truc qui fait le buzz depuis quelques temps dans le monde du web, mais à mon avis son utilité réelle est confinée à la niche assez restreinte des applications ayant besoin de retours du serveur en temps réel. Par exemple, pour quelque chose de semblable au mur de facebook, qui affiche les statuts des autres utilisateurs sitot qu'ils sont disponibles. ou pour une chatbox. ou suivre le cours de la bourse. ou pour un webgame. bref, quelque chose qui a besoin de données actualisées le plus rapidement possible.
On perdrait tout l'interet de la techno si on l'utilisait pour faire un site classique de remontée de contenu, par exemple, qui sera toujours mieux logé avec un back-end classique en php (ou en java, soyons fou) derrière un cache genre varnish.

[DrDrakeRamore]

Hello,
Je rebondis sur ce thread parce que je m'y intéresse également (Bussière, tu as continué ?).
Rabban, la niche dont tu parles est très loin d'être restreinte car on parle de quasiment toute appli web utilisant des appels asynchrones (ajax-style), et pas seulement pour les chats et autres applis de ce genre. Pour ça tu regarderais plutôt du côté des websockets, avec ou sans node.js.

L'histoire c'est qu'avec un serveur http classique ton appel va ouvrir une connexion au serveur et attendre son retour. Pendant tout le temps d'exécution de ta requête, tu vas avoir un thread bloqué.
Avec node.js si j'ai bien compris, ton thread reçoit la requête, la route vers un "handler" puis passe à une autre requête. Lorsque le handler a fini de traiter, il renvoit le résultat via le serveur. Si c'est ça en gros le serveur ne fait plus office que de broker/passe-plats. Ca explique pourquoi on associe tellement node.js à la "scalabilité" (beuark) pour des applications pouvant gérer des milliers de connexions simultannées. Après il faut le reste suive aussi, mais tu élimines un goulot d'étranglement.

Pour l'instant le seul inconvénient que je vois à node.js, c'est que c'est du javascript
Après tu as des exemples d'implémentations avec socket.io, avec des sgbd nosql ... C'est clairement over-hypé mais qu'est-ce que c'est bon !

[Bussiere]

J'ai fait mumuse avec notamment avec du svg pour générer des animations.

En gros tu ecris a la volée du svg dans le html en direct avec du jascript et tu changes en direct le svg selon les input / output de l'utilisateur.

<svg width="150" height="150" viewBox="-105 -105 210 210" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
   <defs>
	  <clipPath id="ball">
		 <circle r="100" stroke-width="0"/>
	  </clipPath>
	  <radialGradient id="shadow1" cx=".4" cy=".3" r=".8">
		<stop offset="0" stop-color="white" stop-opacity="1"/>
		<stop offset=".4" stop-color="white" stop-opacity="1"/>
		<stop offset=".8" stop-color="#EEEEEE" stop-opacity="1"/>
	  </radialGradient>
	  <radialGradient id="shadow2" cx=".5" cy=".5" r=".5">
		<stop offset="0" stop-color="white" stop-opacity="0"/>
		<stop offset=".8" stop-color="white" stop-opacity="0"/>
		<stop offset=".99" stop-color="black" stop-opacity=".3"/>
		<stop offset="1" stop-color="black" stop-opacity="1"/>
	  </radialGradient>
	  <g id="black_stuff" stroke-linejoin="round" clip-path="url(#ball)">
		 <g fill="black">
			<path d="M 6,-32 Q 26,-28 46,-19 Q 57,-35 64,-47 Q 50,-68 37,-76 Q 17,-75 1,-68 Q 4,-51 6,-32"/>
			<path d="M -26,-2 Q -45,-8 -62,-11 Q -74,5 -76,22 Q -69,40 -50,54 Q -32,47 -17,39 Q -23,15 -26,-2"/>
			<path d="M -95,22 Q -102,12 -102,-8 V 80 H -85 Q -95,45 -95,22"/>
			<path d="M 55,24 Q 41,41 24,52 Q 28,65 31,79 Q 55,78 68,67 Q 78,50 80,35 Q 65,28 55,24"/>
			<path d="M 0,120 L -3,95 Q -25,93 -42,82 Q -50,84 -60,81"/>
			<path d="M -90,-48 Q -80,-52 -68,-49 Q -52,-71 -35,-77 Q -35,-100 -40,-100 H -100"/>
			<path d="M 100,-55 L 87,-37 Q 98,-10 97,5 L 100,6"/>
		 </g>
		 <g fill="none">
			<path d="M 6,-32 Q -18,-12 -26,-2
					 M 46,-19 Q 54,5 55,24
					 M 64,-47 Q 77,-44 87,-37
					 M 37,-76 Q 39,-90 36,-100
					 M 1,-68 Q -13,-77 -35,-77
					 M -62,-11 Q -67,-25 -68,-49
					 M -76,22 Q -85,24 -95,22
					 M -50,54 Q -49,70 -42,82
					 M -17,39 Q 0,48 24,52
					 M 31,79 Q 20,92 -3,95
					 M 68,67 L 80,80
					 M 80,35 Q 90,25 97,5
			"/>
		 </g>
	  </g>
   </defs>
   <circle r="100" fill="white" stroke="none"/>
   <circle r="100" fill="url(#shadow1)" stroke="none"/>
   <g><animateTransform attributeName="transform" attributeType="XML" type="rotate" from="0" to="360" begin="0s" dur="3s" repeatCount="indefinite"/>
	  <use xlink:href="#black_stuff" stroke="#EEE" stroke-width="7"/>
	  <use xlink:href="#black_stuff" stroke="#DDD" stroke-width="4"/>
	  <use xlink:href="#black_stuff" stroke="#999" stroke-width="2"/>
	  <use xlink:href="#black_stuff" stroke="black" stroke-width="1"/>
   </g>
   <circle r="100" fill="url(#shadow2)" stroke="none"/>
</svg>

C'est juste une idée mais j'ai pas le temps de creuser :'(

Bussiere

[reset]

C'est très bien NodeJS


Ca permet en effet de faire des push en temps reels. Plus besoin d'un setTimer par ex.
Ca permet de stream entre plusieurs clients. X dessine/ecrit/classe/whatever des données sur son interface web. Directement, tu peux rebalancer ce qu'il fait en direct vers d'autres clients sans stocker ni meme intervenir dans les données envoyées (cherchez stream dans la doc).
Ca permet d'avoir le meme language coté client et coté serveur. Plus besoin de transformer/serializé/jsonencodé vos données ni meme vos objets. C'est le meme language. C'est con mais ca permet une grande souplesse de developpement. Passer un un DOM complet se fait en toute simplicité. Imaginez que coté serveur, vous puissez manipulez le DOM client... ah là je vous parle.
Ca permet de faire du full JS simplement, node JS coté serveur, JQuery + MustacheJS coté client. D'ailleurs, je vous invite à regarder le framework JoshFire basé sur ces technos.



NodeJS c'est bien.



Le débat full JS n'est pas celui de ce thread (et ya débat).

[Bussiere]

Yep des que j'ai le temps je re creuserai ce systeme de générer du svg a la volée en fonction des inputs de l'user.

Bussiere

[DrDrakeRamore]

reset, le 19 March 2012 - 20:29, dit :

C'est très bien NodeJS

Ca permet en effet de faire des push en temps reels. Plus besoin d'un setTimer par ex.
Ca permet de stream entre plusieurs clients. X dessine/ecrit/classe/whatever des données sur son interface web. Directement, tu peux rebalancer ce qu'il fait en direct vers d'autres clients sans stocker ni meme intervenir dans les données envoyées (cherchez stream dans la doc).
Ca permet d'avoir le meme language coté client et coté serveur. Plus besoin de transformer/serializé/jsonencodé vos données ni meme vos objets. C'est le meme language. C'est con mais ca permet une grande souplesse de developpement. Passer un un DOM complet se fait en toute simplicité. Imaginez que coté serveur, vous puissez manipulez le DOM client... ah là je vous parle.
Ca permet de faire du full JS simplement, node JS coté serveur, JQuery + MustacheJS coté client. D'ailleurs, je vous invite à regarder le framework JoshFire basé sur ces technos.

NodeJS c'est bien.

Le débat full JS n'est pas celui de ce thread (et ya débat).

C'est super tout ça mais :
- l'histoire du push c'est pas tout à fait exact; le coeur de node.js ne sait pas faire de push, il faut que tu installes socket.io ou équivalent comme tu peux déjà le faire en ruby par exemple
- passer un DOM complet ? un peu lourd non ?

C'est l'aspect architecture qui distingue node.js et peut le faire adopter par les entreprises pour de gros projets.
C'est très bien expliqué ici :
http://andrewbrobins...rvers-so-great/
http://nodeguide.com...g_the_boss.html