Qu'est-ce que “node core” par rapport à “userland” en Node.js

Comprendre pourquoi il y a des modules du cœur de l'écosystème et des modules satellites. Une traduction de l'article What is node core versus userland

Classé dans Pour commencer

Traduction

De temps en temps, dans les discussions sur les listes de diffusion Node.js et les canaux IRC, vous pouvez entendre parler du “node core” (ou cœurd/noyau de Node.js) et de l'“userland” (ou espace communautaire de Node.js).

Bien sûr, traditionnellement, les termes “userland” ou “userspace” font référence à tout ce qui se trouve en dehors du noyau du système d'exploitation. Dans ce sens, Node.js lui-même est un programme “userland” pour un système d'exploitation.

Cependant, dans le contexte de Node.js, le “node core” fait référence aux modules natifs (en JavaScript) et aux interfaces externes (C, C++...) qui sont compilés dans Node.js. En général, ils permettent d'accéder à des fonctionnalités de bas niveau dont l'utilité fait consensus, dont presque tous les programmes de mise en réseau auront besoin : TCP, HTTP, DNS, le système de fichiers (File System), les processus enfants (child processes), et quelques autres choses. Si quelque chose est suffisamment sophistiqué pour être discuté, il y a de fortes chances qu'il ne fasse pas partie du “node core”. HTTP est aussi couvert que possible, et s'il n'était pas aussi populaire, il ne ferait certainement pas partie du cœur de Node.js.

Il y a également certaines choses dans le noyau de Node.js qui sont tout simplement trop pénibles à faire sans un environnement JavaScript, ou qui ont été créées pour mettre en œuvre certaines constructions de la nomenclature qui ne font pas partie du langage JavaScript, mais qui pourraient tout aussi bien en faire partie (par exemple, setTimeout, setInterval et console).

Tout le reste fait parti de l'“userland”. Cela inclut : npm, express, request, coffee-script, les clients mysql, les clients redis, et ainsi de suite. Vous pouvez souvent installer ces programmes en utilisant npm.

La question de savoir ce qui est proprement du “node core” et ce qui appartient à l'“userland” est un champ de bataille constant. En général, Node.js est basé sur la philosophie selon laquelle il ne devrait pas être livré avec des « piles incluses ». Il est plus facile de déplacer les choses hors du “node core” que de les déplacer dedans, ce qui signifie que les modules de base doivent continuellement « payer un loyer » en termes de fourniture de fonctionnalités nécessaires que presque tout le monde trouve précieuses.

C'est une bonne chose

L'un des objectifs de la bibliothèque noyau minimale de Node.js est d'encourager les gens à implémenter des choses de manière créative, sans imposer leurs idées à tout le monde. Avec un noyau minuscule et un espace utilisateur dynamique, nous pouvons tous nous épanouir et expérimenter sans le fardeau onéreux de devoir être toujours d'accord, tout le temps.

Userland n'est pas moins

Au contraire, c'est plus. Construire une fonctionnalité dans l'“userland” plutôt que dans le “node core” signifie que :

• Vous avez beaucoup plus de liberté pour itérer sur l'idée.
• Tous ceux qui veulent votre module peuvent l'installer assez facilement (si vous le publiez avec npm).
• Vous avez la liberté de briser les conventions de Node.js si cela a du sens pour votre cas d'utilisation.

Si vous pensez que quelque chose doit vraiment faire partie de l'ensemble des bibliothèques de base de Node.js, vous devriez quand même le construire comme un module ! Il y a beaucoup plus de chances qu'il soit intégré au “node core” si les gens ont la chance de voir vos grandes idées en action, et si ses principes de base sont itérés, polis et testés dans le monde réel.

Modifier une fonctionnalité qui est incluse dans le “node core” est très coûteux. Nous le faisons parfois, mais ce n'est pas facile, et cela comporte un risque élevé de régressions. Il est préférable d'expérimenter à l'extérieur, puis de l'intégrer au “node core” une fois qu'elle est stable. Une fois qu'il est utilisable en tant que paquet “userland”, vous pouvez même trouver qu'il est moins essentiel à “node core” que vous ne le pensiez au départ.