基于 CF Pages/Workers/D1/KV，探索 0 成本部署应用的可能。

[witcat]

上次把一个普通的 Node + Nginx 应用转移到 AWS Lambda 之后，就没有再更新过了程序了，AWS 维护的成本也不低，让人没什么信心。
虽然 Lambda 解决了一部分问题，比如免运维、低价，也许 serverless 本身也能避免一些内存泄露问题？
但是产生了更多的问题:

• 首先就是 AWS 的那个控制台是非常繁琐的，CDK 也需要学习，而且并不能正常的在中国区使用。
• 如果访问频次低的话，会经常出现冷启动，链接超时。尝试过但最终没能解决。
• lambda 可以使用非 serverless 架构的数据库技术，但如果想要最佳效果，要使用 dynamo db ，这玩意很强大但只能在 AWS 上用，学习成本比较高。
• 中国区不仅只对公，而且收费也必须对公转账。有一个 10 块多的账单，我懒得转，索性就弃了。

前一阵子刷 Github 看到一个热门库Hono，据说是转为 edge function 环境设计（其实就是本身功能比较精简，尺寸小，有一个高性能路由），作者似乎现在是在给 CloudFlare 做布道师。
感觉 EdgeFunction + Hono 似乎可以在 Lambda 的基础上更进一步，更加简化其他工作，只要开发程序本身即可。遂开始把 lambda 上的程序转移到函数计算架构。
Hono 有一个脚手架工具可以生成多个基于多种平台的模板。
因为我是前端，所以最喜爱的是 Vercel ，Vercel 虽然也有函数计算，但是它的函数不能单独存在，必须存在于 Next.js 项目内。
对于我的项目，我可能希望多个 workers 一起工作，不一定每个 worker 都有前端界面，这样 vercel 的方案就比较受限。
鉴于现在 CF 的人气比较高，免费计划也很值，于是就开始研究了，经过最近的研究，个人有以下几个感受：

1. 相比 AWS ，CF 有类似的地方，但文档更清晰和明确。wrangler 也比 cdk 要人性化很多。当然他们不是一个量级的，不知道 CF 如果的服务继续变多，文档会不会也很乱。
2. 因为使用了这种无服务器的方式，最大的困难就是解决数据库问题。不可避免的要学习使用 D1 数据库，但学习它的成本也很低，它是一种 SQLite 数据库。这样有个好处就是一些入侵性比较低的 ORM 可以配合 D1 使用比如 drizzle-orm 、kysley ，这比使用 dynamo db 的门槛低了太多。
3. 对 Javascript 程序员非常友好，可以直接部署 typescript 代码，而且 cf workers 就是一个特殊的 Javascript 的运行环境。

总体来说，我的个人项目从 lambda 迁移到 cf 以后，各方面是提升的。
冷启动问题没有了，而且感觉 wrangler 很简单很可控很放心。
相比 Lambda 的花费，现在花费更低了
原本的 postgres+primsa 本身就与 serverless 相容度低，而且 postgres 用在小应用上没有必要。
最后是 CloudFlare 天生比较抗攻击的优点。有时候小公司做些东西被小鬼盯上了很容易被流量攻击打死，这也是我拒绝自建网络服务的一个很重要的原因。
总体来说现在不管程序还是架构还是维护都比以前更轻巧了，继续开发维护也更加有信心了。
不得不感叹，安全、抗打、低价，CloudFlare 才是未来啊！（对于小公司或个人 sideproject ，我是这样认为的）
不过这么好的东西，问题当然还是有的。就是 cloudflare 国内不能直接访问。
但通过转移域名解析服务器到 cloudflare 是可以实现直接访问的。
听说墙封死 cloudflare 是可以做到的，不过因为 cloudflare 用的公司极多可能造成损失，所以大概还是可以通过这种方式访问吧。
其他的，我看对象存储和消息队列也是有的,构建一个功能全面的 App 应该没有太大问题，如果不在乎有一天无法访问的风险，我觉得还真是一种相当先进的服务托管方式了。

写的比较急，写的有些问题：
“dynamo db ，这玩意很强大但只能在 AWS 上用”：Dynamo DB 可以在外部用，只是多数情况下它都是和 Lambda 一起用。
“遂开始把 lambda 上的程序转移到函数计算架构。”：这里应该说是边缘函数计算架构，workers 是用全球的节点来计算的，lambda 以我的了解应该还是限制在某个区域内。

[witcat]

关于控制台问题：
locode nocode 其实效率也不是很高，postgres 函数钩子也太怪异。
所以最终还是开发了一个管理面板，但好处是我可以把 function 和 pages 放在一起，这样相当于在同一个域内，而且那些管理相关的路由就只有对应的 page 能够访问，对于管理员的鉴权如果不想实现，可以直接打开 cloudflare 的 zerotrust 鉴权。
最终写入的 api 会只存在于管理面板内。那些读取的 api 会放在另外一个 worker 内。
结构简单，而且绝对安全。

[chihiro2014]

是的，其实 R2+D1+pages 可以构建个小型百度盘

[Kirscheis]

CF 现在能玩这么花了吗。。一直只会用他的 DNS 和 CDN

cf workers 心动很久了，主要是确实便宜，而且还支持 rust

[0o0O0o0O0o]

并且 D1 without read replicas is strongly consistent ，配合 edge network ，太杀手级了

[airyland]

hono 不错，我有个 AI 应用部署在 cf worker 上已经有半年没遇到什么问题。

[lupus721]

在用 microfeed ，全托管到 cf 上了，不过感觉还是摸索实验为主

[cxumol]

https://github.com/cxumol/URLinkCat 看看全栈部署在 cloudflare 平台的云书签, 用于整理大量链接并分享, 可供多人使用

[linyongxin]

低成本部署这个对于无交互、更新频率很低的网站来说很有用
非常有意思的想法，CloudFlare 可以抗攻击，保护源站很好，就是国内的速度太慢了。
我之前甚至把 wp 安装在 serverless 上，打算全站生成自动部署到 cf pages 和 cdn ，可惜环境有问题无法实现，wp 无法使用静态化 static 插件