Home > Javascript > Node.JS: l’avènement de la programmation asynchrone ?

Node.JS: l’avènement de la programmation asynchrone ?

On est plutôt habitué dans nos développements à faire du synchrone: on appelle une fonction, elle retourne une valeur quand elle a fini de travailler. Avec Javascript ça peut être totalement différent, par exemple avec Node.JS:

var fs = require("fs");
fs.readFile("fichier.txt", function(err, content) {
  if (err) {
    console.err(err);
  } else {
    console.log("file read: " + content.length + " bytes");
  }
}
console.log("after readFile");

En programmation synchrone, ce bout de code aurait lu le fichier, affiché « file read: X bytes » puis « after readFile ». Avec Node.JS ce n’est pas le cas, car toutes les fonctions systèmes ont une version synchrone (qui renvoie un résultat et lève une exception en cas d’erreur), et une vesion asynchrone (qui ne va rien renvoyer, rendre tout de suite la main, et prendre en paramètre un callback acceptant une éventuelle exception et le reste des paramètres).

Le retour attendu sera plutôt celui-là:

after readFile
file read: X bytes

La fonction a tout de suite rendu la main. Il devient ainsi totalement trivial de lire plusieurs fichiers en même temps, ou de réaliser n’importe quelles actions simultanément en mode asynchrone.

Mine de rien, ça change tout ! Et quand on fait du développement web, donc que la même application va devoir être capable de traiter pleins de requêtes différentes en même temps, l’asynchrone (et la gestion des contextes qui va avec) est tout-à-fait adapté: concrètement une requête un peu plus longue à traiter que les autres ne plombera absolument pas les requêtes d’à côté. C’est d’ailleurs il me semble le paradigme choisi par nginx, qui lui réussit plutôt bien ;)

Hé mais pourquoi on n’a pas toujours fait comme ça, d’ailleurs ?

,

  1. Répondre Palleas
    11/02/07

    Très bonne question! J’aime vraiment le fait qu’on puisse avoir une version asynchrone et une version synchrone, typiquement dans le cas de lecture de fichier où, dans des cas très simples, devoir ajouter un listener est contraignant (ou tout simplement inutile).

    Gloire à NodeJS \o/

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">

Trackbacks:4

Listed below are links to weblogs that reference
Node.JS: l’avènement de la programmation asynchrone ? from naholyr.fr
pingback from Présentation de Node.JS et du framework Express « naholyr 1 juin 2011

[...] mais évidemment sur son API, toute entière orientée vers le non bloquant, c'est-à-dire que la plupart des commandes, notamment d'accès au système de fichier, rendront la main directement sa…, ceci étant largement simplifié par l'orientation évènementielle de Javascript. C'est ce choix [...]

pingback from Benchmark Node.JS: méthodes synchrones ou asynchrones ? « naholyr 3 juin 2011

[...] dit souvent que les méthodes asynchrones apportent à Node.JS un avantage dans sa gestion des accès concurrents. On dit que pour une [...]

pingback from Gérer facilement ses versions de node.js - Mikael Randy 3 juin 2011

[...] des serveur, dont l’énorme avantage est l’aspect asynchrone de la programmation (voir cet article de naholyr, qui en parle très bien. Rappelez vous, je vous avais déjà décrit l’installation de [...]

pingback from Bonnes pratiques pour gérer son code asynchrone en Javascript « naholyr 6 juin 2011

[...] on l'a déjà vu, en Javascript, et principalement avec Node.JS, les appels à des méthodes non bloquantes exécutant leur traitement de manière asynchrone permet de faire du multi-tâche de manière très simple et performante. Néanmoins, un piège dans [...]

TOP

Switch to our mobile site