我正在为我公司希望提供的新解决方案设计云部署网站。我一直试图回答几个问题并没有运气，所以在罗马时。
首先，我不希望网站被卡在任何一个特定的框架上。我知道没有办法完全证明一个网站的未来证明，但我宁愿不把所有的鸡蛋放在一个篮子里。
其次，我想完全分开前端和后端。我列出了为什么要这样做的原因列表，不一定要进入他们所谓的对话。服务器端渲染大部分是不可能的。
那么这让我离开了什么？
我对设计的初步想法是拥有一个可以访问任何API调用的REST API（将来可能会转向GraphQL）。
我主要想要的设计决策是针对前端的。该网站将是一个仪表板类型系统，租户可以登录并查看它们的屏幕。
我在想我会有一种shell，它挂在index.html上。这将拥有它自己的路由，这将呈现与shell逻辑完全分离的微应用程序。
例如，如果我加载index.html，路径为“/”
它有一些它负责的路线，比方说 “/待办事项” “/帐户”
如果我访问/ todos路由，我的shell应用程序将呈现该微应用程序。除了可能通过窗口加载的一些数据外，此应用程序将与shell完全分离。一旦通过shell应用程序呈现此应用程序。
因此，我的todos路线可能是一个独立的redux应用程序。它可以拥有自己的路由等。
这是一个常见的架构吗？这有什么例子吗？有没有更好的方法来解决这个问题？
感谢您的任何见解！
答案 0 :(得分：1)
听起来像你的好，真正超过了这个野兽的工程。
你可以采用这样一个架构进行巨大的构建，许多开发团队都是分开工作的。小型敏捷团队，上面会在每个＆＃34; app＆＃34;之间的上下文切换中产生如此大量的样板和脑痛的开销。
微服务架构非常棒。只是不要将它分解得太小，请仔细阅读您的用例并相应地破坏您的服务。
例如：我们是一个由3人组成的团队。我们设计了一个非常大的应用程序：
全部在多个主机上的多个docker容器中运行。拉下后端..好的前端网站仍在运行！