nodemon et pnpm : deux modules Node.js indispensables
Parmi bien d'autres
Le 07 août 2020 à 12h10
9 min
Logiciel
Logiciel
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 quenodemon
- 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é :
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.
nodemon et pnpm : deux modules Node.js indispensables
-
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
Commentaires (39)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 07/08/2020 à 18h50
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 " />
Le 07/08/2020 à 19h40
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 " />
Le 08/08/2020 à 07h39
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 « 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é (bon, Java, passons… " /> 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 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).
Un junior même talentueux aura encore énormément de réflexes à acquérir en conception et écriture pour réellement assumer un projet.
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).
Le 08/08/2020 à 08h03
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 :)
Le 10/08/2020 à 11h24
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
Le 08/08/2020 à 11h32
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.
Le 10/08/2020 à 09h54
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.
Le 08/08/2020 à 21h06
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).
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 -> D’un coup le mec est compétent pour écrire des applis de A à Z.
Alors que en vrai, le plus souvent, non. " /> 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”.
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, 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…).
Le 09/08/2020 à 01h19
juste pour chipoter ^^
Doc Node.js server.listen([port[, host[, backlog]]][, callback])
Le 10/08/2020 à 12h05
Oui, my bad et merci pour le coup d’œil. Corrigé
Le 09/08/2020 à 12h25
Le 07/08/2020 à 12h30
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
sanssudo
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 :)Le 07/08/2020 à 12h36
Tout ça pour éviter d’utiliser F5 " />
Très bon tuto merci " />
Le 07/08/2020 à 12h43
Merde, même NI se met à NodeJS… On est définitivement foutu.
Le 07/08/2020 à 12h52
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.
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
Le 07/08/2020 à 12h59
Le 07/08/2020 à 13h19
" />
Le 07/08/2020 à 13h33
Je me demande qui télécharge le plus internet, entre un NodeJS ou un Maven " /> 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 " />
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 " />
Le 07/08/2020 à 13h50
Et on package le tout dans un Electron ? " />
Le 07/08/2020 à 14h51
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).
Le 07/08/2020 à 15h04
L’avenir de JS runtime c’est Deno " />
Le 07/08/2020 à 15h05
Le 07/08/2020 à 15h14
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 " />
Le 07/08/2020 à 15h17
Toi t’as envie que je refasse l’Altice Stock Checker en Node " />
Le 07/08/2020 à 15h34
Je dis pas non, elle était sous Windows donc je me suis senti frustré de ne pas pouvoir participer " />
Le 07/08/2020 à 17h54
> “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.
Le 10/08/2020 à 09h30
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 10/08/2020 à 11h46
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:
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.
Le 10/08/2020 à 12h27
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.
Le 11/08/2020 à 12h24
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
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).
Le 11/08/2020 à 12h45
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 ?
Le 11/08/2020 à 13h35
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.
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.
ç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.
Le 12/08/2020 à 10h24
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.
Le 10/08/2020 à 09h39
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.
Le 10/08/2020 à 12h41
Pour ça tu mettras plusieurs instances qui exploitent peu de cpu. (Scalling horizontal) :)
Le 10/08/2020 à 21h09
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
Le 11/08/2020 à 12h25
TLR
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 :
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.
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.
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).
Le 11/08/2020 à 13h25
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
Le 12/08/2020 à 07h46
Et côté serveur, vous tournez sur quelle techno ? (si on peut savoir bien sûr )