Il est particulièrement efficace pour gérer une tonne d'E / S de fichiers et je m'attendrais à ce qu'il gère également une tonne de communications réseau. Il semble particulièrement populaire pour les applications pilotées par socket. La chose importante à garder à l'esprit est que si vos besoins ne sont pas satisfaits par les bibliothèques existantes (il y en a beaucoup), vous devrez peut-être plonger dans du C qui peut être lié aux commandes JS. Vous pouvez également générer des processus Node supplémentaires, mais je soupçonne que faire beaucoup de cela pourrait être taxé (je suppose - pourrait être faux - il y a une instance V8 générée pour chacun d'entre eux).
JS est monothread et bloquant, ce qui signifie que rien d'autre ne peut s'exécuter tant qu'un appel de fonction n'est pas terminé. C'était une fonctionnalité souhaitée de JS, éliminant essentiellement tous les problèmes de threading et de file d'attente. Le JS n'empêche pas les choses C / C ++ de s'exécuter de manière plus multi-thread sous le capot, donc le rôle de JS est vraiment plus architecture / messager. Si vous traitez l'image, vous ne voudrez pas gérer cela avec des commandes JavaScript synchrones, car tout le reste de votre application ou de votre serveur sera bloqué jusqu'à ce qu'il soit terminé. L'idée est que vous appelez une image à traiter par la fonctionnalité C / C ++ liée, puis répondez à l'événement «done» lorsque l'image est terminée en cours de traitement.
Cela nécessite que le JS dans n'importe quelle application Node.js soit fortement piloté par les événements et les rappels, ou il fonctionnera probablement très mal. Vous ne verrez donc pas beaucoup d'appels de méthode dans Node qui ne reçoivent pas de fonction pour une utilisation ultérieure. Une chose qui devient très claire très rapidement dans Node est que vous êtes dans un monde de laid si vous ne trouvez pas un moyen de gérer la pyramide de rappel. par exemple
//event CBs are more DOM-style than Node style and this isn't built-in Node file I/O
//keeping it simple and quick since I'll just get Node stuff wrong from memory
file.get('someFile.txt', function(e){
e.fileObj.find('some snippet', function(e){
someFinalCallBackHandler( e.snippetLocations );
} );
} );
Heureusement, il existe de nombreux outils et exemples pour mieux gérer cela. La plupart ont tendance à tourner autour des mécanismes de promesse et à enchaîner simplement une série de fonctions destinées à répondre aux états de rappel les uns des autres dans un tableau qui fait le truc pyramidal laid pour vous sous le capot.
Personnellement, j'aime énormément que nous obtenions JS au niveau supérieur et C / C ++ plus proche du chrome. C'est le combo ultime et cela m'a inspiré pour commencer à apprendre le C. Et ne laissez pas le manque de potentiel de bibliothèque vous effrayer avant d'avoir fait des recherches. Les bibliothèques de nœuds sont produites à un rythme très rapide et arrivent à maturité très rapidement. Si vous ne faites rien de très inhabituel, les chances sont bonnes que quelqu'un le couvre.
La plus grande différence avec Rails, c'est que JS n'est jamais susceptible d'être sur rails pour ainsi dire. Nous avons tendance à coder pour pouvoir l'avoir comme vous le souhaitez très rapidement, donc il y a la corde pour vous accrocher avec le facteur et l'architecture a été assez bricolage en JS jusqu'à ces dernières années. J'appelle cela la liberté, mais je me rends compte que ce n'est pas considéré comme idéal pour beaucoup de développeurs.
De plus, vous n'aurez jamais de problème de "gemme" dans Node.js car vous avez essayé de l'installer sur autre chose qu'un Mac. Les développeurs Web côté client méprisent les problèmes de dépendance et c'est de là que vient le cœur de Node. Si cela ne fonctionne pas hors de la boîte en 5 minutes ou moins sur chaque plate-forme populaire, nous le froissons généralement et le jetons. Je n'ai pas encore rencontré de module populaire qui exigeait que je fasse quelque chose de spécial pour le faire fonctionner. Le système d'emballage est excellent.
Mais pour répondre à votre question principale de manière plus explicite / succincte: est-ce bon avec les processus d'arrière-plan?
Oui, Node est essentiellement un processus d'arrière-plan avec un moyen de piloter une application via des événements et des rappels.