
在 Cloudflare Worker 中通过 Supabase JS 查询 Supabase 数据【免费下载链接】supabaseThe Postgres development platform. Supabase gives you a dedicated Postgres database to build your web, mobile, and AI applications.项目地址: https://gitcode.com/GitHub_Trending/supa/supabaseSupabase 提供的是基于 Postgres 的完整后端平台而 Cloudflare Workers 是运行在全球边缘节点的无服务器运行时。这篇实战指南以仓库中的 examples/with-cloudflare-workers 示例为蓝本完整演示了如何在 Cloudflare Worker 中安装并初始化supabase/supabase-js客户端把项目 URL 与发布密钥通过wrangler secret安全注入 Worker然后执行articles表查询并以application/json响应返回给浏览器。读完本文你将掌握一套可复制、可运行的“边缘端直连 Supabase”的最小实现并能看懂仓库中完整可运行的 src/index.js 源码。场景概述为什么要在边缘端查询 SupabaseSupabase JS即supabase/supabase-js是一个 NPM 包它为 JavaScript / TypeScript 应用访问 Supabase 项目提供了简单统一的接口。它支持三种典型能力查询与变更数据通过对象关系映射ORM风格语法读写 Postgres 表中的数据实时订阅监听数据库变更并推送实时事件本文不展开服务端或客户端运行既可在浏览器中运行也可运行在 Node.js、Deno、Bun 以及 Cloudflare Workers 等运行时。Cloudflare Worker 与 Supabase 的组合价值在于Worker 在离用户最近的边缘节点执行开发者可以在请求到达源站之前完成轻量数据聚合、权限校验或响应加速。本文对应的示例正是把“读取文章列表并返回 JSON”这一任务整体下沉到 Worker 完成。在仓库中examples/with-cloudflare-workers 是一个自包含的最小示例目录完整结构如下examples/with-cloudflare-workers/ ├── src/ │ └── index.js # Worker 入口创建 Supabase 客户端并查询数据 ├── package.json # 依赖与脚本wrangler、supabase/supabase-js ├── wrangler.toml # Cloudflare Worker 配置 └── README.md # 教程说明准备工作获取项目 URL 与访问密钥在使用 Supabase JS 之前需要两个来自 Supabase 项目的信息项目 URL形如https://project-ref.supabase.co的 RESTful 端点地址访问密钥用于通过网关鉴权。该密钥可在 Supabase Dashboard 的Settings API中获取。原文教程里该密钥被称作Anon Key。需要说明的是随着生态对密钥语义的澄清当前仓库内多个示例已将代码与文档中的命名统一为publishable key可发布密钥例如 src/index.js 中的环境变量名是SUPABASE_PUBLISHABLE_KEYnextjs-full 示例也使用NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY。本质上它就是createClient的第二个参数用于网关层鉴权。这类密钥在客户端环境暴露是预期行为因此使用时应配合数据库行级安全策略RLS约束可读数据范围不要把service_role这类高权限密钥放进边缘 Worker。第一步安装 Supabase JS在 Worker 项目目录内用 npm 安装官方客户端npm i supabase/supabase-js仓库中的 package.json 给出了完整依赖声明与本示例一致{ name: supabase-at-the-edge, devDependencies: { wrangler: 2.20.1 }, dependencies: { supabase/supabase-js: ^2 }, scripts: { start: wrangler dev, deploy: wrangler publish } }可以看到示例同时声明了两个运行时层面的依赖应用依赖supabase/supabase-js的 v2 大版本开发依赖wranglerCLI此示例锁定在2.20.1用于本地开发、密钥管理与发布。npm scripts 中预置了start等价于wrangler dev与deploy等价于wrangler publish两条常用命令。第二步编写 Worker 入口并查询数据示例的核心逻辑集中在 src/index.js全文不足 20 行逐段拆解如下。首先导入客户端工厂函数并导出一个默认对象。Cloudflare Worker 的模块化语法约定默认导出的对象需要暴露一个fetch方法作为请求的入口处理器import { createClient } from supabase/supabase-js export default { async fetch(request, { SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY }) { const supabase createClient(SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY) const { data } await supabase.from(articles).select(*) return new Response(JSON.stringify(data), { headers: { Content-Type: application/json, }, }) }, }这里蕴含三个关键知识点环境变量的注入方式fetch的第二个参数是env绑定对象其中包含 Worker 可访问的全部环境变量与绑定资源。示例通过解构语法直接取出SUPABASE_URL与SUPABASE_PUBLISHABLE_KEY它们由 Cloudflare 侧以密钥secret形式注入详见下文“密钥管理”一节。客户端初始化createClient(projectUrl, anonKey)是 Supabase JS 的标准初始化签名。第一个参数是项目 REST 端点第二个参数是密钥。初始化完成后即可使用 ORM 风格的查询语法const { data } await supabase.from(articles).select(*)该调用等价于从 Postgres 的articles表读取全量记录返回结果按解构约定放入data字段。仓库中其它示例如 expo-social-auth 的客户端封装采用完全相同的createClient初始化模式验证了这套 API 是跨端一致的。返回 JSON 响应supabase-js返回的是 JavaScript 对象而网络响应体要求字符串或字节流。因此需要先用JSON.stringify(data)序列化随后在Response中设置Content-Type: application/json请求头通知浏览器按 JSON 解析响应内容。这是 Worker 返回结构化数据时的标准做法。第三步配置 wrangler.toml仓库中的 wrangler.toml 内容如下name supabase-at-the-edge main src/index.js compatibility_date 2022-07-26三个字段的含义分别是nameWorker 在 Cloudflare 上的部署名称main入口模块文件即上文中的src/index.jscompatibility_date指定 Workers 运行时的兼容性日期锁定某版本的运行时行为避免将来行为变更破坏现有代码。第四步本地开发运行编辑完成后先通过 wrangler 的本地开发服务器验证代码行为npx wrangler devwrangler dev会在本机启动一个模拟 Workers 运行时的开发服务器绑定wrangler.toml中的入口文件。本地调试时需要注意正式密钥以 Cloudflare 账户级 secret 形式存储默认不会出现在本地环境。实践中可参考 wrangler 对本地变量的支持在开发阶段补充可用的本地配置后再行联调。第五步用 wrangler secret 注入密钥正式环境中项目 URL 与发布密钥不应硬编码进源码而应作为secret密钥存储在 Cloudflare 账户中。Wrangler 提供统一命令创建密钥npx wrangler secret put NAME按提示输入密钥值后该变量会加密保存在 Cloudflare 侧并在 Worker 运行时注入env绑定对象。为当前示例依次创建两个密钥添加 SUPABASE_URL 密钥npx wrangler secret put SUPABASE_URL添加 SUPABASE_PUBLISHABLE_KEY 密钥npx wrangler secret put SUPABASE_PUBLISHABLE_KEY执行上述命令时wrangler 会要求先完成 Cloudflare 账户登录与项目选择随后交互式地读取密钥值。密钥名必须与 src/index.js 中解构的环境变量名完全一致Worker 才能正确取到值。仓库中的配套课程示例 with-cloudflare-workers-kv 使用完全相同的SUPABASE_URL/SUPABASE_PUBLISHABLE_KEY命名约定说明这是一套被反复验证的既定实践。第六步发布部署完成本地验证并注入密钥后发布 Workernpx wrangler publish发布后 Worker 即运行于 Cloudflare 边缘网络任何对 Worker 路由的 HTTP 请求都会触发fetch处理器实时查询 Supabase 的articles表并把数据以application/json响应返回。仓库 package.json 中的deploy脚本封装的就是这条命令。完整调用链小结把整个请求生命周期串起来看客户端请求到达 Cloudflare 边缘触发 Worker 的fetch处理器wrangler 注入的 secrets 通过env绑定对象进入函数作用域createClient(SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY)完成 Supabase 客户端初始化supabase.from(articles).select(*)向 Supabase 项目发起查询读取 Postgres 中articles表的记录JSON.stringify(data)序列化查询结果配合Content-Type: application/json响应头封装为Response返回给调用方。从源码结构可以进一步推断该架构的扩展方向若需要“先返回响应、再后台刷新缓存”的体验可参考仓库中的 with-cloudflare-workers-kv 示例借助 Workers 的context.waitUntil在响应返回后继续更新 KV 缓存——这与本示例共用同一套 Supabase 客户端初始化与密钥注入模式可作为继续深入学习的下一站。需要注意的边界密钥定位SUPABASE_PUBLISHABLE_KEYAnon Key设计上允许暴露在客户端与边缘代码中但它仍受网关与数据库 RLS 策略约束切勿把高权限的service_role密钥放入 Worker 前端代码。运行时差异示例锁定的 wrangler 版本为2.20.1、compatibility_date 为2022-07-26。使用更新版本 wrangler 时个别命令如publish与dev的行为可能存在差异但 secret 注入、env绑定与fetch模块约定是稳定的核心模型。示例用途该目录是一个教学性质的最小示例未包含鉴权、错误处理与分页逻辑投入生产前应补充data为空的兜底、查询失败的状态码返回以及基于 RLS 的数据可见性控制。通过本示例可以看到借助supabase/supabase-js与 wrangler 的 secrets 机制把 Supabase 数据查询下沉到 Cloudflare Worker 仅需一个入口文件即可完成。读者可直接在仓库中对照 README.md、src/index.js 与 wrangler.toml 三个文件进行实践。【免费下载链接】supabaseThe Postgres development platform. Supabase gives you a dedicated Postgres database to build your web, mobile, and AI applications.项目地址: https://gitcode.com/GitHub_Trending/supa/supabase创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考