缩放流星(来自非技术人员的Q)

时间:2015-07-02 21:56:45

标签: javascript meteor scaling prototyping

TL;使用Meteor作为我们的全栈框架构建一个Web应用程序是不明智的,因为期望大量的并发用户?

我们正在寻找构建一个网络应用程序,在其第一阶段,音乐为product hunt(从Youtube的API提供用户提交的URL以获取播放请求)。

Meteor的好处似乎是开发MVP /原型以了解用户行为的速度有多快,但风险似乎是在使用整个产品生命过程中在此阶段构建的内容。

想知道是否有人可以帮助我的无知大脑以外行的方式理解我上面所说的任何内容是不正确/正确的,如果是,为什么?衷心感谢此

上的任何/所有输入

2 个答案:

答案 0 :(得分:2)

没有帐户或订阅的流星应用程序的通信和CPU开销几乎为零。但是,正如我在this question的答案中指出的那样,真正的资源限制来自维护服务器和客户端之间的查询结果集。换句话说,随着订阅数量,大小和复杂性的增加,扩展变得很难。

在不了解您的产品及其运作方式的情况下,我的一般建议就是这样:去吧,因为流星会给你一个快速的MVP。如果您发现由于大量用户的攻击而难以缩放(恭喜!),那么您可以通过使用各种技巧(包括非反应性数据(方法调用))来降低订阅费用。

推荐阅读:Scaling Meteor: The Challenges of Real-time Apps

答案 1 :(得分:1)

根本不是不明智的。有一个名为ClassCraft的网站使用Meteor构建,我认为每天可以获得15,000次登录。

您最简单的解决方案可能是使用基于节点的托管服务,例如Modulus,它将自动为您处理缩放。

迈向更多DIY解决方案的下一步是将您的MongoDB托管在ComposeMongoLab等提供商上,但在您自己的服务器上托管Meteor应用程序。查看mup的简单部署脚本,或者他正在使用的Arunoda新解决方案mupx,它使用Docker部署Meteor应用程序。

这只是触及表面,但希望能让你更有信心已经完成并且可以完成。

相关问题