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

MeteorFrameworkのプロジェクト構造を改善するための開発者ガイド つぶやき

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のドキュメント 。ザ・ コレクション2 パッケージはSimpleSchemaからブートストラップし、Meteorコレクションに適切なスキーマをもたらすことができます。これにより、スキーマがアタッチされたコレクションへのクライアント側およびサーバー側の書き込み要求の自動検証が可能になります。これらのパッケージはどちらも非常に深くカスタマイズ可能であるため、いくつかの段落でそれらを完全に理解することは困難です。むしろ、Aldeedが詳細のために編集した詳細なreadmeを確認することをお勧めします。これらのパッケージからどのように価値を得たかについて簡単に説明します。彼らが可能にした最高のことの1つは、ユーザーのフォーム入力の検証でした。これは、Meteor Userドキュメント（Accountsパッケージから）を検証するのに便利です。デフォルトでは、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オブジェクトにアタッチし、これをフォームにリアクティブに統合することで、おそらく次のようなパッケージを使用します。 アルディードのオートフォーム 、データベースに含まれるものと含まれないものを細かく制御できるため、アプリケーションでデータを処理する方法の概念モデルを使用して時間と労力を節約できます。このモデルを具体的な用語で示して説明することができます。

役割：401および403の場合

Meteorプロジェクトを構築および改善するための最後の提案は、Alanningの 役割パッケージ 。これは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アプリにあると便利なものをもう1つ見てください。 Restivusパッケージ 、アプリのRESTAPIを簡単に公開できます。

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

関連： Meteorチュートリアル：Meteorを使用したリアルタイムWebアプリケーションの構築