EventMachine vs Node.js

Ответ 1

EventMachine не имеет ничего общего с Rails, кроме того, что они оба написаны на одном языке. Вы можете получить EventMachine как голый как Node.js; все, что вам нужно сделать, это не добавлять библиотеки в ваш проект. По моему опыту библиотеки EventMachine (например, em-http) намного лучше, чем что-либо для Node. И вы можете использовать волокна вместо обратных вызовов, чтобы избежать аддонов обратного вызова. Полная обработка исключений практически невозможна в Node из-за всех обратных вызовов. Плюс Ruby - более удобный, более полный язык, чем Javascript.

Ответ 2

Я склонен к "использованию того, что вы знаете" (даже если это более тяжелая архитектура). Из-за этого я не вижу, чтобы это было так просто, как "EventMachine vs NodeJS". В основном различие можно суммировать следующим образом:

• NodeJS - это фреймворк/язык, который был написан для обработки событийного программирования в JavaScript. Это его движущая сила. Это не мысль, или сторонний механизм. Он испек прямо на языке. Вы создаете обратные вызовы/события, потому что это то, как язык построен. Это не сторонний подключаемый модуль и не изменяет ваш рабочий процесс.
• EventMachine - это драгоценный камень в Ruby, который дает разработчикам доступ к некоторым из преимуществ модели программирования на основе событий. Он широко используется и хорошо протестирован, но не испечен непосредственно на языке. Оба заблокированы для одного процессора, но с программированием событий в ядре Nodes он все еще имеет ногу. Ruby не был написан с учетом concurrency.

Тем не менее, технические проблемы могут быть преодолены. Более важные вопросы (с моей точки зрения), которые должны руководствоваться вашим решением, следующие:

• Как будет выглядеть ваша производственная среда? У вас есть полный контроль над сервером? Можете ли вы принять его, как хотите? Или это будет с общей системой, с которой вы начинаете, и тогда вам нужно расширять ее?
• У всех разработчиков вашей команды есть возможность быстро изучить новый язык? Насколько быстро они смогут понять язык, основанный на событиях, например JavaScript для среднего уровня?
• Вам нужна вся архитектура, которую Rails дает вам (полная платформа тестирования, строительные леса, модели, контроллеры и т.д.)? Или это перебор?

Существует немало технических различий между ними. Один из них - это язык, один из которых является основой. Действительно, насколько тяжелый стек вы хотите запустить? Сколько обучения ваши разработчики должны сделать? Вы хотите, чтобы полный стек дал вам много тонкостей, которые вы не можете использовать, или вы хотите, чтобы готовые кости были созданы очень быстро и одновременно, хотя вам, возможно, придется писать дополнительный код плиты котла и узнать новый lanugage?

В то время как Rails не так сильно, как некоторые архитектуры веб-приложений, вам по-прежнему потребуется больше мощности процессора, чем вы бы справлялись с аналогичной пропускной способностью в NodeJS. Предполагая код качества для обеих систем. Плохой код, написанный в любом стеке, будет препятствовать свету стека. Это действительно сводится к тому, что вы действительно хотите научиться совершенно новому способу делать что-либо или использовать свое текущее понимание Ruby, чтобы быстро разрядить вещи?

Я знаю, что это не окончательный ответ, но я надеюсь, что это поможет вам принять решение!

Ответ 3

Одна вещь, о которой стоит упомянуть, - это история производства. EM, как и большинство вещей в стойке, имеет множество доступных для тестирования и мониторинга инструментов, которые хорошо протестированы, тогда как Node.js в этом отношении недостаточно.

На момент написания кажется почти невозможным получить четкие показатели из Node для ответа на такие вопросы, как "Нужно ли масштабировать". Есть варианты, начинающие формироваться там от таких, как Joyent, и всегда аргумент roll-your-own, но нигде рядом с такими инструментами, как NewRelic.

Node.js очень хорош с точки зрения производительности/конфигурации, но лично я бы не принимал его в процессе производства.

Ответ 4

Node.js

Вы получаете гораздо лучший контроль над низким уровнем контроля над тем, что происходит. Вы можете включить общие библиотеки для построения поверх node.js, чтобы настроить уровень абстракции по своему вкусу. Например, вы можете использовать connect или express в зависимости от того, хотите ли вы, чтобы для вас был создан движок просмотра. Вы можете использовать socket.io или теперь в зависимости от того, сколько вы хотите, чтобы ваше клиент-серверное соединение было абстрагировано. Вы можете включить любую из многочисленных библиотек MVC или написать свой собственный.

Event-машина

Асинхронная библиотека ввода-вывода, аналогичная node.js

Это сводится к предпочтению Ruby vs JavaScript, насколько гибкой вы хотите с абстракциями или отсутствием абстракций и хотите ли вы использовать node как ваш фактический веб-сервер.

Ответ 5

подробный взгляд на путаницу уже был предложен... просто личное мнение

[] node.js будет лучше, если вы готовы учиться и экспериментировать больше, чем думаете, потому что:

• Механизм потока является удивительным (вдохновлен тем, что "erlang" )

• вы можете создать целевой сервер (легко), который будет действительно продуктивным