nodemon et pnpm : deux modules Node.js indispensables

nodemon et pnpm : deux modules Node.js indispensables

Parmi bien d'autres

Avatar de l'auteur
David Legrand

Publié dans

Logiciel

07/08/2020 9 minutes
39

nodemon et pnpm : deux modules Node.js indispensables

Dans les semaines et mois à venir, nous allons vous parler de Node.js. Cet environnement d'exécution JavaScript côté serveur sera en effet à la base de certains projets que nous détaillerons dans de prochains articles. L'occasion pour nous d'évoquer certains outils annexes pouvant simplifier la vie des développeurs.

En 2009, Ryan Dahl décidait d'utiliser le moteur JavaScript de Chromium (v8) non plus pour exécuter du code côté client, mais côté serveur. D'en faire un environnement d'exécution pour pallier les manques des solutions de l'époque, à mi-chemin entre Java et Python. Une petite révolution, critiquée pour son aspect « JS partout », au succès indéniable.

Node.js est maintenu par l'OpenJS Foundation.

JavaScript, roi du Web

Il faut dire que, tout critiquable qu'il soit, JavaScript est un langage simple à apprendre (mais dur à réellement maitriser), qui a su évoluer dans le bon sens ces dernières années. Ainsi, dès 2010, le gestionnaire de paquet npm était créé pour accompagner la tendance. Désormais, les deux compères sont partout. 

La multiplication des chaînes YouTube dédiées et autres « formations » auto-proclamées montre à quel point le sujet intéresse. Il faut dire que Node.js et npm ont accompagné la transformation du web ces dix dernières années, que ce soit à travers l'évolution d'ECMAScript (le standard qui sert de base à JavaScript), la montée en puissance d'Angular, React ou Vue. Et de manière plus générale, les méthodes de développement web qui sont de plus en plus modulaires.

En 2020, créer un site débute souvent par un paquet npm. C'est notamment ce qui a poussé Microsoft à transformer .Net en .Net Core pour en faire une solution open source (licences MIT/Apache 2) et multiplateforme, installable aussi bien sur un serveur classique qu'un Raspberry Pi. Le projet est d'ailleurs géré désormais par une fondation dédiée où Microsoft n'est pas seul. Ce qui n'a pas empêché l'entreprise d'acheter npm en mars dernier à travers GitHub

Nous avons déjà eu l'occasion de vous présenter un projet exploitant Node.js par le passé, pour créer une application pouvant être packagée sous la forme d'un exécutable. Nous allons bientôt l'utiliser pour différents projets, nous voulions donc vous présenter certains des outils que nous utiliserons et qui peuvent vous faciliter la vie.

Commençons par nodemon et pnpm

Commençons avec une petite application

Pour suivre ce guide, il vous faudra bien entendu avoir installé Node.js sur votre système. Il est disponible pour Linux, macOS et Windows 10. Il vous faudra également un éditeur (IDE). Nous utiliserons Visual Studio Code, mais vous pouvez très bien lui préférer Atom, Notepad++, WebStorm ou même vim. Le fonctionnement sera le même.

Certaines des commandes tapées seront spécifiques à Windows 10, pensez à les adapter si vous êtes sous Linux/macOS.

Une fois tout en place, on créé un répertoire nodemonTest puis on l'ouvre dans l'IDE. Dans notre cas cela revient à taper les deux commandes suivantes, mais vous pouvez aussi le faire depuis l'Explorateur de fichiers : 

mkdir nodemonTest
cd nodemonTest
code .

Il faut ensuite initialiser le projet depuis le terminal de l'IDE (CTRL+MAJ+ù) :

npm init

Cela consiste à lui donner un nom, une description, des mots-clés, un numéro de version, des informations sur l'auteur, le dépôt GitHub, le point d'entrée, la licence, etc. Le tout enregistré dans un fichier package.json. Vous pouvez laisser les paramètres par défaut en pressant la touche Entrée à chaque question ou en utilisant cette commande :

npm init -y

N'hésitez pas à modifier ces paramètres comme bon vous semble, à la création ou plus tard dans le fichier package.json. Gardez simplement index.js comme point d'entrée. Il faut d'ailleurs créer ce fichier (CTRL+N) et l'enregistrer (CTRL+S). On peut alors commencer à y taper du code, par exemple pour l'habituel « Hello, World ! » :

console.log("Hello, World !")

Enregistrez le fichier puis tapez la commande suivante dans le terminal pour l'exécuter :

node index.js

Créer un serveur web en Node.js : rien de plus simple !

Imaginons maintenant que vous souhaitez non pas afficher ce texte dans la console, mais au sein d'une page web. Avec Node.js, rien de plus simple. Il suffit de modifier le code comme suit :

const http = require("http");
const port = 8080;

http.createServer((req, res) => {
res.end("Hello, World !");
}).listen(port)

Il faut alors enregistrer le fichier, puis taper à nouveau la commande ci-dessus dans le terminal. Cela créé un serveur web accessible via le port 8080 de la machine. Vous pouvez y accéder via le lien suivant : 

http://localhost:8080

Ajoutons un message dans la console pour indiquer que le serveur est lancé, avec un lien direct vers celui-ci pour y accéder d'un simple CTRL+clic dans le terminal. Il faut modifier le code ainsi : 

const http = require("http");
const port = 8080;

http.createServer((req, res) => {
res.end("Hello, World !");
}).listen(port, () => {
console.log (`Le serveur écoute à l'adresse suivante : http://localhost:${port}`)
})

Vous devriez commencer à comprendre le problème : à chaque modification il faut couper le serveur précédemment démarré (CTRL+C), enregistrer le fichier (CTRL+S) puis taper à nouveau la commande pour lancer la nouvelle version.

C'est là que nodemon peut venir à votre secours.

nodemon : un gain de temps pour les petits projets

Car si de nombreux framework/bibliothèques telles qu'Angular, React ou Vue proposent (nativement ou non) une mécanique de type Hot (Live) Reload, il n'est pas toujours nécessaire de se reposer sur de telles briques. Car elles impliquent l'installation d'un grand nombre de dépendances/modules et une taille minimale importante du projet. 

nodemon fait au plus simple et permet de lancer votre application tout en surveillant l'état des fichiers du dossier courant. Lorsqu'ils sont enregistrés, l'application est automatiquement redémarrée. Vous pouvez donc modifier votre code et simplement enregistrer le ou les fichiers du projet (CTRL+S ou CTRL+K S), il sera directement relancé.

Il s'agit d'un paquet npm, il vous suffit donc de l'installer comme suit :

npm install -g nodemon

Cela permet une installation dite globale, pour que nodemon soit exploitable depuis n'importe quel projet Node.js. Si vous préférez vous limiter à celui en cours, installez-le comme une dépendance de développement : 

npm install --save-dev nodemon

Une fois l'opération effectuée, il n'y a plus qu'à le lancer. Notez que vous pouvez demander l'ajout d'un délai avant la relance de l'application, ce qui permet par exemple d'avoir le temps d'enregistrer différents fichiers. Il est aussi possible d'effectuer une relance manuelle en tapant rs puis sur la touche Entrée dans le terminal.

nodemon index.js
nodemon --delay 10 index.js // 10 secondes d'attente
nodemon --delay 2500ms index.js // délai en millisecondes

La documentation complète de nodemon se trouve par ici.

Attention, sous Windows il peut y avoir un problème puisque les commandes ci-dessus pourront chercher à lancer le script nodemon.ps1 si vous utilisez un terminal PowerShell (ce qui est le cas par défaut sous Visual Studio Code). Mais sans modification, l'exécution de scripts tiers n'est pas autorisée. Vous avec alors trois possibilités :

  • Utiliser la commande nodemon.cmd plutôt que nodemon
  • Supprimer le fichier nodemon.ps1
  • Autoriser l'exécution de scripts tiers

Dans ce dernier cas, il faut lancer la commande suivante dans le terminal PowerShell :

Set-ExecutionPolicy -Scope "CurrentUser" -ExecutionPolicy "RemoteSigned"

Gagnez de l'espace disque avec pnpm

S'il s'est bien amélioré ces dernières années, le gestionnaire de paquets npm est critiqué pour de nombreux aspects. C'est d'ailleurs son manque de performances/rapidité qui avait poussé Facebook à créer yarn pour lui faire concurrence.

Mais il y a un autre point qui peut poser problème : si différents projets partagent de mêmes dépendances, vous allez stocker les paquets individuellement dans chacun d'entre eux. Autant dire que si vous avez régulièrement des applications qui partagent les même modules, nécessitant plusieurs dizaines/centaines de Mo, votre stockage va vite réduire.

C'est dans cette optique que pnpm a été créé. Il se veut ainsi plus rapide que npm ou yarn (dans sa version classique ou plug n' play) et plus efficace en termes d'utilisation de l'espace disque. Tous les modules sont installés dans un espace unique auquel vos projets Node.js accèdent, ils n'ont ainsi pas besoin d'être retéléchargés.

L'installation passe par la même méthode que nodemon :

npm install -g pnpm

Vous pouvez ensuite télécharger un paquet comme d'habitude, en remplaçant npm par pnpm. Par exemple pour Express :

pnpm install express

Si vous créez un second projet Node.js après cette commande et que vous la tapez à nouveau, Express sera mis en place mais sans qu'aucun nouveau fichier ne soit téléchargé. Ce qui sera clairement indiqué :

 pnpmpnpm

Dans la pratique, comme on peut le voir ci-dessus, un lien symbolique (junction) est créé dans le répertoire node_modules, menant aux modules placés dans le dossier .pnp_store de celui de l'utilisateur. 

Vous pouvez également ajouter un paquet au « store » local de pnpm, en voir la liste et les supprimer intégralement. En effet, contrairement à npm, lorsqu'un paquet est supprimé, il est en réalité gardé dans l'espace local, pouvant être réutilisé directement pour d'autres projets jusqu'à sa suppression définitive :

pnpm store add 
pnpm store status
pnpm store prune

Les commandes utilisables par npm le sont par pnpm. C'est également le cas pour npm qui permet d'exécuter un paquet. Il dispose également de son équivalent : pnpx.

39

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

JavaScript, roi du Web

Commençons avec une petite application

Créer un serveur web en Node.js : rien de plus simple !

nodemon : un gain de temps pour les petits projets

Gagnez de l'espace disque avec pnpm

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (39)


Sympa de voir ça ici !



Peut être que ça manque de détail sur le lien entre node et npm. Expliquer rapidement les versions de node et que npm est installé defacto avec node car c’est le gestionnaire de paquet par défaut pour node. Un débutant aura peut être du mal à comprendre pourquoi on lui parle de node puis de taper npm init 



Aussi n’hésitez pas à glisser un mot sur nvm qui permet d’installer plusieurs version de node, de switcher de l’une à l’autre et surtout d’avoir un répertoire global pour les paquets ailleurs que le vrai global qui demande les droits root. Ça permet de faire du npm -g sans sudo et sans péter son fs parce qu’un coup c’est du root donc on change les droits pour aller vite et faire crade, ou un coup ça ne marche plus parce qu’on n’est pas root… bref tout en local avec un user local :)


Tout ça pour éviter d’utiliser F5 <img data-src=" />

Très bon tuto merci <img data-src=" />


Merde, même NI se met à NodeJS… On est définitivement foutu.


Après des années de lecture assidue du brief, des incipits des articles et des commentaires (pour essayer de comprendre de quoi cause la suite de l’article), j’ai finalement cédé et ai fini par prendre un abonnement et créer un compte.

&nbsp;

Ce n’est pas l’offre à 1 € qui m’a séduit, ni la V7 béta dont l’URL n’est volontairement pas mentionnée dans son article (heureusement, on la trouve dans les commentaires), ni même les très bons articles et tutos du moment qui ont fini par me motiver, mais l’oisiveté au boulot en cette période estivale qui correspond aussi aux vacances du brief, au moment où j’ai le plus besoin de contenu ! ;)



Petites interrogations cependant : dans les paramètres du comptes nous sommes tenus de choisir entre “un homme” et “une femme” sans que je comprenne la nécessité de ce traitement de données à caractère personnel ni sa finalité. Si je pouvais ajouter une suggestion, je rajouterais le choix “un champignon” qui est bien plus gender-friendly et surtout renforce notre sentiment de vie privée préservée.



Idem, il m’a fallu un moment pour comprendre comment revenir sur NXI depuis la page de gestion du compte : un clic sur le logo renvoie sur la page de gestion du compte mais pas sur la home, ce qui est assez problématique.



Merci pour votre taf et n’hésitez pas à censurer ce commentaire HS si besoin est. Je me rends bien compte que l’endroit n’est pas adapté pour ces remarques mais je n’ai pas su où les poster.

BISOUS








dada051 a écrit :



Merde, même NI se met à NodeJS… On est définitivement foutu.





Bah techniquement les sites sont sur Angular… <img data-src=" />







Vaark a écrit :









Merci <img data-src=" />



Ce n’est pas trop l’endroit pour ça, mais le gestionnaire de compte va évoluer après la mise en ligne de la v7, donc ce seront des points traités à ce moment-là <img data-src=" /> Et vive l’oisiveté ;)



PS : pour la v7 l’URL est dans le billet d’annonce depuis un moment maintenant <img data-src=" />



<img data-src=" />


Je me demande qui télécharge le plus internet, entre un NodeJS ou un Maven <img data-src=" /> Avec un projet Node et qques dépendance, on se retrouve vite avec 23000 fichiers et une centaine de méga. Essayer donc le Node Starter de Microsoft <img data-src=" />

Et si on ajoute Docker, on brule la planète. On part de qques centaines de Ko de source, puis une bonne centaines de Mo de modules à condition d’avoir pris soin de bien gérer les paquets pour finir avec 300Mo d’image Docker, qui installée sur 60 serveur, nous donne un joli 18Go à chaque mise à jour.

Et on nous demande d’être éco-responsable et d’éviter les pièces jointes de 1Mo et plus dans les courriels <img data-src=" />


Et on package le tout dans un Electron ? <img data-src=" />


En python, on a virutalenv et consort (conda). A chaque script projet, tu télécharges tous plein de paquets (bon, d’un autre coté, ça permet d’avoir les bonnes version de chaque paquet dans ton cocktail de paquet).


L’avenir de JS runtime c’est Deno <img data-src=" />








spidermoon a écrit :



On part de qques centaines de Ko de source, puis une bonne centaines de Mo de modules à condition d’avoir pris soin de bien gérer les paquets pour finir avec 300Mo d’image Docker, qui installée sur 60 serveur, nous donne un joli 18Go à chaque mise à jour.

Et on nous demande d’être éco-responsable et d’éviter les pièces jointes de 1Mo et plus dans les courriels <img data-src=" />



Il y a … longtemps … en Delphi 3 on faisait des petites applis en moins d’1Mo (genre 300ko tout inclut, aucune DLL). Déjà à l’époque Ms poussait à utiliser des DLL de quelques Mo.



Mais déjà à l’époque, je ne connaissais que l’assembleur pour produire un exécutable plus petit que les sources.



Actuellement, les applis Android, pour afficher parfois quelques messages (moins de 1000 caractères…) pèsent 50Mo, mis à jour régulièrement (plus régulièrement que les coms de la mairie).



&nbsp;Maintenant, en environnement serveur, rien ne t’empêche de partager le support et d’avoir une seule fois 300Mo d’image plus des disques de différence, non? (déjà fait avec Windows: 1 image Windows de 20Go et x serveurs “légers”&nbsp; qu’on remplace après un certain nombre de màj)





Cet environnement d’exécution JavaScript côté serveur sera en effet à la

base de certains projets que nous détaillerons dans de prochains

articles.





Ce teaser manque de vitamines.

Je veux bien suivre tout ça mais si c’est afficher un Hello world dans la console, bof bof. Il va falloir en dire plus pour donner envie de se lancer <img data-src=" />


Toi t’as envie que je refasse l’Altice Stock Checker en Node <img data-src=" />


Je dis pas non, elle était sous Windows donc je me suis senti frustré de ne pas pouvoir participer <img data-src=" />

&nbsp;


&gt; “S’il y a d’autres paquets Node.JS ou pour d’autres langages/runtimes qui vous aident régulièrement, n’hésitez pas à nous le faire savoir dans les commentaires.”



Puisque vous demandez… TypeScript est franchement génial et permet de gommer beaucoup de défauts de javascript. IMHO l’un des languages les mieux conçus.


C’est ce que je fait pour la mise à jour de la base, avant j’avais 300Mo de conteneur avec les outils pour la base + le script de màj. Maintenant c’est une fois les outils et un conteneur Alpine avec le script. C’est nettement mieux <img data-src=" />


Non mais si on fait du TS on se met à Angular et je vois au quotidien les ravages que ça fait sur PA. Je ne souhaite ça à personne <img data-src=" />


Pour ceux qui débarquent, petit déchiffrage des acronymes (même si ça peut paraître évident pour certains).

NPM : Node Package Manager

NVM: Node Version Manager (de tête, peut-être pas exactement ça).



Sinon…

“Une petite révolution, critiquée pour son aspect&nbsp;« JS partout », au succès indéniable.”

Certes, mais ni pour la qualité du langage (même si ça progresse vite et régulièrement), ni pour la simplicité&nbsp;(bon, Java, passons… <img data-src=" /> mais PHP et Python sont très simples d’approches).



Ce qui explique la montée en puissance foudroyante de NodeJS, c’est le miroir aux alouettes que ça a créé pour les Ressources Humains de toutes les boîtes, le Graal du “développeur qui sait tout faire” (alors que la vérité est qu’il&nbsp; peut -potentiellement- tout faire).

Le fameux développeur “full stack”…



Qui certes peut exister, mais à condition d’avoir déjà un bon paquet d’années sous la ceinture (sauf qu’un développeur expérimenté n’aura en vrai aucun mal à s’approprier un nouveau langage par ailleurs mais passons).&nbsp;

Un junior même talentueux aura encore énormément de réflexes à acquérir en conception et écriture pour réellement assumer un projet.&nbsp;

Une fois ce palier atteint, effectivement pouvoir tout gérer dans le même langage présente un certain confort, notamment pour le prototypage. :)



Reste que depuis l’émergence de Node JS, plein de boîtes embauchent plus ou moins n’importe qui “full stack” à condition qu’il mette plein de mots clés correspondant aux frameworks à la mode ces temps ci, et pas tant que ça sont celles qui prennent le temps de vérifier le code réellement produit par le passé (quoique ça change avec les années).


Et en plus de node.js, allez voir du côté de NodeRed. Pour l’IoT et associé à une solution de domotique comme Home Assistant, c’est vraiment super pratique. Et pour le coup, même pas besoin d’apprendre le javascript :)

&nbsp;


Je confirme, NodeRed est vraiment intéressant pour gérer sa solution de domotique sans être “enfermé” dans du Jeedom ou autre. J’ai remplacé mes scripts node.js par une jolie interface nodered


Même si je suis globalement d’accord, NodeJS a tout de même un certain mérite à mon avis, c’est d’avoir été l’un des premiers (le premier?) à populariser les non-blocking i/o et la programmation asynchrone, basée sur une event loop. Peut-être à la base surtout pour palier à l’absence de multi-threading, mais ça s’est avéré un choix payant et on a vu ce choix repris par la suite dans d’autres langages, notamment via Vert.x en Java par exemple.


Hum de mon point de vu ce n’est pas le premier, c’est quelque chose qui se fait depuis très longtemps, je dirais même que ce principe existait déjà au prémisse de l’informatique et plus spécifiquement en électronique (avec la gestion des intéruptions hardware notamment).



Au niveau du JS ce qui était nouveau c’est que par conception de language fonctionne dans une boucle évenementielle contrairement aux autres language (je n’en connais d’ailleurs pas d’autres équivalent)
ce qui fait que toute la logique de développement peu être dédier au traitement de l’évenementiel.
C’est aussi un des points qui fait que nativement un moteur js ne peut pas planter, car il traite uniquement des évenements un par un et si un plante il passe juste au suivant.


Loin de moi l’idée de nier les avantages ou démocratisations de paradigmes de programmation qu’a apporté NodeJS (ne serait-ce que parce que je suis expert ni en Javascript ni en NodeJS).&nbsp;



Je faisais référence au phénomène plus général de croyance répandue notamment chez les RH (ce que au demeurant on ne saurait trop leur reprocher vu que ce ne sont pas des profils techniques généralement) que parce que a) Untel “maîtrise” (le mot qui veut tout et rien dire) Javascript et que b) NodeJS est en Javascript -&gt; D’un coup le mec est compétent pour écrire des applis de A à Z.



Alors que en vrai, le plus souvent, non. <img data-src=" /> Tout simplement parce que le langage n’est qu’un outil, ce qui importe c’est la qualité et la complétude de conception autant sur la fiabilité et le respect des processus métier que sur la manière de les exposer aux utilisateurs.* Et ça, n’en déplaise aux RH, ce sont des compétences distinctes que tout le monde n’a pas forcément l’occasion d’apprendre à moins d’avoir effectivement mené des missions “des deux côtés”.&nbsp;



Ce qui implique au passage l’aspect que tout le monde semble découvrir depuis 10 ans (voire nettement moins dans certaines entités ahem*), la qualité de code éprouvée par des tests automatisés, la granularisation des process,&nbsp; l’exposition sous forme d’API documentées et la remontée d’informations de supervision, tous besoins essentiels à prendre en compte dans la conception. Mais c’est un autre combat, que de toute manière tout développeur sérieux est prêt à entendre, mais hélas voué à la défaite tant que ceux qui détiennent les cordons de la bourse a) n’ont pas le profil technique (donc par principe considèrent qu’on fait du chantage au perfectionnisme) changent tous les 3 ans max (donc partis avant de pouvoir constater et admettre que les techos avaient 100% raison…).


juste pour chipoter ^^

Doc Node.js&nbsp;server.listen([port[, host[, backlog]]][, callback])&nbsp;



&nbsp;- port &lt;number&gt;       






 Donc ca sera plus exact sans les doubles quote&nbsp; :       

const http = require("http");

&nbsp;const port = 8080;






Même si ca marche aussi avec la String "8080"       






 &nbsp;Apres java script, le typage fort toussa&nbsp;<img data-src=">  

&nbsp;Vive TypeScript, vive Java ^^






 &nbsp;

Oui, my bad et merci pour le coup d’œil. Corrigé :chinois:








David_L a écrit :



Non mais si on fait du TS on se met à Angular et je vois au quotidien les ravages que ça fait sur PA. Je ne souhaite ça à personne <img data-src=" />





Hé, respect. C’est pas donné à tout le monde de faire de l’Angular : … il faut une sacrée bécane pour compiler ton appli si tu vas plus loin qu’un Hello World. Et surtout va pas demander pourquoi aux devs d’Angular : tu l’utilises probablement mal et t’y comprends rien. Quoi ? La compilation de ta modeste appli prend 8go de RAM ? Ah ça « c’est normal et on arrive pas à reproduire ».



Message pour PA : tu n’es pas seul.




jotak a dit:


Même si je suis globalement d’accord, NodeJS a tout de même un certain mérite à mon avis, c’est d’avoir été l’un des premiers (le premier?) à populariser les non-blocking i/o et la programmation asynchrone, basée sur une event loop. Peut-être à la base surtout pour palier à l’absence de multi-threading, mais ça s’est avéré un choix payant et on a vu ce choix repris par la suite dans d’autres langages, notamment via Vert.x en Java par exemple.




Tiens, je viens d’apprendre que Javascript est à la base monothread.
Mais si c’est monothread, comment tu gères les requêtes en NodeJS ? Elle ne sont pas exécutées dans des threads indépendants ?



Dans le même genre, en plus fourbe, il y a le Multithreading en Python (cPython plus exactement, qui est l’interpréteur Python par défaut). Le Multhreading existe en Python, sauf que l’accès au variable est soumis à un locker unique (GIL) pour l’ensemble des variables : à un instant donné, il ne peut y avoir qu’un seul thread qui lit ou écrit des variable. Ca réduit du coup très vite l’intérêt du truc (en gros uniquement à des opérations qui implique beaucoup d’attente d’accès au ressources et très peu de temps pour les traiter). Le Multiprocessing existe, mais du coup, le partage de variables entre les process passe par un socket et une sérialisation (il faut donc que tes variables soient sérialisables)


Le code javascript n’est exécuté que par un seul thread. Tu ne traites donc jamais plusieurs requêtes de façon concurrente. Par contre tu n’est pas obligé d’attendre la fin du traitement d’une requête pour commencer à traiter la suivante, en particulier si tu utilises certaines opération lentes (requête http, en BDD, lecture de fichier…).
Les opérations lentes sont gérés via un mécanisme de callback : tu lances l’opération (par exemple une requête http), et tu demandes à nodejs de lancer le callback quand il aura la réponse.
Par exemple si ton traitement se fait en 2 étapes séparées par une phase asynchrone, tu pourras avoir un ordre d’exécution du type:




  • requête 1: exécution de l’étape 1, mise en attente d’une opération asynchrone

  • requête 2: exécution de l’étape 1, mise en attente d’une opération asynchrone

  • requête 1: exécution de l’étape 2, envoi de la réponse

  • requête 2: exécution de l’étape 1, envoi de la réponse



Elles ont d’une certaine manière été traitées en parallèle, mais dans le même thread.



Ça c’est le fonctionnement basique, tu peux toujours faire des threads si tu en a besoin (par exemple pour faire un calcul lourd sans bloquer le traitement des requêtes http suivantes), mais c’est des cas d’usage spécifiques.



Edit: si tu as déjà fait du dev front, c’est dans l’esprit assez similaire à ce que tu fais pour faire des opérations longues dans le navigateur sans figer l’interface: tu ne fais rien de bloquant, et tu récupères les résultats via des callbacks.


Zerdligham

Le code javascript n’est exécuté que par un seul thread. Tu ne traites donc jamais plusieurs requêtes de façon concurrente. Par contre tu n’est pas obligé d’attendre la fin du traitement d’une requête pour commencer à traiter la suivante, en particulier si tu utilises certaines opération lentes (requête http, en BDD, lecture de fichier…).
Les opérations lentes sont gérés via un mécanisme de callback : tu lances l’opération (par exemple une requête http), et tu demandes à nodejs de lancer le callback quand il aura la réponse.
Par exemple si ton traitement se fait en 2 étapes séparées par une phase asynchrone, tu pourras avoir un ordre d’exécution du type:




  • requête 1: exécution de l’étape 1, mise en attente d’une opération asynchrone

  • requête 2: exécution de l’étape 1, mise en attente d’une opération asynchrone

  • requête 1: exécution de l’étape 2, envoi de la réponse

  • requête 2: exécution de l’étape 1, envoi de la réponse



Elles ont d’une certaine manière été traitées en parallèle, mais dans le même thread.



Ça c’est le fonctionnement basique, tu peux toujours faire des threads si tu en a besoin (par exemple pour faire un calcul lourd sans bloquer le traitement des requêtes http suivantes), mais c’est des cas d’usage spécifiques.



Edit: si tu as déjà fait du dev front, c’est dans l’esprit assez similaire à ce que tu fais pour faire des opérations longues dans le navigateur sans figer l’interface: tu ne fais rien de bloquant, et tu récupères les résultats via des callbacks.


OK, du coup, tu utilises de la programmation événementielle pour libérer le thread (tu libères la mains au prochain events qui se pointe).



Mais du coup, ça veut dire que tu gère toutes les requêtes de toutes les sessions dans un seul et unique thread ? ça ne risque pas de faire exploser le temps de traitement lorsque plein de client balancent des requêtes en même temps et que la charge est importante ? On ne peux pas exploiter les CPU multicœur d’un serveur.


tazvld

OK, du coup, tu utilises de la programmation événementielle pour libérer le thread (tu libères la mains au prochain events qui se pointe).



Mais du coup, ça veut dire que tu gère toutes les requêtes de toutes les sessions dans un seul et unique thread ? ça ne risque pas de faire exploser le temps de traitement lorsque plein de client balancent des requêtes en même temps et que la charge est importante ? On ne peux pas exploiter les CPU multicœur d’un serveur.


C’est un des inconvénients de node, c’est plutôt simple en apparence mais pour faire une prod performante, il faut respecter un certain modèle de déploiement, qui en retour impose des normes en termes de code. (sauf que le dev inexpérimenté ne les découvrira qu’après, quand il faudra deboguer la perf de sa prod, car le modèle de développement ne donne pas un cadre strict qui amènerait aux bonnes pratiques “naturellement”)



Comme il n’y a effectivement qu’un seul thread qui exécute le code js (en vrai il y a quelques autres threads de contrôle qui trainent), pour exploiter correctement la puissance dispo il faut




  • s’assurer que chaque module, individuellement, rende régulièrement la main à l’event loop.

  • faire tourner plusieurs process node sur la machine, que l’OS pourra répartir sur les coeurs (pour simplifier on dit souvent “un coeur -> un worker process” mais en réalité chaque cas est différent et ça demande de mesurer et d’optimiser en faisant des tests de charge)



Le point 1 implique de bien connaître le fonctionnement de l’event loop de node (parce qu’en réalité tous les “events” ne se valent pas, il y a plusieurs priority queues en-dessous.), le point 2 implique de respecter des normes de code qui permettent de réorganiser facilement la chaine d’exécution (en rendant chaque endpoint métier le plus indépendant possible) de façon à pouvoir croître horizontalement sans souci.
Ce qui veut dire plus de complexité niveau architecture et plus de consommation mémoire.



Ce sont des points qu’il faut connaître à l’avance quand on veut se lancer dans un projet node avec un objectif de croissance. (ou juste quand on veut être sûr de tirer le meilleur parti de la techno).


FennNaten

C’est un des inconvénients de node, c’est plutôt simple en apparence mais pour faire une prod performante, il faut respecter un certain modèle de déploiement, qui en retour impose des normes en termes de code. (sauf que le dev inexpérimenté ne les découvrira qu’après, quand il faudra deboguer la perf de sa prod, car le modèle de développement ne donne pas un cadre strict qui amènerait aux bonnes pratiques “naturellement”)



Comme il n’y a effectivement qu’un seul thread qui exécute le code js (en vrai il y a quelques autres threads de contrôle qui trainent), pour exploiter correctement la puissance dispo il faut




  • s’assurer que chaque module, individuellement, rende régulièrement la main à l’event loop.

  • faire tourner plusieurs process node sur la machine, que l’OS pourra répartir sur les coeurs (pour simplifier on dit souvent “un coeur -> un worker process” mais en réalité chaque cas est différent et ça demande de mesurer et d’optimiser en faisant des tests de charge)



Le point 1 implique de bien connaître le fonctionnement de l’event loop de node (parce qu’en réalité tous les “events” ne se valent pas, il y a plusieurs priority queues en-dessous.), le point 2 implique de respecter des normes de code qui permettent de réorganiser facilement la chaine d’exécution (en rendant chaque endpoint métier le plus indépendant possible) de façon à pouvoir croître horizontalement sans souci.
Ce qui veut dire plus de complexité niveau architecture et plus de consommation mémoire.



Ce sont des points qu’il faut connaître à l’avance quand on veut se lancer dans un projet node avec un objectif de croissance. (ou juste quand on veut être sûr de tirer le meilleur parti de la techno).


OK.



Pour le premier point, il faut relativement bien embrasser la programmation événementielle. J’imagine que le principe de base et de libérer dès que l’on fait un appel aux entrée/sortie (lecture de fichier, requête SQL…) et d’attendre le message. Mais est-ce qu’il faut pousser le vis au point de transformer des boucles très couteuses en fonctions récursives ?



Pour le second point, si tu as plusieurs instance Node.js, elle font toutes tourner les mêmes services ? donc il faut quelque chose qui distribue les requêtes vers ces instances, non ? Faut-il une instance ‘front” qui se charge de gérer une pile de requêtes ou il y a un truc qui gère ça de lui même ?


tazvld

OK.



Pour le premier point, il faut relativement bien embrasser la programmation événementielle. J’imagine que le principe de base et de libérer dès que l’on fait un appel aux entrée/sortie (lecture de fichier, requête SQL…) et d’attendre le message. Mais est-ce qu’il faut pousser le vis au point de transformer des boucles très couteuses en fonctions récursives ?



Pour le second point, si tu as plusieurs instance Node.js, elle font toutes tourner les mêmes services ? donc il faut quelque chose qui distribue les requêtes vers ces instances, non ? Faut-il une instance ‘front” qui se charge de gérer une pile de requêtes ou il y a un truc qui gère ça de lui même ?



J’imagine que le principe de base et de libérer dès que l’on fait un appel aux entrée/sortie (lecture de fichier, requête SQL…)




oui, après ça c’est “fourni” par la base library (tous les modules qui permettent l’accès aux fichiers ou au réseau ont une interface qui va soit prendre une fonction de callback en paramètre soit renvoyer un objet Promise). La base library fournit aussi un objet EventEmitter pour pouvoir faire ses events custom, ainsi que des mécaniques pour gérer les streams.
Et depuis un certain temps il y a également la syntaxe async (pour déclarer une fonction comme asynchrone, ce qui fait qu’elle renvoie automatiquement une promise) + await (pour indiquer un point où l’exécution nécessite le résultat d’un ou plusieurs processes asynchrone, et donc indiquer au main thread qu’il peut passer la main en attendant). Node suit les évolutions du langage JS.
Je ne sais pas où ça en est mais le comité technique avait fini par accepter d’ajouter des threads lights, donc quand ce sera finalisé (si c’est pas déjà le cas) ça changera encore probablement la donne et les recos.




Mais est-ce qu’il faut pousser le vis au point de transformer des boucles très couteuses en fonctions récursives ?




C’est du cas par cas, et ça évolue. Au début de node, c’était pas mal conseillé, maintenant, on conseillera plutôt de mettre les traitements potentiellement bourrins dans leur propre process (qui vivra dans un pool, et sera appelé de façon asynchrone par le process qui reçoit les requêtes), ou de combiner les deux techniques. Tout va dépendre de la fréquence et de la criticité, il n’y a pas vraiment de cas général. Un autre souci étant que pendant longtemps, la pile d’exécution asynchrone était horriblement tracée (pas tracée en fait…), ce qui rendait le debug particulièrement atroce. C’est mieux maintenant avec async/await, mais il y a encore des cas pourris quand on mélange les différents constructs asynchrones.




Pour le second point, si tu as plusieurs instance Node.js, elle font toutes tourner les mêmes services ? donc il faut quelque chose qui distribue les requêtes vers ces instances, non ? Faut-il une instance ‘front” qui se charge de gérer une pile de requêtes ou il y a un truc qui gère ça de lui même ?




ça va pas mal dépendre de la typologie de service ou d’application. Node est un process applicatif, pas obligatoirement un serveur http. Un process peut spawner des sous-process avec qui il partagera des ressources. Il y a un module “cluster” disponible de base qui permet un load balancing (round robin ou custom) intégré (https://nodejs.org/api/cluster.html). Donc sur des cas “simples” tout peut se gérer au sein d’un process node. Il y a des produits commerciaux qui font ça aussi. (et qui généralement vont aussi offrir le monitoring des processes, l’auto-restart, etc).
En fait il n’est pas rare de commencer la vie d’une appli en montant tous les endpoints sur un node en mode cluster, puis de mettre un système d’auto-scaling rudimentaire (plusieurs clusters + un load balancer), puis d’aller séparer les services pour mieux répartir la charge une fois qu’on peut mesurer avec du vrai trafic, etc. Le fait de coder “de base” pour le support du cluster fait qu’il devient relativement simple de réorganiser l’ensemble.
Mais là encore, on est sur des choses qui évoluent, avec le développement (relativement) récent des containers, du “serverless” (FaaS), des bases distribuées à la FaunaDB ou CockroachDB, etc, on peut s’attendre à ce que les best practices continuent de changer.


tazvld

OK, du coup, tu utilises de la programmation événementielle pour libérer le thread (tu libères la mains au prochain events qui se pointe).



Mais du coup, ça veut dire que tu gère toutes les requêtes de toutes les sessions dans un seul et unique thread ? ça ne risque pas de faire exploser le temps de traitement lorsque plein de client balancent des requêtes en même temps et que la charge est importante ? On ne peux pas exploiter les CPU multicœur d’un serveur.


Un seul thread par process, mais il y a la possibilité de créer plusieurs processde node & répartir la charge entre eux pour scaler sur une machine multicoeur.
Il y a par contre des limites à comment les process communiquent entre eux. J’ai jamais essayé mais j’imagine que faire du statefull peut être pénible, c’est plus à comparer avec de la scalabilité à plusieurs serveurs.



(reply:15808:Citan666) merci :)




aussi ça a déjà été dit, mais nvm c’est aussi une bonne pratique si on gère plusieurs projet avec des verision de nodes potentiellement différentes, mais rien que pour la mise a jours des projets c’est intéressant.


Pour ça tu mettras plusieurs instances qui exploitent peu de cpu. (Scalling horizontal) :)


J’ai rien compris, ni ce que que Node.js c’est ni a quoi ça sert.
Je vois laisse à vos programmes et bidouilles, je suis trop vieux pour ces âneries.
Vague idée de JavaScript mais là aussi je sais pas ce que c’est.
Moi j’ouvre un lien web, je cherche pas à savoir comment ça marche.
Je fais un site web, bah prestashop pour une boutique, Joomla pour le reste.
Facile et zéro programmation



wackyseb a dit:


J’ai rien compris, ni ce que que Node.js c’est ni a quoi ça sert. Je vois laisse à vos programmes et bidouilles, je suis trop vieux pour ces âneries. Vague idée de JavaScript mais là aussi je sais pas ce que c’est. Moi j’ouvre un lien web, je cherche pas à savoir comment ça marche. Je fais un site web, bah prestashop pour une boutique, Joomla pour le reste. Facile et zéro programmation




TL:DR



Javascript était à la base qu’un petit langage pour que l’on puisse faire des modifications simple d’une page web à partir du navigateur sans avoir à charger une nouvelle page (genre un menu qui apparaît ou qui disparaît). Mais en évolution, on s’est mis à faire de plus en plus de chose avec JavaScript au point qu’il est devenu un langage de programmation généraliste. Ainsi, grace à Node.js, JavaScript remplace PHP coté serveur.



Details



Pour résumer l’histoire. Il y a plus de 10ans, pour faire un site web dynamique on utilisait 4-5 langages :




  • coté serveur :


    • PHP(+SQL) pour créer une page dynamiquement coté serveur. Par exemple pour afficher les commentaire à un article, le commentaires étant enregistrer dans la base de donnée SQL, avec PHP on va faire un requête SQL pour récupérer la liste des commentaires et on va créer une page HTML en rajoutant les commentaire (page HTML qui sera alors envoyer au client). En gros, le PHP sert à créer des page HTML.


  • coté client (navigateur):


    • HTML+CSS pour le rendu de la page par le client. C’est la page que reçoit le navigateur.HTML en soit n’est qu’une façon d’écrire le “DOM” (la structure de la page), et CSS va donner des indication de comment mettre en page chaque éléments.

    • JavaScript : pour modifier la page coté client. Parfois, on veut faire des modifications de la page qui ne nécessite pas forcément de charger entièrement une nouvelle page, et on peut demandé au navigateur de petit truc simple (genre afficher ou cacher un élément comme un menu déroulant). Du coup, en plus du HTML et du CSS, on va mettre du code Javascript qui pourra être éxecuté par le navigateur. Le javascript était à la base destiner à ne pas avoir à charger une page complète pour des modifications mineurs.




Pour Joomla (Drupal, Wordpress…) par exemple, si tu regardes, c’est un site écrit en PHP (et SQL), qui va générer des pages web HTML+CSS et avec sûrement un petit peu de JavaScript (pour des menus déroulant, des vérifications de formulaires….). Dans un tel CMS, le code PHP est assez central car toute les pages sont totalement dynamiquement : il n’y a aucune page HTML qui soit statique (déjà écrite), tout est enregistré dans des base de donnée et des fichiers de configurations et il faut que le serveur charge de la base de données les bon éléments, et les colles au bon endroit dans le DOM et produise une sortie HTML.




Petit aparté



En faite, coté serveur, on n’utilise pas uniquement PHP, il y a pas mal d’autre langage comme Java, de C#, de Ruby et de Python. Mais PHP reste le langage historique.




Mais voila, JavaScript a évolué et a commencé à être poussé plus loin. Par exemple on va l’utiliser pour communiquer en tache de fond avec le serveur et récupérer à la voler des petites update et faire les mise à jour (ce que l’on appelle AJAX). C’est par exemple ainsi que fonctionne le scroll infini sur twitter : les tweets son chargés avec javascript du serveur vers le navigateur au fur et a mesure que tu défiles. C’est aujourd’hui pousser au point que par exemple l’actuel version de NextInpact ne charge qu’une seul fois la page complète et quand tu cliques sur un lien, seule une partie de la page est updatée (le corps de la page n’est pas rechargé). On peut même faire des applications complète avec quasiment uniquement javascript (MS Office Online est il me semble quasi entièrement en javascript).



Une idée est alors germé : pourquoi faire encore du PHP alors que JavaScript est un langage viable, complet. En remplaçant PHP par JavaScript, un développeur web n’aurait qu’à apprendre du Javascript pour coder aussi bien coté serveur que coté client : le “full stack” du javascript, du javascript partout, à tout les niveau, javascript sur le serveur, javascript sur le client, dans ta fusée (oui, l’interface utilisateur de CrewDragon est un javascript+HTML)…



Et voici donc Node.js : un serveur JavaScript pour remplacer Apache PHP.




Une autre version de l’histoire du Full-stack par commitStrip




Aujourd’hui, on va même plus loin, si tu combines dans une application un serveur Node.js avec un version aléger d’un navigateur comme Chromium et du code Javscript, tu peux faire une application “stand alone” bureau uniquement. Ca existe, ça s’appelle Electron et c’est permet de faire plein d’application comme par exemple “Discord”, “Skype”, “Twitch Desktop” “GitHub Desktop”, “VisualStudio Code”… L’un des avantage est qu’il est souvent possible de proposer cette application en version Web assez simplement (le code derrière générant en gros un page web).


Un peu de trollage et d’historique (on est plus à un pavé prêt après celui de tazvld ;) ) sur le pourquoi javascript est vu par certains aficionados d’autres languages comme un gadget (pas de typage fort, choix du modèle prototype plutôt que classe, séparateur de ligne point virgule “optionnel” mais en réalité plus complexe que ca avec quelques jolis edge cases WTF, ca soit disante “simplicité” plus une plaie en réalité…) :



Interview du créateur : http://www.journaldunet.com/developpeur/itws/070213-itw-mozilla-eich.shtml




Dix jours pour faire le prototype, puis le reste de l’année passée à l’intégrer au sein de Navigator. Le nom a ensuite été influencé par des accords avec Sun, qui voulait miser sur la réussite de Java sur le Web.



Vous a-t-on demandé de lui donner une syntaxe plus proche de Java, pour plaire à Sun ?
Au début, l’idée était de le faire ressembler à du Basic. Puis ça a été le tour de Oak/Java, le travail avec le navigateur HotJava de Sun et la course pour le finir, tandis que Sun créait de son côté AWT. Avec la frénésie de l’époque, les opinions étaient partagées : n’en faire qu’un Java, n’y mettre que l’essentiel, conserver la déclaration de type…



Mais l’on s’est vite rendu compte que les pages seraient créées par des non-programmeurs, donc qu’on ne pouvait pas imposer la complexité de Java : nous devions élargir l’audience du langage, permettre à tous de l’utiliser, d’écrire et reprendre du code, comme HTML.
En bref, faire ce qu’avait fait Microsoft en ayant d’un côté C++, et de l’autre Visual Basic. Personne ne savait vraiment que faire, le management poussait pour un Java-like tandis que nous voulions simplifier. Le prototype que j’ai créé a convaincu tout le monde




David_L a dit:


Bah techniquement les sites sont sur Angular… <img data-src=" />




Et côté serveur, vous tournez sur quelle techno ? (si on peut savoir bien sûr :incline: )