読み書きプログラミング

日常のプログラミングで気づいたことを綴っています

Advent Calendar 2 - autopublishとinsecureパッケージ

Meteorでアプリケーションを作るとき、最初に

meteor create app-name

を実行します。すると、app-nameという名前のフォルダーが生成され、中に必要なファイルやテンプレートが展開されます。
この状態でアプリケーションにはautopublishとinsecureというパッケージが追加されています。プロトタイプを素早く実装して試してみるためです。

autopublishパッケージ

本来、MeteorではデータベースのCollectionをpublishして初めてクライアント側でそのデータが利用可能になります。autopublishパッケージは、データベースのCollectionをすべてpublishするパッケージです。これによりサーバー側でもクライアント側でもデータベースがすべて見えている状態でプログラミングが可能です。動かすのに必要なコードが減るだけでなくデバッグもしやすくなるのでプロトタイプの作成を楽にしてくれます。ですが、アプリケーションを公開する段になると、扱うデータによっては望ましくない状態にあるので、このパッケージは公開前には削除して、必要なデータのみpublishするようコーディングしましょう。

Meteor.publishはどこですべきか。
Meteor.publishで登録する関数はクライアントからsubscribeされて初めて実行されるようです。なので、特にMeteor.startupに渡す関数内で使う必要はなく、直に実行すればよいようです。

insecureパッケージ

本来、Meteorでは、データベースのCollectionのallowメソッドで登録した関数(trueかfalseを返す関数)がtrueを返す条件の場合、データベースへの書き込みを許可します。allowで関数を登録しなければ書き込みはできません
このパッケージはデータベースのCollectionをすべて書き込み可能にするパッケージです。autopublish同様、プロトタイプの作成では楽ですが、すべてのクライアントでデータベースに書き込み可能な状態になるので、公開前には削除して、必要な条件のみallow/denyするようコーディングしましょう。

Collection#allowはどこですべきか。
Collectionのインスタンス化はサーバー、クライアント双方で必要です。なので通常、サーバー、クライアント共通のファイルでインスタンス化されます。Collection#allowはサーバー側で実行するので、ファイルが別になる可能性が高いです。その場合、ファイルの読み込み順序によってはサーバー用ファイルではまだCollectionがインスタンス化されていない場合があるので、Collection#allowはMeteor.startupに渡す関数内で実行しましょう。Meteor.startupに渡された関数はすべてのJavaScriptファイルを読み込んでから実行されます。