架构
Supabase 是开源的。我们选择可扩展的开源工具,并使其易于使用。
Supabase 并非 Firebase 的 1:1 映射。虽然我们正在构建 Firebase 提供的许多功能,但我们的方法不同:我们的技术选择截然不同;我们使用的所有工具都是开源的;并且尽可能地,我们使用和支持现有工具,而不是从头开发。
最值得注意的是,我们使用 Postgres 而不是 NoSQL 存储。这个选择是深思熟虑的。我们相信没有其他数据库能够提供与 Firebase 竞争的功能,同时保持超越它的可扩展性。
选择你的舒适度#
Supabase 的目标是让 所有 Postgres 易于使用。这并不意味着你必须使用它的全部功能。如果你是 Postgres 老手,你可能会喜欢我们提供的工具。如果你以前从未用过 Postgres,那么从小处着手,逐步学习。如果你只想将 Postgres 视为一个简单的表格存储,那也没问题。
架构#
每个 Supabase 项目都包含几个工具
Postgres (数据库)#
Postgres 是 Supabase 的核心。我们不会抽象 Postgres 数据库——你可以完全访问和使用它。我们提供工具,使 Postgres 像 Firebase 一样易于使用。
- 官方文档:postgresql.org/docs
- 源代码:github.com/postgres/postgres (镜像)
- 许可证:PostgreSQL License - 语言:C
Studio (仪表盘)#
用于管理数据库和服务的开源仪表盘。
- 官方文档:Supabase 文档
- 源代码:github.com/supabase/supabase
- 许可证:Apache 2
- 语言:TypeScript
GoTrue (Auth)#
一个基于 JWT 的 API,用于管理用户和颁发访问令牌。它与 PostgreSQL 的行级别安全性和 API 服务器集成。
- 官方文档:Supabase Auth 参考文档
- 源代码:github.com/supabase/gotrue
- 许可证:MIT
- 语言:Go
PostgREST (API)#
一个独立的 Web 服务器,可将你的 Postgres 数据库直接转换为 RESTful API。我们将其与我们的 pg_graphql 扩展一起使用,以提供 GraphQL API。
- 官方文档:postgrest.org
- 源代码:github.com/PostgREST/postgrest
- 许可证:MIT
- 语言:Haskell
Realtime (API & 多人游戏)#
一个可扩展的 WebSocket 引擎,用于管理用户状态、广播消息和流式传输数据库更改。
- 官方文档:Supabase Realtime 文档
- 源代码:github.com/supabase/realtime
- 许可证:Apache 2
- 语言:Elixir
Storage API (大型文件存储)#
一个与 S3 兼容的对象存储服务,它在 Postgres 中存储元数据。
- 官方文档:Supabase Storage 参考文档
- 源代码:github.com/supabase/storage-api
- 许可证:Apache 2.0
- 语言:Node.js / TypeScript
Deno (边缘函数)#
JavaScript 和 TypeScript 的现代运行时。
postgres-meta (数据库管理)#
一个 RESTful API,用于管理你的 Postgres。获取表、添加角色和运行查询。
- 官方文档:supabase.github.io/postgres-meta
- 源代码:github.com/supabase/postgres-meta
- 许可证:Apache 2.0
- 语言:Node.js / TypeScript
Supavisor#
一个云原生、多租户的 Postgres 连接池。
- 官方文档:Supavisor GitHub Pages
- 源代码:
supabase/supavisor - 许可证:Apache 2.0
- 语言:Elixir
Kong (API 网关)#
一个基于 NGINX 构建的云原生 API 网关。
- 官方文档:docs.konghq.com
- 源代码:github.com/kong/kong
- 许可证:Apache 2.0
- 语言:Lua
产品原则#
我们的目标是提供一种大型公司会自行设计的架构,然后围绕该架构提供易于使用的工具,供独立开发者和小型团队使用。
我们使用一系列原则来确保可扩展性和易用性永远不会相互排斥
一切独立运作#
每个系统必须作为一个独立的工具运作,尽可能减少活动部件。这个 litmus 测试是:“用户是否可以用一个 Postgres 数据库运行这个产品?”
一切集成#
Supabase 是可组合的。即使每个产品独立运作,平台上的每个产品也需要将其他产品提升 10 倍。为了集成,每个工具都应该暴露一个 API 和 Webhooks。
一切可扩展#
我们慎重地添加新工具,而更倾向于扩展现有工具。这与许多云提供商的产品扩展到细分用例的做法相反。我们提供开发者使用的基本组件,允许他们实现任何目标。更少,但更好。
一切可移植#
为了避免锁定,我们使其易于迁移进出。我们的云产品与我们的自托管产品兼容。我们使用现有标准来提高可移植性(例如 pg_dump 和 CSV 文件)。如果出现与“Supabase”方法竞争的新标准,我们将弃用该方法,转而支持该标准。这迫使我们在用户体验上竞争。我们的目标是成为最好的 Postgres 托管服务。
着眼长远#
我们牺牲短期收益来换取长期收益。例如,运行 Postgres 的一个分支,其中包含只有我们的客户需要的新功能,这很诱人。相反,我们更愿意支持将缺失的功能上游的功能,以便整个社区受益。这样做还有一个好处,就是确保可移植性和寿命。
为开发者构建#
“开发者”是一种特定的用户画像:他们是构建者。在评估工作量与投入的效率时,开发者由于他们可以构建的产品和系统的类型而具有很高的效率。随着开发者画像随时间的变化,Supabase 将继续演进产品以适应这种不断变化的画像。
支持现有工具#
Supabase 尽可能地支持现有工具和社区。Supabase 更像是一个“社区的社区”——每个工具通常都有自己的社区,我们与之合作。我们以协作的方式对待开源:我们雇佣维护者、赞助项目、投资企业并开发我们自己的开源工具。