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

340 阅读4分钟

概述。

在这篇文章中,我们将讨论如何在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会检测到它并以良好的方式部署容器。

本文由mdnice多平台发布