xmsz
2022-06-06 14:08:05 +08:00
就我目前来说
我是想找个前端直接查询 sql 的方案
我的场景是，我在在做 DEMO 项目，然后遇到数据的存储。本来是用 indexedb 的，但是这玩意和 localstorage 一样的限制，所以不能满足更多需求
那么就需要一个持久化储存
然后持久化存储有了，但是前端并不能直接访问数据库，需要某个中间服务去处理，而且这个中间服务必须简单，不能花太多精力
然后这时候的方案就是
1. 直接传 sql ， 这个肯定不行，又慢又不安全
2. orm 写接口，加快了查询速度，但还是要写接口，不符合需求
3. graphql ，还是要写 schema...
4. apijson 只有 java ，我 TM...
5. nextjs ，另一种思路可以但是副作用更大
然后说一下 graphql ，他的场景主要是解决前端层的需求，更具体的是 BFF 层的需求，比如接口裁剪、组合。不是解决后端层的需求。后端其实并没有任何收益，说代码少写实际上并没有，因为你用普通的 orm 也能搞。
当然，有很多工具可以实现自定义生成 schema ，但还是不够快，而且费了太多功夫的。像这种情况下，我们肯定是不推荐硬写。就能实现但不是它该做的
那么剩下就是 apijson ，首先我一看到那个 github 项目页真的。真的是很糟糕
我感觉就是个 80 后程序员硬写出来的东西，而且毫无审美
更加意外的是居然还有那么多产品在用？ 当然这也说明国内真的很多公司水得一比
因为如果你真的有技术人员，或者真的有选型的能力，那绝对不可能选择 apijson ，怎么敢用在生产环境上？？？？
这就和前端的 uniapp 一样
虽然火，但是他真的又菜又没有创新。受众人群就是非程序员或者水平菜得不行的程序员
当然还有一批 80 后的程序员，就真的和社会脱节了，这个东西才是他们能认知的东西
然后目前来说，像我这个场景下，graphql 还是无奈的优选
最简单的方法就是 graphql + 自动生成 schema 然后放在云函数就可以跑了
再麻烦一点就是 graphql + orm + 云函数，然后如果表结构更新，记得更新云函数就行