Meteorアプリケーションのプロジェクト構造を改善するための開発者ガイド

過去数年間で、利用可能なJavaScriptフレームワークの数が劇的に増加しました。 実証済みのAngularJSから毎月出てくるフレームワークのスコアに至るまで、選択できる印象的な多様性があります。 数年前に私の注意を引いたのは、Meteorと呼ばれるフレームワークです。 ほとんどのフレームワークとは異なり、MeteorはJavaScriptアプリ開発のための完全なプラットフォームになることを目指しています。 Meteorを初めて使用する場合は、Webサイトで確認することをお勧めします。 この記事はMeteorの紹介ではありません。 代わりに、Meteorプロジェクトに構造を導入するためのいくつかの簡単な方法を探ります。

Meteorの大きな利点の1つは、複雑なJavaScriptアプリケーションのプロトタイプを非常に簡単に作成できることです。 Meteorは、フロントエンドのテンプレートとレンダリングのハイブリッドであり、MongoDB（統合ソリューション）と対話するノードベースのサーバーと組み合わされているため、フルスタックWebアプリの作成に必要な初期設定のほとんどは既に完了しています。 ただし、これが提供する開発の容易さは罠になる可能性があります。 Meteorアプリを構築するときに、悪い習慣に陥り、構造化されていないコードがごちゃ混ぜになってしまうのは簡単です。 これを回避する方法についていくつか提案があります。

足場：Meteorの管理可能なディレクトリ階層

まず、アプリケーションを構築するときに、推奨されるフォルダー構造を維持することが重要です。 Meteorを使用すると、デフォルトでプロジェクトフォルダー内の任意の場所にファイルを配置できます。必要に応じて、すべてのコードを1つのファイルにまとめることもできます。 これはハッカソンプロジェクトでは機能する可能性がありますが、通常の本番レベルのスケーラブルなアプリがもたらす複雑さは、健全な構造がなければ管理が困難です。

この問題を解決するには、ChrisMatherのnpmパッケージアイアンをチェックすることをお勧めします。 パッケージにはさまざまな構成オプションがあるため、ここで説明するのは難しいでしょうが、一般に、次のようなプロジェクト構造を構築します。

 my-app/ |- .iron/ |- config.json |- bin/ |- build/ |- config/ |- development/ |- env.sh |- settings.json |- app/ |- client/ |- collections/ |- lib/ |- stylesheets/ |- templates/ |- head.html |- lib/ |- collections/ |- controllers/ |- methods.js |- routes.js |- packages/ |- private/ |- public/ |- server/ |- collections/ |- lib |- methods.js |- publish.js |- bootstrap.js

ただし、一部のプロジェクトでは、このようなフォルダーとファイルの構造はやり過ぎになる可能性があります。 すべてのプロジェクトで、コレクション、メソッド、およびサーバー上の公開コードを分離して、このようなきめ細かいレベルの編成を行う必要はありません。 プロジェクトのサイズが大きすぎない場合、または単に別のnpmパッケージをインストールして学習する必要がない場合は、次の基本的なフォルダー構造をお勧めします。

重要な要素は、ファビコンやその他の静的アセットなどのファイルを含むパブリックフォルダーと、クライアントフォルダー、共通フォルダー、サーバーフォルダーです。 クライアントフォルダーとサーバーフォルダーには、（もちろん）クライアントとサーバーでそれぞれ実行されるコードが含まれている必要があります。 共通フォルダーには、クライアントとサーバーの両方がアクセスできる必要があるコードが含まれています。 この例はスキーマコードです。これについては後で説明します。

最下位レベルの編成を実行するには、2つの方法があります。1つはファイルの種類による方法で、もう1つは機能による方法です。 ファイルタイプ別の整理とは、たとえば、client / templatesフォルダーに、JavaScriptファイル用、CSS用、HTML用の3つのフォルダーがあることを意味します。 HTMLフォルダーには、Login.html、Main.htmlなどのすべてのテンプレートHTMLファイルが含まれます。 JavaScriptフォルダーとCSSフォルダーには、それぞれそのタイプのテンプレートファイルが含まれます。 一方、機能による編成とは、ファイルが具体化する概念によって編成することを意味します。 たとえば、クライアント/テンプレートには、アプリのログインプロセスに関連付けられたすべてのJavaScript、CSS、およびHTMLファイルを含む「Login」フォルダーがあります。 特定のファイルやコードの一部をどこで見つけることができるかをより明確にできるので、機能ごとに整理することをお勧めします。 ただし、これは純粋に白黒ではなく、ほとんどの個人やチームは、ファイルやフォルダーを構造化するために、これらの方法をいくつか組み合わせて使用​​しています。

スキーマ：データベースが必要としない場合でも、アプリはそれを必要とします

私が議論したい2番目の種類の構造はデータベースに関連しています。 この記事は、MongoDBを使用していることを前提としています。 そうでない場合でも、概念はおそらく適用されますが、詳細は適用されません。 MongoDBを使用している人は、MongoDBを使用すると、データを非構造化して保存できることを知っています。 MongoDBはNoSQLドキュメントストアデータベースであるため、データの「タイプ」に固定されたスキーマはありません。 この自由は、すべてのオブジェクトが何らかの厳密な形式に標準化されていることを確認する必要がないことを意味します。実際、必要に応じて、アプリのすべてのデータを1つのコレクションにスローできます。 ただし、本番品質のアプリを作成する場合、これはそれほど望ましいことではありません。 これを管理し、書き込み要求の検証などの便利な機能を追加するために、AldeedのSimpleSchemaとCollection2という2つのすばらしいMeteorパッケージを使用できます。

SimpleSchemaパッケージを使用すると、その名前が示すように、アプリ内のオブジェクトを事後的に検証できます。 GitHubのドキュメントを確認してください。 Collection2パッケージはSimpleSchemaからブートストラップし、Meteorコレクションに適切なスキーマをもたらすことができます。 これにより、スキーマがアタッチされたコレクションへのクライアント側およびサーバー側の書き込み要求の自動検証が可能になります。 これらのパッケージはどちらも非常に深くカスタマイズ可能であるため、いくつかの段落でそれらを完全に理解することは困難です。 むしろ、Aldeedが詳細についてまとめた詳細なreadmeを確認することをお勧めします。 これらのパッケージからどのように価値を得たかについて簡単に説明します。 彼らが可能にした最高のことの1つは、ユーザーのフォーム入力の検証でした。 これは、（アカウントパッケージからの）Meteorユーザードキュメントを検証するのに便利です。 デフォルトでは、Meteorユーザーは驚くほど複雑な暗黙のスキーマを持っています。 これは、Aldeedがとても親切に利用できるようにしたコードからのその一部の写真です：

 Schema.UserProfile = new SimpleSchema({ firstName: { type: String, optional: true }, lastName: { type: String, optional: true }, birthday: { type: Date, optional: true }, gender: { type: String, allowedValues: ['Male', 'Female'], optional: true }, organization : { type: String, optional: true }, website: { type: String, regEx: SimpleSchema.RegEx.Url, optional: true }, bio: { type: String, optional: true }, country: { type: Schema.UserCountry, optional: true } });

これは、単にユーザーのプロファイルオブジェクトのスキーマです。 SimpleSchemaのような専用パッケージがないと、すべてのUserオブジェクトを検証しようとすると混乱します。 これらのフィールドはすべて画像ではオプションのように見えますが、適切に検証されたユーザースキーマが必要な場合は、おそらくそうではなく、「Schema.UserCountry」などは実際に検証のために他のスキーマにリダイレクトされます。 このスキーマをUserオブジェクトにアタッチし、これをフォームにリアクティブに統合することで、おそらくAldeedのAutoFormのようなパッケージを使用して、データベースに含めるものと行わないものを細かく制御できるため、時間と労力を節約できます。アプリケーションでデータがどのように処理されるかの概念モデルであり、具体的な用語で指摘および議論することができます。

役割：401および403の場合

Meteorプロジェクトを構築および改善するための最後の提案は、AlanningのRolesパッケージです。 これはMeteorの認証システムであり、Webアプリの任意の部分のユーザーアクセスレベルを確認できます。 権限は、ユーザーがクライアントに公開されたMeteorメソッドまたはデータにアクセスしようとしたときに後で検証または無効化される文字列の形式でユーザープロファイルに添付されます。 例えば：

 if (Roles.userIsInRole(Meteor.userId(), "admin")) { tabsArr.push({ name: "Users", slug: "users" }); }

システムのコアは比較的単純ですが、アプリケーションの任意の部分に対して複雑できめ細かい権限を与えることができます。 すべての役割は文字列として保存されるため、「admin」、「admin.division1.manage」、「admin.division1.manage.group2」など、好きなだけ深いシステムをセットアップできます。

このパッケージが可能にする自由の問題は、非常にきめ細かい役割システムを追跡するのが難しい場合があることです。 このパッケージは、名前が示すように、作成したすべての役割を取得する「getAllRoles」などの関数を提供しますが、それらのすべての意味が何であるか、および特定の役割がいつ必要になるかを追跡するのはあなた次第です。利用される。 そして、「役割」と「許可」の違いが何であるかを知りたい人にとって、このパッケージの目的のために、それらは本質的に違いはありません。

まとめ

残念ながら、記事の幅が広いため（ここで説明する各パッケージは独自のチュートリアルに値します）、特定のパッケージについて詳しく説明することはできませんでしたが、「標準化された」に向けてどのように取り組むことができるかを明らかにしたいと思います。 」自信を持って使用できるMeteorアプリケーションは、本番環境でも大規模でもうまく機能します。 詳細については、私が投稿したリンクを確認し、この記事に到達しなかったものの、Meteorアプリに含めると便利なRestivusパッケージを確認してください。アプリのRESTAPIを簡単に公開します。

免責事項として、私はこれらのパッケージの作成者ではありません。パッケージの機能または目的のいずれかを誤って伝えた場合は、お詫び申し上げます。 読んでいただきありがとうございます。この記事がお役に立てば幸いです。 ご不明な点がございましたら、お気軽にご連絡いただくか、下にコメントを残してください。