需要 MeteorJS 应用程序架构指南

Question

我正在构建一个市场 Meteor 应用程序，但我对应用程序架构感到困惑。我想为市场、客户仪表板、供应商仪表板、管理用户界面和流星移动应用程序为客户和供应商构建前端用户界面。我知道 Meteor 将所有内容捆绑在客户端文件夹中并将其发送给客户端。我的问题是我是否需要使用相同的托管 Mongodb 数据库并为

创建单独的 Meteor 应用程序

• App 1 Marketplace 用户界面和客户仪表板。
• APP 2 供应商仪表板。
• APP 3 管理用户界面
• 适用于客户的 App 4 Meteor 移动应用程序
• APP 5 Meteor 供应商移动应用

或

为每个人创建一个 Meteor 应用程序。但在这种情况下，应用程序的大小会增加。

或

创建单独的 Meteor 应用并通过 DDP 将所有其他应用连接到 APP 1（市场应用）以共享出版物和方法。

请帮我确定最佳架构。

Answer 1

选项 1：

我已经使用单个 MongoDb 实例完成了此操作。我目前有四个应用程序连接到它。效果很好。

确保您使用 oplog 即时更新所有应用。

这种方法的一些安全优势出乎意料地好。例如，允许和拒绝为每个应用只考虑一种类型的用户创建规则。例如，如果有人有权访问 admin.yoursite.com，则该权限允许管理员执行各种操作，但对于面向客户端的应用程序，可以锁定权限以仅允许编辑所需的少数内容。

我推荐这种方法，你可以走得很远。

选项 2：

我不建议制作一个可以做所有事情的大型应用程序。

选项 3：

并不是说这种方法没有好处，但在这种情况下，“APP1”可能应该是某种事件日志，每个应用程序都可以订阅和写入事件，并更新自己的事件数据库。这是最复杂（也是最昂贵）的解决方案，在您尝试真正大规模扩展之前，我不会推荐它。如果您对这种方法感兴趣，我建议您研究事件溯源/CQRS。