2013-07-16 6 views
5

2つのかなり異なるユースケース(管理者アカウントとユーザーアカウント)を持つMeteorで既存のアプリケーションを書き直しています。どちらも機能面では別々のアプリだと考えられますが、同じバックエンドデータベースを共有しています。Meteorアプリケーションごとに複数(個別/名前空間)のMeteorクライアントコードベース

Meteorがアクセスするクライアントのアセットをパッケージ化して送信するように、別のクライアントを「名前空間」または別の方法で定義する方法はありますか。つまり。 meteor-router/admin*スペースと/user*スペースの異なるクライアントをプッシュする可能性があり、どちらのクライアントにも不要なオーバーヘッドがダウンロードされることはありません。

これは、meteor-routerのようなMeteorスマートパッケージの手段の範囲外だと思います。

+0

未回答の質問に関連すると思われます。http://stackoverflow.com/questions/17357394/where-to-put-a-separate-admin-interface-for-a-meteor-app?rq=1 –

+0

私はこれにも興味があり、これまでのところ解決策は見つからなかった。上記の質問には、鉄製ルータに基づいた回答がありますが、特定のアプリケーションにのみパッケージを出荷するという問題は解決しないと思います。 "// –

+0

私が今までに見つけた唯一の解決策は、一種のハッキリですが、"すべてのパッケージング "オーバーヘッドを減らすのに役立ちます。アプリケーションの残りの部分と共有する必要のないスクリプトやテンプレートを使用するアプリケーションの一部がある場合、実行時に[external-file-loader](https://atmosphere.meteor .com/package/external-file-loader)パッケージ。これらのアセットを 'public'のような静的フォルダに投げます。これはAJAX呼び出しと読み込みを処理します。 [session-extras](https://atmosphere.meteor.com/package/session-extras)と組み合わせると、読み込まれたときに物事を引き起こすことができます。 –

答えて

3

いつでも同じデータベースに接続する2つのアプリケーションを作成できます。共有サーバーコードはパッケージに入れて両方に含めることができるので、それを繰り返す必要はありません。

+0

本当に、2つの別々のアプリケーションの余分なオーバーヘッドを招くことなく、別々のクライアントを「サンドボックス」する簡単な方法があることを望んでいたと思います。 –

関連する問題