关于使用 Supabase 和 Cloudflare 开发专用 Web 应用的事项

您好，我是Liberogic的CTO大冢。

针对企业网站和系统的网络攻击接连发生，前天PHP的一个严重漏洞也引发了关注。

今天要介绍的Web应用开发，在架构上尽可能减轻了此类安全对策和运维方面的负担，但关于安全的话题，我想另找机会再来探讨。

申请审批、会员专属主页、面向合作伙伴的门户网站、工时管理等，根据各公司业务量身定制的Web应用构建中，我们经常使用Supabase和Cloudflare的组合。

过去，我们需要在AWS上分别搭建EC2、RDS、S3、Cognito等组件，或者搭建Linux服务器并自行部署Web服务器、中间件和框架，数据库、认证、API和文件存储各自的搭建与运维都十分费事。
使用Supabase和Cloudflare后，这些基础部分交由服务本身承担，就能专注于开发该应用真正需要的功能了。

本文将简要介绍组合使用Supabase和Cloudflare可以构建哪些专用Web应用。

什么是专用Web应用

这里所说的“专用Web应用”，是指根据公司和业务需求量身定制的Web应用程序。
例如这样的应用。

• 内部申请与审批系统
• 会员专属主页
• 合作方专用门户
• 工时与考勤管理
• 项目管理
• 咨询管理
• 面向门店与网点的管理系统
• 文件共享与审核系统
• 问卷与诊断结果管理
• 各类业务管理后台

收到此类咨询时，我们会先调研能否通过现有的 SaaS 或套装产品实现。对于常规业务而言，采用现成产品往往更快速、成本更低。

但实际将需求逐条梳理后，往往很难找到与“正是我们想要的功能”完全吻合的产品。
例如企业特有的审批流程、因部门或网点而异的信息展示需求，以及与现有系统的对接需求等。

这样一来，与其让业务去迁就SaaS、靠持续运维来勉强应对，不如开发一个贴合业务的专用Web应用，这样更能让客户的业务顺畅运转，是更好的方案。实际上，很多情况下我们都会做出这样的判断。

Supabase可以统一提供Web应用的数据基础设施

Supabase是一项服务，可以统一提供Web应用所需的后端功能。

从全球范围来看，这也是发展势头相当强劲的服务，使用它的开发者已超过1,000万人。据美国知名创业加速器Y Combinator公布，其最近一期项目中有55%采用了Supabase，它正逐渐成为新服务后端的常规选择。

这些实绩主要来自拥有大量C端用户的服务，但我们认为，这一机制同样可以直接应用于面向企业内部或合作方、可称为“内网式使用”的业务Web应用，因此才予以采用。

主要功能包括：

• Database（托管的PostgreSQL数据库）
• Auth（用户认证与登录）
• 自动生成API（定义数据表后，即可直接使用REST API）
• RLS（Row Level Security：行级权限控制）
• Storage（文件存储）
• Realtime（实时通信）
• Edge Functions（无服务器运行的 API 处理）

等。

如果是业务应用，可以在 Supabase 数据库中管理用户信息、项目信息、申请数据、操作历史等内容。

此外，使用 Supabase Auth 还可以直接为应用添加登录功能。这种 Auth 与业务应用很匹配，是因为它支持通过 Microsoft 账户和 Google 账户登录。

如果公司已经在使用 Microsoft 365 或 Google Workspace，员工就可以直接用平时使用的账户登录。无需为应用单独发放新的 ID 和密码，入职、离职时的账户管理也可以统一到现有体系中。

过去，数据库和认证通常需要分别准备并再进行连接，这样的架构并不少见。而使用 Supabase，则可以将数据与认证整合到同一个基础平台中。

使用 RLS（Row Level Security，行级安全）时，

• 可以只让用户看到自己的数据
• 只展示同一据点的数据
• 管理员可以查看全部数据

这类控制也可以在数据库端进行。

在业务应用中，这种权限控制非常重要。

使用 Cloudflare 进行前端分发

不过，仅靠 Supabase 有些事情是无法完成的，那就是“网站（前端）托管”。
数据库和 API 可以交由 Supabase 承载，但用户通过浏览器访问的页面本身，需要从其他地方进行分发。

这类分发服务的代表是 Vercel 和 Cloudflare。我们选择了 Cloudflare，原因有以下几点。

• 可以在 Cloudflare 上统一管理从 DNS / CDN / WAF 到应用分发的全部环节
• 借助 Cloudflare Workers，不仅可以分发前端，还能统一承载 API 处理和外部服务集成
• 提供 R2（存储）和 Access（访问限制）等与业务应用高度契合的周边服务
• 按传输量计费的思路简单明了，预算也容易掌握。

提到 Cloudflare，很多人可能首先想到的是 CDN 或 DNS，但如今它也已经足以作为 Web 应用的运行平台来使用。

从制作公司的角度梳理 Cloudflare

也就是说，在这种架构中，Cloudflare 负责接收用户的访问，并返回页面和 API；而其背后的数据、认证和权限控制则由 Supabase 承担，两者分工明确。

将 Supabase 与 Cloudflare 结合使用

例如可以采用以下架构。

运行在 Cloudflare Workers 上的应用接收用户的访问，并返回页面和 API；在其背后，Supabase 负责数据和认证。

根据需要，还可以通过 SendGrid 发送邮件，将文件保存到 Box 等外部存储，或与其他业务系统进行 API 集成。

这种架构的优点在于，整体由标准技术组合而成，对接对象不受限制。
只要支持 API 集成，无论是现有的核心业务系统，还是已经在使用的 SaaS，都可以自由对接。不会像一些业务套件那样存在“该产品只能与○○对接”之类的限制。

例如可以构建以下类型的业务应用

内部申请与审批应用

这是一款由各分支机构及负责人登记申请、由上级及管理员进行审批的应用。
根据登录用户的不同，

• 仅显示本人的申请
• 显示本分支机构内的申请
• 管理员可查看全部申请

等权限控制也可以实现。
简单来说，就是将原本通过邮件和 Excel 处理的业务，直接转化为 Web 应用。

面向合作伙伴的门户

为每个合作伙伴发放登录 ID，

• 资料查阅
• 文件上传
• 进度确认
• 咨询
• 合同信息确认

还可以搭建用于进行此类操作的门户网站。
按交易方控制展示内容等功能，也相对容易实现。

工时与考勤管理

适用于员工按项目或负责人录入工作时间和工时并进行汇总的应用。
如果存在通用考勤 SaaS 难以处理的独特规则或公司专属的汇总方式，定制 Web 应用会更加合适。

这类业务如果强行套用现成产品，有时反而会变得更麻烦。

据点管理系统

也适用于由总部统一管理、从全国各门店或营业所录入信息的 Web 应用。

从几人使用的内部工具，到多据点使用的业务应用，都可以应对。
并不是说“使用 Supabase 就只适合小规模”。
只要设计得当，可以用于相当广泛的场景。

例如，我们公司协助开发的应用包括以下类型。

丰田汽车社交媒体运营管理系统「TOYOTA Social Hub」UI/UX设计与系统开发

判断专用Web应用而非SaaS的标准

前面我们介绍了专用Web应用的优势，但并非总是专用Web应用才是正确答案。
下面列出我们在实际咨询中积累的参考标准，帮助判断何时应该“自主开发”。

• 长期依靠人工运营来弥补
  审批流程因部门而异、例外处理较多等，业务流程偏离了SaaS的设计假设，仅靠设置无法完全覆盖
• 权限和展示控制过于精细
  希望按部门、据点或客户展示不同的信息，但SaaS的权限功能粒度不够
• 业务跨多个工具进行
  在Excel、邮件和多个SaaS之间来回切换，转录和复制粘贴已成为日常
• 自定义的管理项目和统计规则较多
  强行将公司特有的数据塞进SaaS的通用字段中
• 现场功能过多或不足
  通用SaaS导致界面复杂，现场人员不愿使用；或者缺少真正需要的功能

如果只符合其中一两项，通常通过调整SaaS的设置或运营方式就能应对。
但如果多项同时符合，日常的“小麻烦”不断累积，我们认为这就是考虑定制专用Web应用、使其贴合业务的时机。

事实上，“想把Excel管理的信息网络化”“想把邮件往来的审批系统化”“想把在多个SaaS之间切换的业务整合到一处”，这类关于专用Web应用的咨询，往往就是从这些情况开始的。

小步起步，边使用边逐步完善

说到这里，我们一直在介绍技术架构，最后想分享的，与其说是 Supabase 和 Cloudflare 本身的功能，不如说是项目的推进方式。

“应该做什么”，在需求定义文档中往往并不容易看清

一般的软件开发通常从需求定义开始。先把现有业务整理成文档，再据此设计满足这些需求的系统，这是常见的推进方式。

不过，这种推进方式也有其弱点。文档上可能已经覆盖了业务的方方面面，但“实际用起来是否顺手”“这个功能是否真的必要”这些视角往往被忽略，需求就这样不断堆积。
尤其是那些刚负责 DX 推进、但本身并不擅长系统开发的人，仅凭文字和表格来判断需求是否合理，想必相当困难。

因此，Liberogic 并不会一开始就花大力气打磨厚厚的需求定义书，而是借助 Figma、v0、Claude Code 等工具制作原型（可实际操作的界面试作稿），让客户亲自上手体验，再以此推进讨论。

与纯文字的需求定义不同，亲自操作界面，就能以极为真切的方式体验“用起来怎么样”。有趣的是，这时大家的关注点会从“确认文档”转向“改善业务”，比如“有了这个画面，业务的某个环节会轻松很多”“另外那项工作能不能也自动化”。

在定制 Web 应用开发中，真正重要的往往正是“应该做什么”这一部分。我们认为，这一点并不是在文档里看清的，而是在通过原型共享印象的过程中逐步显现的。

先实现基础部分并率先上线

我们不会先把所有需求确定下来再一次性做完，也就是所谓的瀑布式推进。原型确定大致方向之后，我们会先实现登录 / 数据登记 / 列表显示 / 管理画面等基础部分并率先上线。

之后让大家实际使用，同时确认使用感受和现场反馈，再逐步追加审批功能、邮件通知、文件管理以及外部 API 集成等功能。
Supabase 与 Cloudflare 的架构与这种循序渐进的推进方式非常契合。

根据预算和业务价值逐步扩展

“先小规模搭建，再根据需要扩展”也关乎预算。例如，

• 按照全年预留的预算，逐步开发功能
• 先小范围上线，待业务价值显现后再追加投资，逐步完善应用

等推进方式。无需一开始就一次性准备大笔开发费用，也能拥有并逐步培育业务应用。我们认为，业务应用与其一开始就把需求定得完美无缺，不如边使用边改进，往往效果更好。

总结

通过将 Supabase 与 Cloudflare 结合使用，可以以相对精简的架构构建专用 Web 应用，涵盖身份认证、数据库、权限控制、API 和文件分发。从企业内部的小型业务工具，到面向合作伙伴的门户网站，再到多据点使用的业务系统，都可以根据用途逐步扩展。

不过，真正重要的并非 Supabase 或 Cloudflare 这些工具本身，而是推进方式。

• 先通过原型图共享“实际使用的情景”，找出应当开发的内容
• 只开发基础部分，尽快上线
• 边使用，边根据预算和业务价值逐步培育

这种推进方式过去并不现实。因为软件的实现成本和基础设施的搭建成本都很高，必须在事先把所有内容都确定下来之后才能开始动手。

如今，借助 Supabase 和 Cloudflare 等现代技术栈，以及利用 AI 智能体进行开发和原型制作，我们已经可以按照更接近理想的方式推进项目：先做出可以实际操作的东西，再在使用中不断完善。Liberogic 所擅长的，正是这种推进方式。

“这项通过 Excel 和邮件处理的工作，能不能做成 Web 版呢？”“试过 SaaS，但总觉得不太适合我们的业务。”即使是这样的初步咨询也没问题。我们会和您一起思考符合业务需求的架构，欢迎随时与我们联系。