概述。
在这篇文章中,我们将讨论如何在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多平台发布