EventMachine vs Node.js

Question

Je vais développer un site collaboratif, et l'une des fonctionnalités sera l'édition collaborative avec des changements en temps réel. C'est-à-dire que lorsque deux utilisateurs ou plus éditent le même document, ils peuvent voir les changements de chacun dès qu'ils se produisent. J'ai une certaine expérience de Ruby on Rails, et je pensais donc utiliser EventMachine, mais avec tout ce battage autour de Node.js, j'envisage de l'utiliser à la place. Alors, quels seraient les principaux avantages d'utiliser Node.js au lieu d'EventMachine ?

tl;dr Quelles sont les principales différences entre EventMachine et Node.js (outre le langage) ?

Answer 1

EventMachine n'a rien à voir avec Rails, si ce n'est qu'ils sont tous deux écrits dans le même langage. Vous pouvez obtenir EventMachine aussi dépouillé que Node.js ; tout ce que vous avez à faire est de ne pas ajouter de bibliothèques à votre projet. D'après mon expérience, les bibliothèques d'EventMachine (comme em-http) sont bien plus agréables que tout ce qui existe pour Node. Et vous pouvez utiliser des fibres au lieu de callbacks pour éviter l'enfer des callbacks. La gestion complète des exceptions est pratiquement impossible dans Node à cause de tous les callbacks. De plus, Ruby est un langage plus agréable et plus complet que Javascript.

Answer 2

Je tends vers le "utilisez ce que vous savez" (même si c'est une architecture plus lourde). Pour cette raison, je ne pense pas que ce soit aussi simple que "EventMachine vs NodeJS". Principalement, la différence peut être résumée comme ceci :

• NodeJS est un cadre/langage qui a été écrit pour gérer la programmation basée sur les événements en JavaScript. C'est sa force motrice. Il ne s'agit pas d'une réflexion après coup, ou d'un mécanisme tiers. C'est intégré directement dans le langage. Vous créez des callbacks/événements parce que c'est ainsi que le langage est construit. Il ne s'agit pas d'un plug-in tiers, et il ne modifie pas votre flux de travail.
• EventMachine est un joyau de Ruby qui permet aux développeurs d'accéder à certains des avantages du modèle de programmation basé sur les événements. Il est très utilisé et bien testé, mais n'est pas directement intégré au langage. Les deux sont bloqués sur un seul processeur, mais avec la programmation événementielle au cœur de Nodes, il a encore une longueur d'avance. Ruby n'a pas été écrit avec la concurrence à l'esprit.

Cela dit, les problèmes techniques peuvent être surmontés. Les questions les plus importantes (à mon avis) qui devraient guider votre décision sont les suivantes :

• À quoi ressemblera votre environnement de production ? Avez-vous un contrôle total sur le serveur ? Pouvez-vous l'héberger comme vous le souhaitez ? Ou sera-t-il placé sur un système partagé pour commencer, et devrez-vous ensuite l'étendre ?
• Tous les développeurs de votre équipe ont-ils la capacité d'apprendre très rapidement une nouvelle langue ? À quelle vitesse seront-ils capables de comprendre un langage basé sur les événements comme JavaScript pour le niveau intermédiaire ?
• Avez-vous besoin de toute l'architecture que vous offre Rails (cadre de test complet, échafaudage, modèles, contrôleurs, etc.) Ou est-ce excessif ?

Il existe un certain nombre de différences techniques entre les deux. L'un est un langage, l'autre un framework. Vraiment, quelle pile de logiciels voulez-vous utiliser ? Combien d'apprentissage vos développeurs devront-ils faire ? Voulez-vous une pile complète qui vous offre de nombreuses fonctionnalités, que vous n'utiliserez peut-être pas, ou voulez-vous une configuration de base qui fonctionne extrêmement rapidement et de manière simultanée, même si vous devez écrire du code supplémentaire et apprendre une nouvelle langue ?

Bien que Rails ne soit pas aussi lourd que certaines architectures d'applications web, vous aurez tout de même besoin de plus de puissance processeur que pour gérer un débit similaire en NodeJS. Supposer un code de qualité pour les deux systèmes. Un mauvais code écrit sur l'une ou l'autre pile va empêcher la pile de briller. La question qui se pose est la suivante : voulez-vous vraiment apprendre une toute nouvelle façon de faire les choses ou utiliser vos connaissances actuelles de Ruby pour faire décoller les choses rapidement ?

Je sais que ce n'est pas vraiment une réponse définitive, mais j'espère que cela vous aidera à prendre une décision !

Answer 3

Une chose qui mérite d'être mentionnée est l'histoire de la production. EM, comme la plupart des produits Rack, dispose de nombreux outils de test et de surveillance bien testés, alors que Node.js est loin d'être à la hauteur à cet égard.

À l'heure où nous écrivons ces lignes, il semble presque impossible d'obtenir des mesures claires de Node pour répondre à des questions comme "Dois-je changer d'échelle". Il y a des options qui commencent à se former du côté de Joyent, et toujours l'argument du "roll-your-own", mais rien de comparable à des outils comme NewRelic.

Node.js est très bon du point de vue des performances et de la configurabilité, mais personnellement, je ne l'hébergerais pas en production. tout de suite .

Answer 4

Node.js

Vous obtenez un bien meilleur contrôle de bas niveau sur ce qui entre. Vous pouvez inclure des bibliothèques générales à construire au-dessus de node.js pour ajuster votre niveau d'abstraction à votre goût. Par exemple, vous pouvez utiliser connect ou express selon que vous souhaitez ou non qu'un moteur de vues soit écrit pour vous. Vous pouvez utiliser socket.io ou now selon le degré d'abstraction que vous souhaitez pour votre connexion client-serveur. Vous pouvez choisir d'inclure l'une des nombreuses bibliothèques MVC ou d'écrire la vôtre.

Événement-machine

Une bibliothèque d'entrées-sorties asynchrones comme node.js

Tout dépend de votre préférence pour Ruby ou JavaScript, de la flexibilité que vous souhaitez obtenir avec les abstractions ou l'absence d'abstractions et de votre volonté d'utiliser node comme serveur web.

Answer 5

Une vue détaillée de la confusion a déjà été proposée... juste un avis personnel

[] node.js sera meilleur, si vous êtes prêt à apprendre et à expérimenter plus que vous ne le pensez car :

• son mécanisme de fil de discussion est génial (inspiré de celui de 'erlang')

• vous pouvez construire un serveur spécifique (facilement) qui sera réellement productif.