单页应用+ node.js后端（REST）+ CMS - 最佳概念/实践

Question

我们将打造一款大型社交网络应用。我们必须实现两个大模块：

1. FrontEnd - 单页应用（Backbone.js）
2. CMS - 管理FrontEnd内容的系统（每日内容，赞助商，横幅，链接，特别优惠，上传媒体etcetc）

FrontEnd将使用Node.js支持的REST api，它将使用云中的数据库（PG或Mongo - 还没有决定）。

我的问题是：CMS是否也应该使用与FrontEnd相同的REST API？或者我们应该为CMS直接与db进行“对话”的单独app（不是node.js neccessery）？我的问题出现了，因为在之前的项目中我们遇到了这个问题：

1. FrontEnd和CMS的单一REST api。
2. 当我们想要CMS中的新功能时，我们必须在RESTapi中实现它 - 然后我们不得不重新启动整个APP（RESTapi），这在生产中是有问题的......

所以：

1. 实施2 RestApis - 一个用于FrontEnd，一个用于BackEnd？
2. 为FrontEnd实施1个RestApi并将CMS实现为直接与数据库对话的独立应用程序？

你是怎么做到的？

---

目标是实现超快的FrontEnd和Big / Heavy CMS（它将比FrontEnd更大）。所以我们正在考虑将CMS模块与FrontEnd模块完全分离。模块之间的最终通信需求将通过redis pub / sub实现 - 您如何看待？

Answer 1

软件体系结构决策始终取决于上下文-您和您的团队最有资格做出决定，因为您比我们更了解。话虽如此，根据您分享的信息，这里有一些需要考虑的事情：

1. 内容管理作为问题空间已经相当成熟。除非您的收入模型的一部分涉及如何处理内容管理方面的创新，否则构建它是不明智的。有许多出色的CMS，包括开源和商业CMS，价格从几百美元到数十万美元不等。对于常见的开发人员谬论，我无法给予足够的警告，以免浪费我们自己的时间。即使您将整个工程师的薪水花在CMS上，您也几乎肯定会领先。

2. 使用CMS的体系结构应反映＃1的现实，即CMS成熟且稳定。您希望在系统的各个部分（特定于您的收入模型）以及与COTS（现成的商用）可互换的部分之间建立牢固且定义明确的界面边界-即使您 > do 最终由您自己构建（我再次强烈警告）-您将遇到非常难以摆脱的阻抗失配问题，并给新功能造成摩擦如果您设计的东西好像不是定制的（或者相反），则可以跨整个系统交付。