Derby.js対 Meteor.js
これら2つのフレームワークはすでに比較されているため、1つのセクションにまとめることにしました。 これらのフレームワークを放棄するときに私にとって決定的に思えた品質のみをリストします。
- どちらも、クライアントとサーバーの両方でJavaScriptを実行し、テンプレートをレンダリングできます。唯一の質問は、クライアントとサーバーを判断する方法です。
- MongoDB（またはDerby.jsの場合はRedis）と統合します。これにより、アプリケーションの範囲が大幅に縮小されます（データソースに依存しない場合は、プロジェクト内のこのようなコードの編成に同意するでしょう）。
- meteor.jsの場合のパッケージ管理システム。
- derby.jsの場合のドキュメントの欠如（「脚がどこから成長するか」を理解する必要がある場合は、コードに入る必要があります）
別々のコンポーネントを使用することは可能ですが、一般的に、ツールは、それらがどれほど称賛され、PRされていても、非常に具体的で完全に命を救う開発者に思えました。
Kraken.js
Kraken.jsは、PayPalによってリリースされた比較的最近のMVCフレームワークであり、npmモジュールとして配布され、アプリケーションのセキュリティと国際化のサポートに重点を置いています。
構図
カーネルに加えて、フレームワークにはさらに4つのモジュールが含まれています。
- Lusca-アプリケーションのセキュリティを担当
- Kappa -npmパッケージ用のローカルプロキシサーバーを実装します
- Adaroは、さまざまな補助ツールを追加するdust.jsテンプレートエンジンのアドオンです
- Makara-テンプレートに国際化サポートを追加
これらのモジュールは互いに独立しており（adaro機能に依存するmakaraを除く）、任意のnode.jsアプリケーションにプラグインして使用できます。
アプリケーション構造
その構造上、アプリケーションはMVCアプリケーションの構造に非常に似ており、機能的な目的に応じてファイルを保存します。
/config - /controllers - /locales - .property- /lib - ( , npm ) /models - /public - web- /public/templates - /tasks - grunt- grunt-config-dir /tests - index.js -
構成
node.jsにはアプリケーションの動的構成を実装できるCommonJSモジュールがありますが、kraken.jsは開発環境と運用環境に2つの.jsonファイルを使用するため、機能が大幅に制限されます。 しかし、これらの制限にもかかわらず、 kraken.jsは、web 開発者の間ですでに人気を博しているexpress.jsフレームワークに基づいています。そのアプリケーションは、index.jsファイルで直接知られている任意のメソッドを使用するか、アプリケーションを構成する自己記述モジュールを使用して構成できます。 さらに、アプリケーションでのミドルウェアの構成を大幅に簡素化する追加のメドウェアモジュールがあります。
ルーティング
ここでは、彼はそうであると言うことができますが、同時に彼はそうではありません。 すべてのルーティングはコントローラーファイルで手動で実行され、その主な機能はルーターオブジェクトへのアクセスを許可され、次のようになります。
module.exports = function (router) { var model = new IndexModel(); router.get('/', function (req, res) { res.render('index', model); }); };
もちろん、これにより構成の柔軟性が向上しますが、フレームワークがまず第一に、プログラマーによって適用される手動アクションの数を減らすように設計されたツールであるとは思いません（腐ったトマトはおそらく私に飛び込むでしょうが、全体的にはそうです）。 アプリケーションが許容可能なサイズまで成長すると、そのようなルーティングでパスを管理することもあまり快適ではなくなります...
モデル
ここで、フレームワークの作成者は、開発者に完全な選択の自由を与えることにしました。事実は、kraken.jsのモデルは独自のプロパティを持つ通常のJavaScriptオブジェクトであるということです。 それで、好きなORMを選択して、npmでインストールしてください！
パターン
不満はありません。 テンプレートエンジンは、一般に、フィルター、ブロックセクション、条件構造をサポートし、開発者に必要なすべてのツールを提供し、クライアントで使用するテンプレートをコンパイルすることもできます。
国際化
翻訳サポートはテンプレートにのみ存在します。これは、テンプレート変数で動的に組み立てられた翻訳文字列を取得して転送することはできないため、サーバー上の機能を大幅に制限します。 さらに、翻訳自体を実行するモジュールは、.propertyファイルの使用に依存しています。このファイルの構成はあまり信頼を集めません。
index.greeting=Hello {name}! index.bye=Bye {name}!
おそらく、単純な文の場合、これは何らかの形で機能しますが、複雑な文の場合に何が起こるか想像してみてください...
Sails.js
Sails.jsは、スケーラブルなリアルタイムアプリケーションを作成するために、 Mike McNeillによって設計および開発されました。
構成
Sails.jsは、他の開発者が作成およびサポートしているnpmモジュールで構築されたカーネルで構成されていますが、その中には非常に興味深いモジュールが1つあります。ORMwaterlineは、半自動モードでデータベース移行を実行し、セイル専用に作成されています、任意のnode.jsアプリケーションに簡単に接続できます。 さらに、コード生成のサポートがカーネルに組み込まれており、 コマンドラインから直接使用できます。 さらに、websocketのサポートが組み込まれているため、ソケットを介して受信したリクエストを通常のリクエストとして処理できます。
アプリケーション構造
構造はMVCアプリケーションに非常に似ており、機能のより詳細な断片化があります。
api/ controllers/ - models/ - policies/ - ... services/ - singleton- assets/ - public config/ - tasks/ config/ - grunt- register/ - grunt- ... views/ - Gruntfile.js - grunt- app.js - .sailsrc -
各ファイルの目的に関する詳細については、 ドキュメントを参照してください。ディレクトリまたはファイルをワンクリックして目的を確認できます。
構成
Sails.jsもexpress.jsに基づいていますが、kraken.jsとは異なり、開発者にアプリケーションオブジェクトへの直接アクセスを提供せず、設定全体は.jsファイルを介して行われます。コアコンポーネント。 このメカニズムにより、データベース構成をHTTPサーバーのセットアップから分離できますが、アプリケーションの特定のプロパティを構成する機能が大幅に制限されます。たとえば、テンプレートがレンダリングされる場所からデフォルトのパスを変更することが困難になりました。 ミドルウェアに関しては、config / http.jsファイルのミドルウェアセクションに配置することで簡単に接続できます。
ルーティング
不満はありません。 ルーティングは、対応するセクションのconfig / routes.jsファイルで目的のパスを指定することで構成され、次のようになります。
module.exports = { 'get /signup': { view: 'conversion/signup' }, 'post /signup': 'AuthController.processSignup', 'get /login': { view: 'portal/login' }, 'post /login': 'AuthController.processLogin', '/logout': 'AuthController.logout', 'get /me': 'UserController.profile' }
このメカニズムは非常に便利で、HTTPメソッドを指定せずに設定を構成し、コントローラーを使用せずにテンプレートを表示し、テンプレートに転送されるデータを指定し、特定のコントローラーメソッドへのユーザーアクセスを許可する前にチェックする必要があるアクセスポリシーを指定できます。
モデル
前述のように、sails.jsには非常に強力なORMが含まれています。これは、多くの有名なデータベースに存在するさまざまなデータソースでのアダプターの使用に基づいています。 モデルは、モデルプロパティをエクスポートするCommonJSモジュールとして表されます。これにより、Waterline.Collectionコレクションの基本クラスがさらに拡張されます。 ORMには、モデルのライフサイクル全体にわたって特定のバリデーターを適用するいくつかの追加タイプのフィールドの組み込みサポートがあります（詳細についてはドキュメントをお読みください）。また、モデルデータの書き込みおよび読み取り時に使用される特定のデータベース接続を各モデルに指定する機能もあります。 これらすべてに加えて、ページネーション、ソート、イベントハンドラーの組み込みサポートがあります。
モデルファイルの典型的な例：
module.exports = { connection: 'disk', attributes: { firstName: { type: 'string', required: true }, lastName: { type: 'string', required: true, } } });
モデル構造に変更が発生すると、ORMは起動時にそれらを自動的に決定し、自動競合解決ができない場合、開発者との対話を行います。
パターン
Sails.jsは、express.jsフレームワークの作成者からconsolidate.jsライブラリのアプリケーションを埋め込むための最も有名なテンプレートエンジンをサポートしています。これにより、アプリケーションでのテンプレートの使用が間違いなく簡素化されます。 選んで使用するだけです！
国際化
sails.js内ではi18nライブラリを使用するため、サーバーコード、テンプレート、.jsファイルのいずれであっても、アプリケーションのライフサイクル全体を通じて、sails.jsに翻訳サポートが存在します。 翻訳自体は.jsonファイルに追加され、まだファイルにないテキストを翻訳しようとするときに自動的に補足されます。 一方で、自動入力はタイムリーな翻訳の問題を引き起こしますが、必要なファイルの内容をスキャンし、翻訳用のすべてのテキストを収集する単調なタスクをいつでも作成できます。
それで、あなたは何を選びましたか？
要約すると、以下の分類表は、5つのポイントシステムに従って、頭の中で形成されました。
| 構成 | ルーティング | モデル | パターン | 国際化 | |
|---|---|---|---|---|---|
| Meteor.js | 3 | 5 | 4 | 4 | 2 |
| Derby.js | 5 | 3 | 4.5 | 3 | 2 |
| Kraken.js | 5 | 2 | 5 | 4 | 3 |
| Sails.js | 4 | 5 | 4 | 5 | 4 |
フレームワークで使用されるプロジェクト構造と、フレームワークが提供する「すぐに使える」機会が精神的に近いため、私の選択がsails.jsに当てはまると推測することは難しくありません。 もちろん、構成と国際化に関して欠点がありますが、フレームワークの概念に従って考えれば、これらは私の場合には調整または実装できる欠点です。 この記事では、どのような場合でも、この楽器またはその楽器に向かって傾くことはありません。精神的にあなたに近いものを自分で選択してください。