EventMachine против Node.js

Question

Я собираюсь разработать совместный сайт, и одной из функций будет совместное редактирование с изменениями в реальном времени.т.е. когда два или более пользователей редактируют один и тот же документ, они могут видеть изменения друг друга, как только они происходят.У меня есть некоторый опыт работы с Ruby on Rails, поэтому я думал об использовании EventMachine, но, несмотря на всю эту шумиху вокруг Node.js, я знаю, что стоит вместо этого использовать ее.Итак, каковы основные преимущества использования Node.js вместо EventMachine?

tl; dr Каковы основные различия между EventMachine и Node.js (помимо языка)?

Answer 1

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

Answer 2

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

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

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

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

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

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

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

Answer 3

Стоит упомянуть одну историю производства.EM, как и большинство Rack, обладает множеством доступных инструментов тестирования и мониторинга, которые хорошо протестированы, тогда как Node.js в этом отношении не дотягивает.

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

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

Answer 4

Node.js

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

Event-машина

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

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

Answer 5

подробное представление о путанице уже было предложено ... просто личное представление

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

• это потрясающий механизм потоков (вдохновленный таковым из 'erlang')

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