为什么 Supabase 是 Coderblock Web 应用的默认后端

构建出色的界面只是开始。 一旦应用需要处理账号、持久化数据、文件、权限或支付，就不能只有前端，还需要一个能够支撑真实产品运行的后端。

这正是 Supabase 发挥作用的地方：它是 Coderblock 标准 Web 应用的默认后端。 当你用自然语言描述应用时，Coderblock 不会只生成一个使用临时数据的原型，而是会构建真正的全栈应用：基于 React、Vite、TypeScript 和 Tailwind CSS 的前端，并连接到一个独立的 Supabase 项目。

核心思路很简单：修改界面的同一条需求，也可以同时修改界面背后的系统。

添加注册功能？系统会配置身份验证。 添加新的数据实体？数据库结构也可以随之更新。 添加上传功能？Storage 会参与其中。 添加仅限特定用户使用的功能？相应的权限也会一并定义。

最终得到的后端会与应用共同成长，而不是一个需要日后另行配置的独立部分。

为整个应用提供统一的后端基础

一个 Web 产品很快就可能需要多种不同的后端服务。 预订平台需要管理客户、可用时段、预订记录和管理员角色；电商应用需要处理商品、购物车、订单、图片和支付；数据看板则可能要根据当前登录用户展示不同的数据。

Supabase 将这些组件整合到同一个后端中：

• Postgres：存储应用的结构化数据
• Supabase Auth：支持电子邮件和社交账号登录
• Row Level Security：在数据库层定义访问规则
• Storage：存储应用文件和用户上传的文件
• Deno Edge Functions：运行服务端逻辑

使用 Coderblock，你不必逐个拼装这些服务。每个标准 Web 应用都会获得独立的 Supabase 项目，智能体在实现新需求时，可以同时操作技术栈的不同层级。

例如，你可以输入：

添加预订表和管理员视图。

智能体可以设计数据库结构、将其连接到界面、配置必要的权限，并更新实时预览。 你不必暂停当前流程，手动配置 API、数据库迁移或后端服务。 更重要的是，每次修改都会延续之前的工作。后端不是一组彼此独立的组件，而是会和产品一起演进。

Postgres 让生成的应用真正可用

Postgres 是关系型数据库，能够支撑 Web 应用需要处理的许多核心功能，包括个人资料、商品、预约、订阅、消息和预订等。在通过自然语言开发应用时，这一点尤其重要。

你可以说：

允许客户收藏喜欢的房产。

你不必指定数据表、外键或 SQL 查询。你只需从产品角度描述功能，智能体就会将需求转换为实现该功能所需的数据结构。

Coderblock 还会让你看到对话背后发生的事情。在编辑器的 Backend 选项卡中，你可以查看项目的数据表、已验证用户、Storage 和函数。即使不了解基础架构的每个细节，你依然可以开发应用，同时也能确认界面背后运行着真正的后端。

这与简单的原型有着本质区别。 数据会被实际保存，并在不同会话之间持续存在。<app>.coderblock.dev 上的预览不仅展示产品可能呈现的样子，还允许你测试产品赖以运行的数据流程。

身份验证与权限控制协同工作

登录只是身份验证的一部分。 一个完整的系统还必须管理账号和会话、保护受限页面、将数据关联到用户，并防止用户访问不属于自己的信息。

当你要求 Coderblock“添加登录和用户账号”时，智能体可以将 Supabase Auth 集成到整个应用中，包括注册、登录、会话管理、受保护路由，以及与已登录用户关联的 Row Level Security。需要时，你还可以添加社交账号登录。 每个应用都已包含个人资料表和基础的角色管理结构，智能体因此可以更轻松地为客户、会员、协作者或管理员构建不同的使用体验。你也不必手动开发密码系统或自定义身份验证机制。

Supabase Auth 负责管理用户身份，而 Row Level Security 则定义每位用户可以查看或修改哪些数据。两者之间的区别至关重要。 在前端隐藏按钮，并不代表用户无法访问该按钮背后的数据。例如，数据库层的策略可以确保每位客户只能查看自己的预订，而获得授权的管理员则可以访问全部预订。

借助 Coderblock，这些规则可以直接成为所需功能的一部分，而不必等到界面完成后再单独处理。

无需独立技术栈即可处理文件、集成和服务端逻辑

真实应用通常不只是读取和写入数据。它可能需要处理头像、文档、商品图片或用户上传的其他文件，也可能需要执行高权限操作，或在不向浏览器暴露凭据的情况下与外部服务通信。

Supabase Storage 和 Deno Edge Functions 可以在应用的同一套后端中满足这些需求。 当某项集成需要 secret 时，Coderblock 会通过专门且安全的环境变量提示框进行处理。该值会保存在服务端，不会写入生成的代码，也不会显示在普通对话中。

Stripe 就是一个具体示例。 你可以直接在对话中要求添加订阅或结账功能。在默认的托管模式下，智能体会在收集少量基本信息后为项目配置 Stripe，并由平台处理支付 webhook。

如果你更希望使用自己的 Stripe 账号，可以选择 BYOK 模式。在这种情况下，智能体会安全地请求 STRIPE_SECRET_KEY，并自动配置 webhook。

无论采用哪种模式，Coderblock 都可以创建商品、价格和结账流程，并将支付流程同时连接到应用的前端与后端。 目标始终一致：添加完整的功能，而不只是添加它的可视化组件。

从构想到发布，后端始终与应用同步

Coderblock 的工作流强调连续性。

描述应用。 生成应用。 在实时预览中试用。 继续修改。 完成发布。

修改会在几秒内显示到 <app>.coderblock.dev，因此后端也必须能够与界面同步演进。 这正是将后端整合进开发流程的优势：当产品发生变化时，你可以同时调整数据、权限以及支撑产品的逻辑，而不必在每次迭代时手动重建基础架构。

应用准备就绪后，你可以一键发布到 <app>.coderblock.app，也可以绑定自定义域名，并自动获得 SSL。 Supabase 是标准 Web 应用的默认后端，但当项目有不同需求时，Coderblock 也会采用其他架构。例如，Enterprise Web Platform 项目使用 Python、FastAPI 和 Neon Postgres，以满足特定的平台需求。

不过，对于大多数 Web 应用而言，Postgres、Auth、Row Level Security、Storage 与 Edge Functions 的组合已经提供了完整基础，足以将一个想法变成真正可以运行的产品。

后端不应该成为第二个项目

通过对话构建应用时，你不应该总是在创意、前端、数据库和基础架构之间来回切换。 你应该能够直接说：

“添加客户账号。”

然后说：

“现在让每位客户只能查看自己的预订。”

再接着说：

“添加上传头像的功能。”

每一项需求都应该能够自然地延续到下一项。 这正是后端在 Coderblock 中承担的角色：它不是一个需要在界面完成后另行配置的独立系统，而是应用中与你的想法共同成长的部分。最终，你将获得一个可以通过同一个对话界面持续生成、测试和开发的全栈应用。