作为目前世界上仅有的几款实时数据库,我们没有选择的余地。而firebase是google的产品,国内已经没法使用,仅剩下supabase了。
这种数据库的好处是,我写一个离线的前端页面,不用放服务器上,任何人打开这个页面,都可以直接使用了。缺点是实时数据库租用应该很贵。
废话不多说,写这篇的目的是将firebase的应用转为supabase,方便我们自己测试或使用。那么真正要使用这种实时数据库,要缴纳不菲的费用,或者你自己搭建supabase,用docker,但是我本机没有成功,这点很重要。
在转换前,首先是概念上。
1. 数据库不同
firebase是nosql,所以没有建表的命令,你拿到一个firebase应用,你看不到表的结构哦。还要猜出字段的类型。它存储的是json树状key-value结构。
supabase是传统的postgres关系型数据库,要先建表,并且字段的类型不能搞错。
所以firebase不用关心字段类型,查询不用专门写关联查询语句,子孙节点自动返回;添加数据也是直接给定路径就好了。supabase就要关注这些关联查询了,写入数据也是先写入父节点,等返回id后再写入子节点。
有了这个概念,或者说你把表研究透了,就成功一半了。
2. 注册新用户
然后到supabase官方页面注册啥的不在赘述了。值得注意的是,它官网只能用github账号登录,不支持注册。而supabase的author(对这个概念比较陌生的后面会说)里,可以任意添加用户。添加用户可以在页面上操作,不要勾选“需要邮件确认”,因为很麻烦。当然,用前端代码JavaScript来批量添加用户就很方便(代码见它的API)。
实施数据库的author功能比较全面,用于鉴权足够了。比如你浏览器已经登录了github,那么用前端代码就可以直接登录实施数据库。如果用户不登录,那就看你的应用设计了,比如检查到用户没登录,就不能写入数据库,可以查询等等。
3. 文档对比
经过逐条对比firebase和supabase的API(后者对应要看Supabase JavaScript Library v2.0的文档哦)v2.0文档
2.0和1.0还是有不少区别,就不一一列举了。
supabase的API比firebase还是欠缺不是一点点,好在基本还够用,特别是联合查询之类,还挺凑合的。什么外键、关联啊(后面补充),文档做的特别好,对于example,有建表语句、有代码、有返回结果(比firebase文档在这方面好太多),真是非常齐全,不想gorm的文档和其他数据库语言的文档,你也搞不清它案例用的数据表是啥样的。
supabase相对firebase没有once这个查询语句,就是只查询一次。实时数据库因为每个用户都是用websocket长连接,而数据库记录这个用户,对于代码中使用了once的,那么自始至终就只查询一次,不会再查询第二次。而实时数据库就是这样的特点,每一次更新,删除或添加或修改,都会向所有用户广播一次,也就是通知到每个用户,我变化了,告诉你们哪里变化了。
supabase里也没有ondisconnect,用户断了连接后,没有反馈。
另外,就是firebase变化的广播内容由于是json结构,所以连带子孙节点都会返回。supabase由于是关系型数据库,只是广播变化的字段部分,关联的部分不会返回,需要再单独用关系型查询语句再查询出关联的部分。
firebase监听数据库变化一般用on,once是监听变化一次,还可以用off关闭监听,这些功能比supabase是增加的。
firebase添加数据有set和push等,后者是添加子节点数据,supabase一律用insert。
说完了概念,接下来会具体看看API对应的代码,其实也就是将增删查改对应修改一下即可,难在入门,难在了解它们本质的区别。
哦,对了,在supabase里建表,最好用sql语句,这样你下次重复建表就方便了。如果你手动建表,下次还得重新来过。当然,如果手动建表,然后自动生成sql语句那就方便了,我找了很久好像没找到。
待续……
标签:建表,supabase,数据库,用户,查询,firebase,应用 From: https://blog.51cto.com/3xxx/5846764