在 CF 的 workers 上撸了一个简单的博客，有站友在这上面部署过复杂的项目吗？

[jamfer]

最近才接触 Cloudflare ，感觉很有趣，花了一天撸了个简单的博客，不是用的 pages ，用的是 workers+d1 ，纯动态博客（只放了几篇远古的文章上去，果然个人博客最大的障碍还是更新动力）

写代码的过程中发现 Workers 的 js 跟 node.js 真的很像，但又有本质的不同，serverless 还是限制颇多的（比如无法直接访问文件系统）。但 CF 的免费福利，还是太舒服了。

我忽然有个疑问，V 站是否有人真的在 cf 的 workers 或 pages 上部署了复杂的项目（不是博客），把项目都迁移到 workers 上是否有坑？问这个问题，主要是昨天让我产生了这方面的冲动，CF 有太多优点了。

最后，顺便麻烦大家帮忙测个速： https://blog.gamegene.net

[bgm004]

慢，开了代理都慢。
cf workers 好像单次执行时间有点短。

[0o0O0o0O0o]

/t/1047473

[wonderfulcxm]

你这个是 ssr 的吗？
seo 怎么样

[sparkinglemon]

谈不上复杂吧，我自己的静态(next.js ssg)博客在 Pages 上，然后 worker 写了一个接口转发，写了一个检测网站是否在线的 cron （如果 A 云离线了通过修改 DNS 的方式切换到 B 、C ）

我自己的理解就是 serverless 还是更适合一些无状态应用，太过复杂就很依赖平台提供的功能（之前 D1 没有的时候用 KV 存储数据要多蹩脚有多蹩脚）

[jamfer]

@wonderfulcxm ssr 是啥？
@0o0O0o0O0o 这个做的不错，我昨天也看了一些 cf 上的博客项目，大多数是静态的，我更好奇有没有更复杂的动态语言项目部署在 workers 上
@sparkinglemon 嗯确实，我也感觉 serverless 太依赖平台了，给你什么就用什么

[sparkinglemon]

@jamfer ssr 是 server-side rendering （服务器收到请求后渲染成 HTML 字符串，然后返回给用户，在浏览器进行 hydration ），区别于 SSG （ Static-Site Generation ）

Vue 的 SSR 文档写的算是蛮清晰的： https://cn.vuejs.org/guide/scaling-up/ssr

[woodongwong]

我说怎么这么快，图片放在了阿里云

[jamfer]

@sparkinglemon 感谢科普
@wonderfulcxm 是 SSR

[jamfer]

@woodongwong 嗯，图片还没迁到 R2 ，晚点也迁过来

[enrolls]

这个 cf worker 可多东西玩了，同理所有云上的 lambda 都一样

[cwxiaos]

pages 可以做全栈，要依赖 d1 或者 kv,做动态的没啥大问题，

Worker 理论上可以，但静态资源依赖 kv asset 之类的

[ByteCat]

尝试用 worker 做个小项目，但是有几个问题，主要是因为无状态带来的。
我用的后端框架是 Hono ，ORM 用的是 Drizzle ，每次要进行数据库查询需要初始化一个 db 对象，比较麻烦。不过也算小问题。
另外就是配套的 D1 数据库有查询变量限制，好像是 100 个，这就导致某个比较长的查询，直接运行失败，原因未知，可能 cf 自己的限制，可以通过多次查询解决，但是非常不优雅，用别的 serverless 数据库代替应该也行，比如 neon postgres ，但是就不能白嫖 cf 了，有点恼火。
另外如果迁移到别的平台可能不太方便，暂时没有试过 miniflare 是不是完全兼容 cf 的 workers 。
哦还有一点就是 workers 不太能部署静态资源，这个有点麻烦，需要配合 pages （页面）和某种 s3 存储（存文件，比如 cf 的 r2 ）

[jamfer]

@ByteCat 感谢评论，看来还是不适合中大型项目。

[JensenQian]

有现成的方案的

https://github.com/openRin/Rin

[asuraa]

哎 主要是我不会 css 布局
这玩意好难

[gorvey]

https://cloudflare.chuhai.tools/
我估计自己部署的还是少数，大部分都是 clone 个开源项目完事

[epiloguess]

我用的部署的 cloudflare pages+nextjs+hono+prisma
坑太多...nextjs 本身就很多坑，prisma 的查询器太大了，workers 打包很容易超出体积限制，
cloudflare 的 binding 只能在 env 里面访问，和 orm 结合初始化实例也算坑?其实可以通过全局变量来解决，这些前面有人都提到了。
免费版 10ms 的限制还是太短了。

不过 workers 本身还是很强的，可以有很多花样，成本也足够低，调用方式也很灵活，用它来分担一部分的运算还是可行的，但是 all-in 的话，我觉得还不行

[codehz]

我一个用来跑 rss 订阅推送，中值 CPU 时间 45.7ms ，仅用了 D1 服务（
虽然理论上跑 vps 上也一样，但 worker 跑起来不需要维护（
另一个是 cloudflare pages ，用来跑 telegram bot ，同时集成了 webhook 模式和 mini app 的网页，还使用 queue 来实现定时任务（因为 worker/pages 本身不能长时间执行）
serverless 这玩意主要得顺着思路用，不能用传统的程序逻辑来写

[1rv013c6aiWPGt24]

@codehz rss 订阅推送？老哥能不能给个代码？

[codehz]

@UncleCAT4 单纯按订阅渠道推送到 tg 群的不同 topic 而已，主要是给我一键离线下载用（（至于为啥不直接下载，首先 worker 就不行，其次还想给大家一起用）

[codehz]

@UncleCAT4 https://github.com/codehz/tganime <- 哦忘记发了

[Yadomin]

Serverless 这种东西看起来美好，但是当请求量上去之后会发现比传统服务器更贵

[lisongeee]

感觉比较适合反向代理这种无状态但是又不能完全静态的场景

[protonme]

部署了整套后端服务，包括 d1 数据库，kv ，R2 ，webp wasm 转码之类的。成本非常低，免维护，易部署（ GitHub Actions 自动部署）。每天大约 100k 请求。

webp 转码，设置最慢压缩，大约消耗 6-10s cpu time ，所以得放在 queue 里，异步处理，不会阻塞主线程。

做了 100% coverage unit test ，依赖自动 merge ，时刻保持依赖最新。

[protonme]

但是一开始就要以 serverless 的思路来设计，尤其是数据（因为很多时候是数据没办法无状态），例如用 uuidv4 来确保全球唯一性和无状态性，这样就不需要等待数据库返回主键。包括 cache 的设计，如何保持全球低延迟。

[protonme]

有个问题是因为实在太新了，很多 best practice 没有稳定下来，例如 @ByteCat 提到的 Hono ，之前 CF 官方推荐的是 itty-router 现在又变成 Hono 了。包括 test 库也一直在变。

[Amose2024]

请问博客用的什么文本编辑器？

[qweruiop]

serverless 这个东西开始不贵，后期太贵。
2 年前入了 cf worker 的坑，后期一旦上量，每天几千到几万 usd 的跑不掉。
最开始想的是，访问上去了，也不会计较这点调用费。但是当访问上去了，才知道同样的成本，用传统服务器的性能又会比 worker 高。。。

[jamfer]

@Amose2024 自己写的 UBB 编辑器，没用 Markdown

[liuliancc]

我用 Nextjs 和 Prisma ，Prisma 不支持 edge 运行时，感觉用 workers 会有很多坑，还是在用 Vercel 部署。不过我非常喜欢用 honojs 写后端，然后部署在 workers 上，非常合适

[sparkinglemon]

@liuliancc prisma 的竞品 drizzle orm 支持 edge 运行时比如 D1 （ https://orm.drizzle.team/docs/get-started-sqlite#cloudflare-d1 ）