我开始阅读有关Derby.js和Meteor的内容，对我正在开展的项目进行一些研究。它使用了大量实时功能，因此它们看起来都很方便。但是我有一些主要的担忧，我想知道在这个时候使用它们是否合理。
目前我更倾向于Express + Socket.io，并认为Derby和Meteor有点大肆宣传。你觉得怎么样？
为了更好地了解我的计划：
谢谢！
答案 0 :(得分：20)
我可以回答 meteor ：
的问题是即可。我们中有许多人正在为创收公司生产流星。
是即可。自2012年10月以来，Meteor已经建立了accounts系统。
系统为您做的越多，操纵底层机制就越困难。我发现流星达到了合理的平衡。
这个假设是正确的。您还可以实现自己的Web浏览器来可视化HTTP，但我发现使用chrome更容易。
用户身份验证：是，请参阅上文。
复杂路由：是的，请参阅iron-router和flow-router。
SEO：是（？），请参阅spiderable和ssr以及this post。
Elasticsearch：是的，（独立于您的框架选择）。 Meteor没有ES后端，但您当然可以通过node.js模块或直接通过HTTP与ES数据存储区通信。
MongoDB：是的，那是流星的默认（也是官方）数据库。
复杂关系：是的，（独立于您的框架选择）。
实时更新：是的，这就是流星的工作原理。
安全问题：是的，Emily Stark让您满意！另请参阅this post上的discover metetor blog。
性能和可扩展性：使用oplog-tailing并使用kadira监控您的应用。
答案 1 :(得分：15)
有Meteor答案， Derby 也应该有：
是的，从0.6版开始，Derby足够稳定，并且有一些网站在生产中使用它，例如：Lever。
是的，有一些auth模块，例如：derby-login使用passport
是的，但更模块化的框架（由更换部件组成）并且遵循惯例（npm，Express等）越多，您的感受就越少。
是和否。例如，如果你认真对待实时，那么最好有一些冲突解决机制（OT或CRDT或其他），并且实现一个并不简单。顺便说一句，Meteor没有，它使用LWW策略。
用户身份验证：是的，有一些模块。
复杂路由：是的，同构的类似Express的路由器。
SEO：是的，内置同构（客户端和服务器）模板引擎。用于服务器上的第一个请求呈现的Html，用于在客户端上呈现的后续URL更改。
Elasticsearch：是的，当然。这不是框架问题。
MongoDB：是的，有适配器，这是目前最好的选择。
复杂关系：是的，不是框架问题。
实时更新：是的，加上OT。
安全是一个问题：是的。从服务器的角度来看，Derby就是Express。要保护所有这些实时通信，请使用一些访问控制模块，例如：share-access
性能和可扩展性：是的，我没有测试，但理论上Derby在缩放时应该比Meteor更高效。有一个kind of confirmation。
Meteor怎么样，我在Derby之前使用它。它有很好的文档，教程，支持和营销。在五分钟内引导一个小应用程序是件好事。理解这样的概念是很好的：客户端上的db，同构代码，实时等等。但它非常单一且不灵活。它实现实时的方式非常简单，但缺乏冲突解决方案并且存在性能问题。它不能以任何合理的方式用于离线。大多数德比开发者来自Meteor。
尝试两者并做出选择。祝你好运！
答案 2 :(得分：3)
我同意@David Weldon的几乎所有答案，只需要考虑一些事项：复杂的关系和可扩展性。
当你说对象之间的复杂关系时，我想知道MongoDB是否适合你。由于所有数据都存储在文档中，Collections之间的关系越少越好。
关于可伸缩性，如上所述，如果你有一些相当“关系”的集合（MANY-TO-MANY等），你可能会遇到严重的可扩展性问题（学到的经验教训）。
如果你真的这样做，你应该等到Meteor正式支持其他RDBMS。