有人成功部署过 Angular 17 SSR 到 AWS 么？

[wjpauli]

有一个小网站需要 SEO ，但是发现 17 的 SSR ，没有任何部署的文档。看到 Angular 那帮子人天天在网上歌舞升平就来气。

1. 通过 serverless 部署 搜了最多的是这个，也是个第三方公司的库，装到 aws 上，然后找到的文档都是以前 16 版的，没发用。
2. 通过 sst 部署 有一个第三方的，这些都忍了。并且这玩意本身就不支持 Angular ，跌跌撞撞弄好了，网站也上线了。也可以重复部署，但是过了一段时间，昨天修改一下，再部署就失败了，真是无语。今天弄了一天，也不知道是网络问题还是别的什么（我网络没问题）

上面这两个都是 lambda ，然后又尝试了 ECS 容器，也可耻的失败鸟。最主要的是 angular 没有提供任何一丁点的部署文档，哪些被部署的地方，也没有任何预制的模板。

[min]

失败了报啥错

[BeautifulSoap]

你本地怎么跑起来那就打包好扔到 lambda 啊，没必要去专门找部署教程（做 handler 适配倒是需要）

lambda 部署到 aws 建议使用 cloudformation 或 cdk ，后者支持 typescript 你不会陌生。cdk 默认使用 esbuild 做 bundle ，你也可以手动 bundle 然后用 cdk 部署

[wjpauli]

@BeautifulSoap 我不太懂你说的。本地 Angular 17 的 SSR 都是 dev 工具直接运行的，不需要自己架服务器。那个 server.ts 文件里面可以看到它还是用 express 什么的，然后有一个 run 函数，也就是用 node 直接运行这个 run 函数，常驻服务器。如果是 lambda ，应该是交由 lambda 托管，至少应该删除 run 函数吧。然后我把整个 disk/server 打包传给 lambda ，就可以么？然后怎么跟 cloudfront 衔接？

[BeautifulSoap]

@wjpauli 找到了一篇日文文章，看着应该还算靠谱比较新（用翻译软件翻译一下就 ok ）

https://zenn.dev/seapolis/articles/6669b3c1cda5b0#lambda%E3%81%AB%E8%BC%89%E3%81%9B%E3%81%A6%E3%81%BF%E3%82%8B

里面用了 @h4ad/serverless-adapter 做了 lambda handler 和 express 的兼容。deploy 用的是 serverless 框架，但我觉得你要是玩不转 serverless 这个框架，直接手动把最后的文件 bundle 成单一文件 zip 一下，然后手动上传也不是不行。。。。至少能了解下 lambda 的运行方式。然后要么用 cdk 要么 serverless 框架

至于怎么和 cloudfront 结合，也有介绍（直接给 cloudfront 连上 lambda 的 url ，虽然一般用得更多的是 aws apigateway+lambda 再套一层 cloudfront ）

[wjpauli]

我看它这个 serverless 自动部署，往 s3 上的 bucket 里传文件，这是什么意思？它部署到这步，就一直显示 Uploading ，快半小时了我觉得肯定不对，不知道是不是网络问题。那个 bucket 只有两个文件。我要是手工把 dist/server/打包传到 lambda ，总感觉不太靠谱，因为它这个似乎跟这个 s3 要交互一下的感觉。

[zhenjiachen]

@wjpauli ssr 部署不需要上传到 s3 吧，ssr 一般都是把整个源代码上传然后下载依赖，然后 npm run start ，nextjs 就是这样

[wjpauli]

@zhenjiachen 因为官方没有给出具体的部署方案，所以都是第三方部署脚本。具体干了什么我也不是很清楚。

今天上午我不停的尝试各种姿势，比如 aws 换区，比如换电脑，比如删了 s3 重新弄，结果我的 sst 方案自己恢复了正常。我也不知道怎么回事，这里面肯定有问题，只是不知道怎么解决。还有 BeautifulSoap 网友提供的日文网页，非常佩服，我很想知道是怎么找到的。这个日本人写的文档非常的日本人，细致入微，包括用“<----”这样的注释给你指出来修改在什么地方。但是非常遗憾，它的部署程序也在最后无限等待，我觉得就是 aws 的问题，具体是什么问题也不清楚。还有就是 sst 方案比日本人的方案更接近产品，因为 sst 的方案考虑到 cloudfront 部署和 css 、js 这些 browser 的东西都会自动放到 s3.

[zhenjiachen]

你可以在自己电脑上先
npm run build:ssr
npm run serve:ssr
然后访问试试，
然后再到 ecs 试试

[wjpauli]

我还想再吐槽两句，Angular SSR 现在看来注定不是正常的方案，因为你想想，在服务器运行 js ，通过 http client 加载页面后在推给浏览器本身就是一件很扯淡的事情。PHP 时代一个正常的 http 请求，居然把我折腾成这样。

Angular 17 SSR ，就两个部署方案：
1. Lambda 。但是就像日本人说的，这种方案每次访问都对应一次 Lambda 的执行，这太离谱了，搞得网站像是一个玩具。虽然要配合 cloudfront ，但是我想成本也会大大的高。
2. 容器方案。昨天我刚在 X 围观了奶罩被网暴，下午就短暂的屈服于 docker 。但是我把 Dist 放到容器时就已经负罪感满满，然后再把容器 PUSH 到 AWS ，然后再建立 EDC 集群，我的天，再回想一下 PHP+Jquery 时代，到底是进步还是退步？

其实 Angular 部署到 S3+Cloudfront 一直挺好的，就是因为 SEO 的关系才会有现在所有这些烦恼，不知道为何都 2024 年了，Google 还是不能理解 Angular 这种没有 html 输出的网页，尤其是 V8 都是他们自家的，完全可以索引 Angular 程序。

[icepoint1999]

1. 一直在吐槽 angular 17 没文档啥啥的。没想过 ssr 的本质是什么，文档写的很清晰。
2. 本身就是映射一个 node port 的问题 和部署 express 没任何区别
3. ，Angular SSR 现在看来注定不是正常的方案 -> 是的，建议回到 PHP 时代。更适合你。

[wjpauli]

今天发现 SST 又不行了，准确的说其实是 SST 调用的 AWS 那堆黑箱不行了。最扯的是去 SST 官网看了看，它们居然也在抱怨同样的问题，说是要放弃这个产品，另立门户，我靠。好在 SST 装的架子还在，现在可以直接传 ng build 之后的 server 代码到 lambda ，传 browser 到 s3 ，SST 当初搞了一个机制，让本地代码放在 S3 上，这就非常合理了。具体怎么搞的不知道。