《林一的 Cloudflare 通关记》第 5 篇-网站要有个"厨房"——Cloudflare Workers搭建后端API
《林一的 Cloudflare 通关记》第 5 篇
周一早上,林一兴冲冲地打开电脑,准备给"星火AI"的前端页面加上后端接口。
上周他用 Cloudflare Pages 把前端部署上线了,页面看着挺漂亮,但点来点去只有一个静态展示页。产品经理小王周五下班前甩来一句话:"这个网站不能交互,跟PPT有什么区别?用户连个注册登录都做不了。"
《林一的 Cloudflare 通关记》第 5 篇
周一早上,林一兴冲冲地打开电脑,准备给"星火AI"的前端页面加上后端接口。
上周他用 Cloudflare Pages 把前端部署上线了,页面看着挺漂亮,但点来点去只有一个静态展示页。产品经理小王周五下班前甩来一句话:"这个网站不能交互,跟PPT有什么区别?用户连个注册登录都做不了。"
《林一的 Cloudflare 通关记》第4篇
周三下午,老张给林一发了一条消息:「把星火AI的前端代码推到GitHub上,然后部署起来。」
林一精神一振——终于可以干正事了。他熟练地 git init、git push,代码推到了GitHub仓库。然后,他打开了某云服务商的控制台,开始挑选云服务器。
《林一的 Cloudflare 通关记》第3篇
周一早上,林一刚端着咖啡坐下,企业微信就弹出来一条消息。
产品经理小王:「林一,星火AI的页面我刚才在手机上试了一下,加载了整整8秒。我在朋友圈看到人家说,网页加载超过3秒,53%的用户就会离开。咱们这个……是不是有点太慢了?」
《林一的 Cloudflare 通关记》第 2 篇
上回说到,林一把域名托管到了 Cloudflare,网站能访问了,但浏览器地址栏却亮起了"不安全"的红灯。今天,老张要给网站穿上一件看不见的盔甲。
第二天一早,林一到办公室的第一件事就是打开浏览器,输入 http://xinghuo-ai.com。
页面倒是能打开,但地址栏左边那个醒目的"不安全"标签,像一块狗皮膏药一样贴在那里,格外碍眼。
《林一的 Cloudflare 通关记》第 1 篇
一个实习生,一个架构师,一个从零开始的 AI 网站。故事,从给网站"起名字"开始。
最近开始捣鼓 cloudflare,这个互联网赛博大善人,上面免费提供了各种好用的服务,在使用的过程中,我就在想,这么多的服务,如何才能都用起来呢? 实践过程中也遇到了一些问题,于是我就想分享一下,但是过于枯燥的文档估计也不爱看,于是我就想通过一系列的小故事,将 cloudflare 的免费服务串联起来,并使用 AI 来进行加工润色,我不避讳使用 AI,有了AI 的加持,可以让文章更加的顺畅,效率也更高,所以这个系列的文章我一般都会使用 AI 来加工一下。希望对大家有所帮助吧。
codespace 是托管在 github 上的云开发环境。每个 codespace 都由 GitHub 托管在虚拟机上运行的 Docker 容器中,可以理解为 github 为开发者提供的云端虚拟机。
ClawdBot(后更名为 MoltBot,再之后又更名为 openclaw) 是最近非常火的 AI 智能助理项目,但是将其部署在自己的工作机还有些危险的,因为权限太大了。为此我们可以将 openclaw 部署在闲置的 Mac mini 或者 vps 中。
有了 github codespace, 我们可以不必购买服务器就可以体验一下 openclaw 的神奇能力
最近使用 claude code 过程中,想要查看一下具体的请求数据,学习一下它的提示词,但是 claude code 是个在 shell 中运行的工具,不太好查看,这里提供一种使用 mitmproxy 来抓包的方法,类似的还有使用 wireshark 等。
敏感词过滤,这个看起来“老掉牙”的功能,其实藏着不少算法的门道。
你可能不知道,大厂评论系统、弹幕平台、甚至聊天机器人背后,都在悄悄跑着一台“小型自动机”——DFA。
今天我们就用 Python,带你从最简单的思路出发,一步步搞懂:
为什么大家都爱用 DFA 算法 来做敏感词过滤。
假设你用 FastMCP 写了一个最简单的工具函数:
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("My Server")
@mcp.tool(name="打招呼",description="简单的打招呼")
async def hello() -> str:
return "hello world"
这个函数很简单,运行也没问题。
但是一旦你想要在函数里获取请求头、用户信息、IP、Token 等信息(一般用于一些权限校验,数据打点等操作),就会发现:
函数没有直接的 Request 对象!
这时就要用到关键角色 —— ctx: Context
如果你用 Python 开发过 MCP 服务,大概率遇到过这样的场景:服务在本地跑得好好的,一到生产环境就各种幺蛾子。特别是当你想要多机部署时,发现负载均衡器怎么配置都不对劲。
问题根源:SSE 的“粘性会话”魔咒
传统的 SSE(Server-Sent Events)模式有个致命缺陷:需要维护长连接和会话状态。这意味着: