30

共同サイトを開発するつもりです。機能の 1 つは、リアルタイムの変更による共同編集です。つまり、2 人以上のユーザーが同じドキュメントを編集している場合、変更が発生するとすぐに互いの変更を確認できます。私は Ruby on Rails の経験があるので、EventMachine を使用することを考えていましたが、Node.js に関するこの誇大宣伝により、代わりに使用することを検討していることはわかっています。では、EventMachine の代わりに Node.js を使用する主な利点は何でしょうか?

tl;dr EventMachine と Node.js の主な違いは何ですか (言語以外)?

4

5 に答える 5

72

EventMachine は、両方が同じ言語で書かれていることを除けば、Rails とは何の関係もありません。Node.js と同じように EventMachine を取得できます。プロジェクトにライブラリを追加する必要はありません。私の経験では、EventMachine ライブラリ (em-http など) は Node.js の何よりも優れています。また、コールバックの代わりにファイバーを使用して、コールバック地獄を回避できます。すべてのコールバックがあるため、Node では完全な例外処理はほとんど不可能です。さらに、Ruby は Javascript よりも優れた完全な言語です。

于 2011-05-21T20:41:23.630 に答える
21

私は「あなたが知っているものを使う」傾向があります（たとえそれがより重いアーキテクチャであっても）。そのため、「EventMachine と NodeJS」という単純なものには見えません。主に、違いは次のように要約できます。

  • NodeJS は、JavaScript でイベント ベースのプログラミングを処理するために作成されたフレームワーク/言語です。それがその原動力です。これは後付けでも、サードパーティのメカニズムでもありません。それは言語に焼き付けられています。それが言語の構築方法であるため、コールバック/イベントを作成します。これはサードパーティのプラグインではなく、ワークフローを変更しません。
  • EventMachine は、開発者がイベント ベースのプログラミング モデルの優れた機能にアクセスできるようにする Ruby の gem です。頻繁に使用され、十分にテストされていますが、言語に直接組み込まれていません。両方とも 1 つの CPU に固定されていますが、ノード コアでのイベント プログラミングにより、まだ優位性があります。Ruby は並行性を念頭に置いて作成されていません。

とはいえ、技術的な問題は克服できます。あなたの決定を導くべきより重要な質問（私の見解から）は次のとおりです。

  • 本番環境はどのようになりますか? サーバーを完全に制御できますか? 好きなようにホストできますか？それとも、最初は共有システム上にあり、それを拡張する必要がありますか?
  • あなたのチームのすべての開発者は、新しい言語をすぐに習得できますか? 中間層向けの JavaScript のようなイベントベースの言語をどのくらいの速さで理解できるでしょうか?
  • Rails が提供するすべてのアーキテクチャ (完全なテスト フレームワーク、足場、モデル、コントローラーなど) が必要ですか? それともやり過ぎですか？

この 2 つにはかなりの技術的な違いがあります。1 つは言語、もう 1 つはフレームワークです。本当に、どのくらい重いスタックを実行したいですか? 開発者はどの程度の学習を行う必要がありますか? 使用しないかもしれない多くの優れた機能を提供するフルスタックが必要ですか、それとも、追加のボイラープレートコードを記述し、学習する必要がある場合でも、非常に高速かつ並行して実行される必要最小限のセットアップが必要ですか?新しい言語？

Rails は一部の Web アプリケーション アーキテクチャほど重くはありませんが、NodeJS で同様のスループットを処理するには、より多くのプロセッサ パワーが必要になります。両方のシステムの品質コードを想定しています。いずれかのスタックに悪いコードが書かれていると、スタックが輝かなくなります。要するに、まったく新しい方法を学びたいですか、それとも現在の Ruby の理解を利用して物事をすぐに軌道に乗せたいですか?

決定的な答えではないことは承知していますが、これが決定に役立つことを願っています!

于 2011-04-04T15:52:38.777 に答える
8

特筆すべきは制作ストーリー。EM は、ほとんどのラック製品と同様に、十分にテストされた利用可能なテスト ツールと監視ツールを多数備えていますが、Node.js はこの点で十分ではありません。

執筆時点では、Node から明確なメトリクスを取得して、「スケーリングする必要があるか」などの質問に答えることはほとんど不可能に思えます。Joyentのようなものから形成され始めたオプションがあり、常に独自の議論がありますが、NewRelicのようなツールに近いものはありません.

Node.js は、パフォーマンス/構成可能性の観点からは非常に優れていますが、個人的にはまだ本番環境でホストするつもりはありません。

于 2011-08-16T10:42:51.417 に答える
3

Node.js

何が起こっているのかについて、低レベルの制御をはるかによく制御できます。一般的なライブラリを含めて、node.js の上に構築し、抽象化のレベルを好みに合わせて調整できます。たとえば、ビュー エンジンを作成するかどうかに応じて、connect または express を使用できます。クライアントサーバー接続をどれだけ抽象化するかに応じて、socket.io または now を使用できます。多数の MVC ライブラリのいずれかを含めることも、独自に作成することもできます。

イベントマシン

node.js のような非同期 IO ライブラリ

最終的には、Ruby と JavaScript のどちらを優先するか、抽象化または抽象化の欠如によってどの程度の柔軟性が必要か、実際の Web サーバーとしてノードを使用するかどうかにかかっています。

于 2011-04-04T16:06:41.473 に答える
-2

混乱の詳細な見解はすでに提案されています... 単なる個人的な見解です

[] node.js は、あなたが思っている以上に学び、実験する準備ができているなら、より良いものになるでしょう:

  • スレッドメカニズムは素晴らしいです（「erlang」のスレッドメカニズムから着想を得ています）

  • 本当に生産的な目的に特化したサーバーを（簡単に）構築できます

于 2011-04-11T06:11:44.200 に答える