一起使用 S3 作为静态网页和 EC2 作为 REST API 吗？ (AWS)

Question

我发现这个链接讨论了将静态数据和 web api 分离为静态 s3 web 服务器和用于 api 和 ec2 web 服务器的 bean stalk 应用程序以创建网站。 Charles 的回答很准确，CORS 是解决在两个域之间移动的问题的方法。

How to use S3 as static web page and EC2 as REST API for it together? (AWS)

我的问题是你为什么要这样做？

我的一些想法是：

优点 - 我们使用 node 作为 api 的 web 服务器，这样可以减轻 node 进程的负担。

就是这样。

不简单地使用 Bean Stalk 来做这一切的缺点

增加了 CORS 的复杂性 更新软件更复杂 除非你有大量我没有的静态数据，否则似乎有点矫枉过正

我是否错过了另一个优势

Answer 1

将前端逻辑与后端逻辑分离并单独部署它们有很多优势。

代码分离

第一个重要原因是，以这种方式做事可以让您将业务逻辑（您的 API）与您的设计（您的前端）分开。

您可以将两个项目保存在单独的 Git 存储库中。您可以让您的设计师根据需要为前端项目提供尽可能多的更新，而无需打扰工程师。

在单个单体项目中（例如在 Elastic Beanstalk 上）这样做：几乎是不可能的，因为设计师需要通过工程团队来迭代他们的代码。

部署分离

Web 服务器很慢。文件服务器（如 S3）速度很快。它们速度快的原因是没有运行“代码”来从文件服务器访问文件——只是下载了一个文件。

例如，如果您有一个从 EC2 实例提供的单一 Web 应用程序，这意味着要查看一个页面，您需要运行一些代码来生成该 HTML。

但是，如果您将前端代码部署到 S3，则可以更快地通过网络浏览器直接下载该文件。

PROTIP：您还可以将您的 S3 网站放在 CloudFront（一个 CDN）之后，通过在世界各地的多个数据中心保留一个缓存副本来进一步加速您的网站。

更快的迭代

当您将项目分开并单独部署时，您可以更快地迭代。

假设您的前端团队在网站中发现了一个错误。他们无需经过工程设计即可轻松修补/发布修复程序。

您的工程师也是如此——他们现在有更多时间专注于构建核心应用程序逻辑，并且可以部署修复而不用担心 UI 更改等。

更简单的产品逻辑

当您按照您的描述单独部署事物时，您还可以获得简化后端逻辑的好处。

通过让您的核心工程师只构建 API，而不必担心前端问题，您可以比其他方式更快地发布更新。