什么是SSR/SSG/ISR？如何在AWS上托管它们？

概述。

在这篇文章中，我们将讨论如何在AWS上运行SSR/SSG/ISR以及App Runner的魅力。

内容

• 我们将首先分别解释传统和现代网络应用。
• 接下来，我们将介绍如何在AWS上托管SSR/SSG/ISR。

传统网络应用和现代网络应用

传统的网络应用

传统的网络应用
=> 应用处理只在服务器端进行

例如，Java的Spring，Python的Django，Ruby的Rails。

现代网络应用

Reactive Web Application

• 在服务器端和客户端对应用程序进行单独的处理。

• 客户端渲染（CSR）
  => Sigle页面应用程序（SPA）是一个使用CSR创建的应用程序。
  -React, Vue, Angular, 等。

• 服务器端渲染（SSR）
  -下一个，Nuxt，等等。

• 静态网站生成器（SSG）

• Jamstack机制、Gatsby、Hugo、Next、Nuxt和其他。

• 递增静态再生(ISR)
  -下一页 (9.4版中增加的功能)

CSR（客户端渲染）/SPA（Sigle页面应用）。

• 首先检索出空的HTML，然后用JavaScript生成整个页面。
• 根据在客户端获得的数据，整个页面被重写，没有页面转换。

SPA的挑战

• 首先访问加载大量的JavaScript，然后处理整个页面，这使得第一次加载很慢。
• 最大的问题是围绕着SEO。

  • 如果不解释JavaScript，搜索引擎爬虫会解释空的HTML
  • 现代谷歌爬虫也能解释和执行JavaScript
• 建立动态的OGP也是一个挑战
• 至于KDDI工程师门户网站，它也管理着Blog，所以不仅需要SEO措施，也需要OGP措施。

SSR（Server Side Rendering）

• 响应请求，返回动态生成的HTML
• 还在服务器端使用JavaScript、虚拟DOM等。
• 缺点是服务器端很重；如果使用API通信等，响应时间很慢。

SSG（Static Site Generator）

• 预先生成的HTML被返回以响应一个请求
• SSG在构建时生成HTML
• 交付速度非常快，但页面内容在部署后不能动态改变

ISR（Incremental Static Regeneration）。

• 响应一个请求，返回静态构建的页面。
• 当超过有效期时，SSR异步地重新生成静态页面。
• 在利用缓存的同时，静态页面可以被自动更新，如果在一段时间后再次提出请求，内容就会被更新，因为内容是为下一次开始建立的。

如何在AWS上托管SSR/SSG/ISR

• 你只需要一个服务器来渲染（设置了Nodejs的服务器就可以了）。

当你想让ISR工作时的缓存问题

• ISR使用缓存来重新生成HTML。
  => 因此，随着实例和容器的扩展，缓存的时间也不同，所以HTML响应的显示方式也不同，这取决于从LB接收访问的实例或容器。

还有其他选择吗？

其他选择包括一个名为Serverless Next.js Component和App Runner的第三方工具。

事实上，托管给Amplify也是可以的。

• 静态网站部署管道和托管的简易服务
• 很适合SPA或Jamstack托管。
• Amplify => Serverless Next.js组件似乎是基于它的。

什么是App Runner？

APP Runner是 "在AWS上构建、部署和运行容器化网络应用程序的最简单和最快速的方法"，即一项允许你在AWS环境中非常容易和非常快速地准备和运行容器应用的服务。 换句话说，它是一项允许你在AWS环境中非常容易和非常快速地准备和运行容器应用程序的服务。

为什么选择App Runner？

• 当然，如果是运行容器的环境，那么ECS就可以了。
• 然而，说实话，即使ECS Fargate是一个选项，它不是很难操作吗？我认为它是，因为我认为它是。

App Runner

有了Fargate，你必须把容器管理、围绕VPC、ALB、NLB和自动扩展设置和Codebuild结合起来，如果你想实现自动化，但App Runner在一个（隐藏的）包中提供了所有这些。

在App Runner中部署

• 在App Runner的部署方法中，有一个功能可以自动做到这一点。
• 在使用方面，如果你把容器镜像推送到ECR或源代码推送到GitHub，App Runner会检测到它并以良好的方式部署容器。