又停更了一段时间，主要是沉迷 switch 游戏，有一段时间没有写点什么了。最近看了看可以快速搭建 rest 接口到 db 访问的几种不同的开源工具，这个有点算是 lowcode 或者 BAAS（backend as a service）的领域，据说在最近也很火啊？起因是我发现在做记单词的程序中，我还是很希望能够有一个快速搭建出基于 db 表的增删改查的接口平台，同时类似 data admin 的后台，可以方便的通过界面来查看和直接修改 db 数据。其实 django 已经能很接近地提供类似的功能，django admin 只需要通过设定一些配置，就可以自动在后台增加数据表的 UI,而通过 DRF（django rest framework）也可以快速地创建 rest 接口。不过我还是看了看其他几个项目。
directus
同类型的更出名的项目应该是 strapi，他们叫 headless cms。directus 代码更简单一些，所以我试用了一下并简单地看了下 directus 的代码结构。如果实际使用的话，需要注意，strapi 的免费部署有 role 个数限制，而 directus 没有。不过要二次开发的话，注意 strapi 是 MIT 协议，而 directus 是 GPL 协议。 这类 headless cms 特点是 web UI 比较好看，对数据表的字段编辑非常的图形化，并且更偏向外观显示，比如是可视化编辑文本，还是简单的 text，还可以设置图表等。而不是直接设置 varchar(64)这种。所以这类产品应该是更倾向于面向非程序员群体来操作和编辑后台的。这样业务需求方可以直接创建和修改所需要的表结构，然后框架就是自动具备这些表的 rest api。或者可以通过 admin 的角色分类，提供一个可供非程序员的 admin 后台，来让这些人来查看和编辑数据。 directus 是一个单体代码仓库。express+vue 组成。原理应该是通过 knex 来生成 sql，实现自定义数据表的 rest api。同时在创建和修改自定义表的字段时，也会生成对应的 sql DDL 语句来创建或修改数据表。同时还有自带的用户和权限管理，可以对接口进行鉴权。还有静态文件管理。相当于 directus 是一个在图形界面上定义数据 model,然后自动生成 rest api 和 admin 管理页面，还附带用户和文件管理的加强版 django admin。对于博客，内容管理平台类型的系统开发应该是非常适用，只需要开发对应的前端即可，还附带了后台系统。
supabase
supabase 是对标 firebase 。但是在我看来，和 headless cms 还是有一些相似的。不过对于 supabase,我觉得更偏向于有程序背景的人适用。适用的人群确实是和 firebase 的 cloud storge/realtime/auth 部分近似。 不过从技术上看，supabase 和 firebase 应该还是有很大不同的。supabase 是基于 postgresql 来做的扩展，其中应该有不少特性是基于 postgresql 的，所以只能适用 postgresql。 supabase 不是单体应用，而且各个模块好像来不同的项目组成，他们的整合能力还挺厉害。而且使用的语言都不一样。lua/go/haskell/Elixir/TS。不知道是不是有意为之。 设计理念上，他们是强依赖 postgresql 的。比如数据的验证是在 sql 里定义的，并且也是依赖 db 来校验的。如果要是想要复杂的 db 操作，可以创建存储过程。他们的 graphql 模块，也是要准备借助 PLpgSQL 来实现。 从它提供 js/ts/flutter 等等客户端 lib 来看，supabase 是面向程序开发者使用的。他们的 admin 也是更偏向开发来使用，数据查看更像是在使用类似 mysql workbench。
总结
如果想快速地搭建一个增删改查的接口，专注于前端的工作，那么这两种工具都是可以的。如果有需求给使用方开发后台，那么 directus/strapi 更合适。如果是需要类似 realtime,或是相对复杂的 sql 查询，或是对 db 有更底层的控制，那么 supabase 应该更合适。 一点感想，这些项目和在一个大型公司，在一个接口里要塞大量逻辑的行为很不相同。在互联网程序开发盛行的今天，其实还有大量的领域可以有非常不同的设计和开发思路。比如，外键，这两个项目应该说是比较依赖外键来构建数据表之间的联系的。比如，supabase 中，竟然把大量的逻辑放到 db 中，比如数据字段验证，我之前甚至不知道 sql 还有 check 语句；比如存储过程，这个应该是很复古的一种方式了；比如用户验证，要用到 db 的 row level security；他们还要在 postgresql 里设置自定义的 function 来实现自定义功能。我想这和我们大部分人接触的‘原则’是截然相反的吧，为了数据库性能，我们会拦截无效的请求，缓存请求，就是为了尽量减少 db 的消耗。而其实，当 db 不是瓶颈的时候，大可以将一些工作交给 db，来减少自己服务的开发成本。就像数据库反范式设计一样，这也是一种‘反原则’实现。