Node.js est le nouveau noir

référence: https://www.sitepoint.com/node-js-is-the-new-black/

Si vous avez écouté les actualités concernant la technologie Web au cours de la dernière année, vous avez probablement entendu le nom de node.js mentionné au moins une ou deux fois. Ce qui s’est passé ensuite a probablement ressemblé à ceci: vous avez demandé «Qu’est-ce que c’est?» Et quelqu’un (ou Google) vous a dit que c’était un moyen d’écrire des serveurs Web en utilisant JavaScript. Si cela ne vous effrayait pas, vous auriez peut-être alors demandé «Pourquoi voudriez-vous l’utiliser?» Et la réponse aurait peut-être été similaire, tirant parti des E / S événementielles non bloquantes pour permettre simultanéité dans les applications à longue interrogation ou à base de comètes.

À quel point vous avez cessé de poser des questions. Je ne vous en veux pas. Pour aider à briser ce mur de jargon, voici ma tentative d’expliquer ce que est node.js et pourquoi vous devriez y prêter attention.

Voici donc ce qu’il en a toujours été: un navigateur envoie une demande à un site Web. Le serveur du site reçoit la demande, recherche le fichier demandé, effectue les requêtes de base de données selon les besoins et envoie une réponse au navigateur. Sur les serveurs Web traditionnels, tels qu’Apache, chaque demande amène le serveur à créer un nouveau processus système pour gérer cette demande.

Ensuite, il y avait Ajax. Au lieu de demander chaque fois une nouvelle page, nous ne demandions que l’information que nous voulions réellement. Ok, c’est une amélioration.

Mais réfléchissez maintenant à la façon dont vous construirez un service tel que FriendFeed, où le flux de chaque utilisateur est mis à jour en temps réel. Le seul moyen possible est que chaque utilisateur ait une connexion active au serveur à tout moment. Le moyen le plus simple de le faire à l’heure actuelle est de faire de longues interrogations.

L’interrogation longue incite essentiellement HTTP à se comporter comme une connexion persistante: dès le chargement de la page, une requête Ajax est envoyée au serveur, même si la page ne veut rien en particulier. Mais contrairement à une requête Ajax normale, le serveur ne répond pas immédiatement. Il attend simplement et renvoie une réponse uniquement lorsqu’il a quelque chose de nouveau à afficher. Par exemple, dès que l’un de vos amis ajoute une nouvelle publication, le serveur renvoie la réponse en demandant au navigateur de mettre à jour son affichage. Dès que le navigateur reçoit la réponse, il renvoie une autre demande. De cette façon, le navigateur attend toujours qu’un nouvel événement se produise côté serveur.

Maintenant, réfléchissez à ce que cela signifie pour un serveur Web traditionnel comme Apache. Pour chaque utilisateur connecté au site, votre serveur doit conserver une connexion ouverte. Chaque connexion nécessite un processus et chacun de ces processus passera le plus clair de son temps à rester inactif (consommation de mémoire) ou à attendre que la requête de la base de données soit terminée. Cela signifie qu’il est difficile d’évoluer jusqu’à un nombre élevé de connexions sans vous arrêter presque et utiliser toutes vos ressources.

Alors quelle est la solution? C’est ici que certains jargons d’avant entrent en jeu: spécifiquement non bloquants et événementiels. La signification de ces termes dans ce contexte est moins compliquée que vous pourriez le craindre. Pensez à un serveur non bloquant comme une boucle: il continue à tourner en rond. Une requête arrive, la boucle la saisit, la transmet à un autre processus (comme une requête de base de données), établit un rappel et continue sans interruption, prête pour la requête suivante. Il ne reste pas assis à attendre que la base de données revienne avec les informations demandées.

Si la requête de la base de données revient, très bien, nous traiterons la question de la même manière: envoyez une réponse au client et continuez à lire en boucle. Il n’ya théoriquement aucune limite quant au nombre de requêtes que vous pouvez attendre sur la base de données, ni au nombre de clients ayant des demandes en attente, car vous ne perdez pas de temps à les attendre. Vous les traitez tous à leur rythme, et c’est ce que veut dire événement: le serveur réagit uniquement lorsqu’un événement se produit. Cela peut être une requête, un fichier en cours de chargement ou une requête en cours d’exécution - cela n’a vraiment aucune importance.

Pour ce faire, FriendFeed utilise un framework non bloquant écrit en Python, appelé Tornado. Le serveur Web nginx se comporte également de cette manière. Cependant, Node.js a un atout: parce qu’il utilise JavaScript (il tourne sur le moteur V8 ultra-rapide de Google), il n’a jamais à s’inquiéter de savoir si une requête envoyée à un autre morceau de code pourrait bloquer la boucle. La raison en est que JavaScript est intrinsèquement piloté par les événements. Pensez-y: lorsque vous écrivez du code JavaScript pour le navigateur, vous ne faites que joindre des gestionnaires d’événements et des callbacks. C’est ainsi que le langage a été conçu.

Node.js en est encore à ses balbutiements. Par conséquent, si vous souhaitez écrire une application à partir de cette application, vous devez procéder à un codage de niveau assez bas. Mais avec l’arrivée imminente de WebSockets dans les navigateurs de la prochaine génération (éliminant ainsi la nécessité de longues interrogations), ce type de technologie deviendra de plus en plus important sur le Web. J’espère vous avoir incité à commencer à déconner et à comprendre ces concepts.