API 网关缓存混乱

Question

我相信这是一种常见模式，但我正在尝试通过从 S3 拉取 API 网关来为我的 Angular Web 应用程序提供服务。我的 api 网关设置为在 / 路由处设置了 GET，该路由从 s3 存储桶中的适当位置拉取我的 index.html，并在 /${folder} 处设置了另一个 Get，其中 file 是特定文件。当我点击 api 网关的根目录时，我的 index.html 被拉出，然后触发请求通过 /{folder} 端点拉取所需的 js/css 文件，以使应用程序实际运行。呜呼！

现在我想确保除了我的index.html文件之外的所有文件都被缓存，以便我确定我得到最新的index.html（因为该文件的名称永远不会改变），但文件引用的资源应该只需要转到S3 一次（或者每当缓存的最长 TTL 达到时，就必须再次拉取它，那很好）

我的困惑来自“阶段级缓存配置”和“方法级缓存配置”。我已经为我的方法 /{folder} 方法启用了缓存，但没有为根方法启用缓存，因为我不希望缓存 index.html

但是我还没有在舞台级别启用缓存

我的js/css文件现在是否被缓存？如果我启用了阶段级缓存，我如何确保index.html被不缓存？或者我什至需要担心这个？在 S3 中的现有索引上部署新的 index.html 是否会触发 Api 网关刷新该文件的缓存，以便加载新文件？谢谢你！截至目前，我对使用 CloudFront 不感兴趣，但我可能会在未来研究它。

Answer 1

使用 API Gateway 直接从 S3 提供 Angular 文件通常被认为是一种反模式。这是一个更好的方法：

将 Angular 应用程序部署到 S3：不使用 API Gateway 来提供 Angular 文件，而是将整个 Angular 应用程序部署到 S3 存储桶并将其配置为静态网站。

使用 CloudFront 进行缓存和分发：设置 CloudFront 分发以从 S3 存储桶为 Angular 应用程序提供服务。 CloudFront 将处理静态文件的缓存和分发，提供比使用 API Gateway 更好的性能和可靠性。

使用 API Gateway 作为后端：保留 API Gateway 设置，但使用它来处理来自 Angular 应用程序的后端 API 调用，而不是提供 Angular 文件。例如，如果您的应用程序需要数据库 - 例如 DynamoDB，请编写一个与 Amazon DynamoDB 交互的 Lambda 函数，并通过 API Gateway API 调用该函数。

设置的工作原理如下：

1. 将 Angular 应用程序部署到 S3 存储桶并将其配置为静态网站。

2. 创建指向 S3 存储桶的 CloudFront 分配。这将处理 Angular 文件的缓存和分发。

3. 在您的 Angular 应用程序中，对 API 网关端点进行 API 调用以获取数据或执行其他服务器端操作。

这种方法有几个好处：

缓存和性能：与 API Gateway 相比，CloudFront 为静态文件提供了更好的缓存和分发能力。

关注点分离：您的 API 网关专注于处理后端 API，而您的 Angular 应用程序直接从 S3 存储桶和 CloudFront 提供服务。

可扩展性：与使用 API Gateway 相比，CloudFront 和 S3 可以处理更高的流量，并且可以更好地扩展来为整个 Angular 应用程序提供服务。