【第3511期】前端很难

正文

请到「今天看啥」查看全文

我们最初开发 SST 的时候，前端部署只是其中很小的一部分。但随着项目的发展，越来越多用户开始提出，希望我们能更好地支持前端部署。

对于开源项目来说，自行托管前端是再合适不过的了。

我们看到的问题包括：没有通用的解决方案，以及框架和功能种类繁多。正因为如此，这个问题特别适合用开源的方式来解决。

于是我们采取了以下做法：

1、拆解问题

部署前端其实包含两个步骤：第一步是通过所谓的 “适配器（adapter）” 生成构建结果，第二步是基于构建结果搭建基础设施。

基础设施部分依赖于具体的云服务提供商，但 “适配器” 这一步是可以共享复用的。

所以在 SST 决定支持前端部署时，我们把这两个步骤拆分开来，并将 “适配器” 开源。

这就促成了 OpenNext 项目的诞生。https://opennext.js.org/

现在，像 Cloudflare、甚至 Netlify 和 Vercel 这样的服务提供商都可以参与这个项目，帮助我们保持其更新和完善。

2、一切都开源

不仅是适配器，SST 用来部署前端的基础设施配置也是完全开源的。你可以直接查看我们的代码库，了解我们是怎么部署的。

SST Github：https://github.com/sst/sst

这让更多人可以参与贡献，也让 SST 能够支持大量的前端框架，覆盖各种特性，并持续适配框架的更新。

【第3387期】多种前端框架SSR性能大比拼

3、与框架作者紧密合作

由于一切都是开源的，我们也更容易直接与前端框架的作者合作。

这使得 SST 成为那些希望将前端部署到自有基础设施用户的首选方案。

是优秀，还是 “够用”？

SST 在本地部署前端时所创建的基础设施，与 Netlify 或 Vercel 创建的有些不同。

原因在于，Netlify 和 Vercel 是多租户架构，它们可以在多个用户之间共享部分基础设施资源。

而 SST 为每个前端站点创建的是完全隔离的环境：每个站点之间互不影响，也不会与其他 SST 用户共享资源。

这种做法的缺点是，每个站点都需要单独创建完整的基础设施，比如 CDN 分发配置，这个过程可能需要 15 到 20 分钟。所以，如果你有多个前端项目，或者经常创建预览环境，部署速度会比较慢。

还有一个相关的问题是，SST 之前并不支持将前端部署到多个地区。

我们一直在寻找改进的方法。现在，机会来了。

CloudFront 宣布新功能

一个看似微不足道的预发布声明让 CloudFront 变得更具可编程性。这让我们能够支持比 Netlify 或 Vercel 更灵活的部署方案。

关键的变化在于：现在可以将 CloudFront Functions 和 CloudFront KeyValueStore 配合使用，以动态修改请求的源地址。这使我们可以根据自定义策略，将 CDN 的流量灵活地路由到具体的应用上。

以前要实现这个功能，必须用到 Lambda\@Edge 和 DynamoDB—— 这种方式既昂贵又慢。

引入 Router（路由器组件）

我们利用 CloudFront 的这个新功能，构建了一个名为 Router 的组件。这个组件允许你为整个应用只使用一个 CloudFront 分发（distribution）。

 sst.config.ts
const router = new sst.

请到「今天看啥」查看全文