10

現在取り組んでいるプロジェクトについて調査するために、Derby.jsとMeteorについて読み始めました。多くのリアルタイム機能を使用しているため、どちらも便利に見えます。しかし、私にはいくつかの大きな懸念があり、現時点でそれらを使用する意味があるかどうか疑問に思っています.

  1. 彼らはまだ生産準備が整っていますか? それとも、重大なセキュリティ上の問題がまだありますか?
  2. それらは現在、セッションと認証をサポートしていますか?
  3. 多くの作業を行うフレームワークに依存することで、単純なものは簡単になるかもしれませんが、もう少し複雑になるとはるかに難しくなるという仮定は正しいですか?
  4. Express + Socket.io（またはexpress.io）を使用するだけで（ユーザーエクスペリエンスの観点から）まったく同じ効果を達成でき、より多くの時間/作業を投資する必要があるという仮定は正しいですか？

現時点では、Express + Socket.io の方が魅力的で、Derby と Meteor は少し誇大宣伝されていると思います。どう思いますか？

私が計画していることをよりよく理解するには：

  • ユーザー認証が必要です
  • 複雑なルーティングが必要
  • SEOが問題
  • Elasticsearch を使用した全文検索
  • DB おそらくMongoDB
  • オブジェクト間の複雑な関係
  • リアルタイム更新 (Socket.io)
  • セキュリティが問題
  • パフォーマンスとスケーラビリティが問題です。

ありがとう！

4

3 に答える 3

20

meteorに関する質問にお答えします。

  1. はい。私たちの多くは、収益を生み出す企業のために本番環境で meteor を実行しています。

  2. はい。Meteor には2012 年 10 月からアカウントシステムが導入されています。

  3. システムがユーザーに代わって処理を行うほど、根底にあるメカニズムを操作するのが難しくなります。流星は適度なバランスを取っていると思います。

  4. この仮定は正しいです。独自の Web ブラウザーを実装して HTTP を視覚化することもできますが、chrome を使用する方が簡単だと思います。

その他の要件

  • ユーザー認証: はい、上記を参照してください。

  • 複雑なルーティング: はい、iron-routerとflow- router を参照してください。

  • SEO: はい(?)、spiderableとssrおよびこの投稿を参照してください。

  • Elasticsearch: はい (フレームワークの選択とは関係ありません)。Meteor には ES バックエンドがありませんが、node.js モジュールを介して、または HTTP 経由で直接 ES データストアと通信できます。

  • MongoDB: はい、これが meteor のデフォルト (かつ唯一の公式) DB です。

  • 複雑な関係: はい (フレームワークの選択とは関係ありません)。

  • リアルタイム更新: はい、これが meteor の仕組みです。

  • セキュリティが問題です: はい、エミリー・スタークがカバーします! また、discover metetor ブログのこの投稿も参照してください。

  • パフォーマンスとスケーラビリティ: oplog-tailing を使用し、 kadiraでアプリを監視します。

于 2014-09-29T23:58:22.130 に答える
15

Meteor の回答があり、 Derbyにもあるはずです。

  1. はい、バージョン 0.6 から Derby は十分に安定しており、実稼働環境で使用しているサイトがいくつかあります (例: Lever ) 。

  2. はい、いくつかの認証モジュールがあります。例:パスポートを使用するderby-login

  3. はい。ただし、モジュール化されたフレームワーク (交換部品で構成されている) が多く、規則 (npm、Express など) に準拠しているほど、それを感じなくなります。

  4. はいといいえ。たとえば、リアルタイムに真剣に取り組んでいる場合は、何らかの競合解決メカニズム (OT や CRDT など) を用意したほうがよいでしょうが、それを実装するのは簡単なことではありません。ちなみに、Meteorには何もありません。LWW戦略を使用しています。

その他の要件

  • ユーザー認証: はい、いくつかのモジュールがあります。

  • 複雑なルーティング: はい、同形の Express のようなルーターです。

  • SEO: はい、ビルトイン同形 (クライアントおよびサーバー) テンプレート エンジン。最初のリクエストの HTML はサーバーでレンダリングされ、後続の URL 変更ではクライアントでレンダリングされます。

  • Elasticsearch: はい、もちろんです。それはフレームワークの問題ではありません。

  • MongoDB: はい、それ用のアダプターがあり、現時点ではこれが最良の選択です。

  • 複雑な関係: はい、フレームワークの問題ではありません。

  • リアルタイム更新: はい、OT を使用します。

  • セキュリティが問題です: はい。サーバーの観点から見ると、Derby は単なる Express です。これらすべてのリアルタイム通信を保護するには、いくつかのアクセス制御モジュールを使用します。例: share-access

  • パフォーマンスとスケーラビリティ: はい、テストはありませんが、理論的には Derby は Meteor よりもスケーリング時のパフォーマンスが高いはずです。確認のようなものがあります。

Meteorはどうですか、Derbyの前に使っていました。優れたドキュメント、チュートリアル、サポート、およびマーケティングがあります。小さなアプリを 5 分でブートストラップできるのは良いことです。クライアント上のデータベース、同形コード、リアルタイムなどの概念を理解するのは良いことですが、非常にモノリシックで柔軟性がありません。リアルタイムを実装する方法は非常に単純ですが、競合の解決に欠けており、パフォーマンスに問題があります。賢明な方法でオフラインに使用することはできません。ほとんどの Derby 開発者は Meteor 出身です。

両方を試して、選択してください。幸運を！

于 2014-10-01T15:49:46.357 に答える
3

@David Weldon からのほぼすべての回答に同意しました。考慮すべき点がいくつかあります。複雑な関係とスケーラビリティです。

オブジェクト間の複雑な関係についておっしゃる場合、MongoDB が適切な選択であるかどうか疑問に思っています。すべてのデータはドキュメントに保存されるため、相互の関係が少ないCollectionsほど良いです。

スケーラビリティについては、上で述べたように、かなり「リレーショナル」なコレクション (多対多など) がいくつかある場合、将来、深刻なスケーラビリティの問題に遭遇する可能性があります (厳しい教訓が得られました)。

本当にそうするなら、Meteor が他の RDBMS を正式にサポートするまで待つべきです。

于 2014-10-01T12:40:49.770 に答える