在后端编写微服务并没有那么令人困惑，特别是如果我们正在构建api端点。我们可以编写用于用户管理的单独项目，用于报告的单独项目，...，并将其所有端点与AWS网关api相结合，或者为较小的一个与nginx反向代理完成此功能以提供集成的api服务。
我建议团队编写后端的方式是这样的：
本地主机：8001 /列表 apiproxy.com/users/list
本地主机：8003 /事务 apiproxy.com/transactions/create
这样看来很简单，我们按类别在单独的存储库中编写我们的项目，每个团队/人员都可以单独进行工作。但是我的问题在这里：
“我们如何实现一个解决方案，使服务器渲染的React应用程序（或angular，Vue）可以渲染并使用单独的存储库进行开发，但是在构建时，它们可以相互融合，并且路由工作良好。”
因此，在这种情况下，每个存储库必须能够独立进行引导。目的不是创建新的框架。
有人有什么建议吗？
最佳答案
Canopy Tax是一家位于犹他州的科技初创公司，致力于为税务专业人士提供解决方案，大约两年前也面临着类似的情况。他们希望能够在前端实现某种微服务架构，然后猜想他们成功了。解决方案还不是完美的，有很多折衷方案，但是可以满足目标，并且他们正在与客户一起在生产中使用它。我在他们举办的一些聚会上看到了它的作用。
Canopy Tax去年开源了他们的框架，称为Sofe。 Here it is the link to the github project。他们的解决方案用于生产中，并且在这里可以保留很长时间。他们最近在今年筹集了另一笔20 million风险投资。
他们称之为元框架。它基本上是一个主要路由器，它决定将路由分派到何处。然后将其调度到angular2，ember，react，angular2应用程序。而且效果甚至更好，在同一页面上，您可以内置有React组件，有角度的组件等等。这样一来，他们可以更快地扩展规模，获得更多才能，并且不再局限于一个框架。他们可以随时部署，他们的团队（团队）彼此不依赖，因为这些应用程序是独立的应用程序，例如前端的微服务。
它仍然很新，但绝对值得一看。我最近在一次聚会上与他们进行了交谈，其他一些公司也在生产中使用了它。他们还有一个检查器工具和其他工具，可向您显示您选择的Web应用程序所属的框架（例如：react，angular等）。 Here it is the live demo of sofe in action.
单击框架检查器，然后将其打开。它会告诉你。
这种方法需要权衡取舍，其中之一是移动设备尚不支持此方法。它非常适合他们的产品，但他们也正在为此寻找解决方案。
免责声明：我不在Canopy Tax工作，我从没在那里工作过，与公司没有任何关系。我只喜欢Sofe以及他们在该项目中的工作。