我考虑重写一套通用的 [增删改查的数据接口] ,这样就可以不用费劲再开发这样简单的 CRUD 接口来,不知道大家能不能谈谈各家的思路,借鉴一下
1
Mogugugugu 2019-09-18 10:21:40 +08:00 3
graphql 了解一下?
|
2
gz911122 2019-09-18 10:25:10 +08:00
graphql 吧
|
3
daijinming OP @Mogugugugu
@gz911122 最近学习了下 graphql ,我还整理来网站 https://graphql.im ,不过这个需要在后台定义 Schema,还是要写逻辑填充数据,只是入口唯一了,接口调用规范了。不能实现通用的 CRUD,我正考虑使用这个 graphql 写套通用的 CRUD |
4
StarkWhite 2019-09-18 10:30:47 +08:00
facebook 的 graphql + 1
|
5
StarkWhite 2019-09-18 10:31:11 +08:00 19
顺便问下,那个人来推广 apijson 了吗?
|
6
StarkWhite 2019-09-18 10:33:49 +08:00
@daijinming 可以接 prisma,这样就省掉 CRUD 的代码了
|
7
daijinming OP @StarkWhite 我觉得 apijson 有很多借鉴的地方,非常通用,当时我考虑前台标准和 graphql 不兼容,所以不考虑全盘采用
|
8
wysnylc 2019-09-18 10:38:26 +08:00
允许我笑一会哈哈哈哈哈哈哈哈哈
|
9
fxyswh 2019-09-18 10:39:11 +08:00
不知道大家对通用的增删改查接口怎么理解。比如说是接口地址、请求操作、请求返回统一还是其它的情况?
|
10
Caballarii 2019-09-18 10:40:48 +08:00
把你所有表的增删改查全部放给前端就通用了
|
11
arischow 2019-09-18 10:40:48 +08:00
请定义通用
|
12
daijinming OP @fxyswh
@arischow 1、Insert 新增 2、Update 更新 3、Get 查询一条记录 4、Delete 删除一条记录 5、List 分页查询列表 6、List_Params 分页查询列表,可自定字段匹配 7、List_DateParams 分页查询列表,可自定字段匹配,可按照日期过滤 8、List_DateKeywordParams 分页查询列表,可自定字段匹配,可按照日期过滤,关键字查询 9、List_CODE 查询 CODE 表记录,返回数组 10、List_InParams 分页查询列表,可进行范围查询 11、UpdateDouble 更新两个表 这是我之前写的通用接口,就是 CRUD 相关的 |
13
daijinming OP 当然,参考 apijson 中,对操作的表的范围,操作的类型(比如允许查,不允许查询)可以进行一些限制
|
14
chinvo 2019-09-18 10:44:13 +08:00 via iPhone
你把这些开放给前端,安全性怎么办
|
15
daijinming OP @chinvo 开放的都是基础表单、采用 JWT 验证用户角色
|
16
agee 2019-09-18 10:51:34 +08:00
parse-server
https://github.com/parse-community/parse-server |
17
airfling 2019-09-18 10:52:07 +08:00 1
spring data jpa rest,只需要设计好模型和 hibernate 的映射就可以了。会自动映射一些简单的资源接口
|
18
daijinming OP |
20
agee 2019-09-18 10:58:48 +08:00
没用过不了解
|
21
chinvo 2019-09-18 11:00:02 +08:00 via iPhone
@daijinming #15 既然这样你也是要在后端验证单一条目 crud 权限的,如果只是感觉写 viewmodel 麻烦,可以和 ef 共用 model ( ef 的 model 可以直接拿给 mvc 当 vm 用)
或者看看 parse-server |
22
mcfog 2019-09-18 11:14:39 +08:00
馊主意
这和写一个巨大的 main()处理所有业务有什么区别呢,等客户端发版了不能改了,产品需求又改了,你这个接口就得 if 插入 A 表记录 {一坨业务} if 删除 B 表记录 {另一坨业务} 业务上是不同的对象操作就应该写不同的接口,如果你写一组朴素的 CURD 的接口还觉得费劲,那你要做的是做或者加强你的框架来减少这类接口的开发成本,而不是写一个通用的接口然后等着需求迭代把他变成怪物 |
23
StarkWhite 2019-09-18 11:15:15 +08:00
之前用有个人在 v 站推广自动生成 CRUD 的工具,和你这个思路一样吧?
https://www.v2ex.com/t/507187 |
24
daijinming OP @StarkWhite 不一样,我考虑的是不用后端针对每个表单做开发,提供一个可以访问表单的通用接口,无需为一些简单需求,比如查询、更新哪些字段开发代码。而不是自动生成代码
|
25
StarkWhite 2019-09-18 11:26:38 +08:00
@daijinming 像你这个 List_InParams 不也是自动生成的?还是手写的?
|
26
mrobot 2019-09-18 12:13:23 +08:00 via iPhone
你其实要的是动态表单功能
|
27
hellodigua 2019-09-18 12:22:16 +08:00
@daijinming 按你 24 楼的说法,你思路都有了,按照 RESTful 的规范开发一套接口,接口末尾用 key 做识别不同的表单,然后跟前端约定好分页、查询等的规范就好了,不明白你的疑惑是什么
|
28
StarkWhite 2019-09-18 12:26:55 +08:00
@hellodigua 这样做就是 mybatis-plus 那种了
|
29
tabris17 2019-09-18 12:31:08 +08:00 2
胆子放开点,步子迈大些
不如直接把 SQL 接口暴露给前端 /狗头 |
30
loading 2019-09-18 12:31:29 +08:00 via Android 1
只要一个接口:
post /api/crud 参数 sql 你让前端自己拼 sql 过来,你直接给数据库跑就行了,反正是普通表,哈哈 |
31
daijinming OP @StarkWhite 参数字段需要前端出入,前台手写,后台不开发任何代码了
|
32
daijinming OP |
33
daijinming OP @hellodigua 亲啊,疑惑在标准,前台采用 graphql 标准看看前台能否接受,后台采用声明 ORM,还是直接拼 SQL,那种更灵活。希望能集思广益,征求下前后台开发的意见
|
34
oott123 2019-09-18 12:41:39 +08:00 via Android
postgrest 不知道你听说过没有
确实有这样用的,不过后端逻辑一般就从后端移动到了数据库上 |
35
tinycold 2019-09-18 12:41:41 +08:00 via Android
项目中用了一段时间的 GraphQL,劝退,坑还是不少,一切都是美好的想象,我现在只想 RESTful。
这种需求不是该上 BFF 吗?用 Nestjs 搞个 BFF 服务,让说不定还没让前端自己去折腾 |
36
wangxiaoaer 2019-09-18 12:46:55 +08:00 via Android
Postgresful 好像是这个,基于 pg 的表自动生成 restful 接口。
但最大的问题还是关联了。 |
37
encro 2019-09-18 12:53:19 +08:00
firebase,aliyun,qcloud 等的云函数。
|
38
xuanbg 2019-09-18 12:55:33 +08:00
顺便问下,那个人来推广 apijson 了吗?
|
39
encro 2019-09-18 12:57:47 +08:00
django rest, yii gii+ rest, 野狗, leancloud,都有类似的吧
我的一篇 blog 不完全搜集了类似 firebase 的开源程序。 https://c4ys.com/archives/1850 |
40
encro 2019-09-18 12:59:16 +08:00
主要考虑的是权限问题(细化到数据,字段级别的权限控制)
|
41
nuance2ex 2019-09-18 13:06:04 +08:00 via iPhone
jsonapi 1.0
|
42
daijinming OP @tinycold 好像经历来好多,rest 美好
|
43
daijinming OP @tinycold BFF 之前还是没怎么听说过,使用过吗,怎么样?
|
44
daijinming OP @encro 重点不应改在这里
|
45
wisetc 2019-09-18 13:48:18 +08:00
finale + sequelize = `finale-rest`
|
46
guolaopi 2019-09-18 13:53:25 +08:00
原来公司有个大佬推广过 Odata
不知道符不符合要求,你可以看看。 .NET 的 |
47
daijinming OP @guolaopi 感谢老兄
|
48
SjwNo1 2019-09-18 14:24:41 +08:00
graphql 一般用来查吧...
|
49
StarkWhite 2019-09-18 14:42:33 +08:00
tk.mybatis,MyBatisCodeHelper
|
50
StarkWhite 2019-09-18 14:42:58 +08:00
@SjwNo1 query 用来查,mutation 用来 增删改
|
51
LokiSharp 2019-09-18 14:44:47 +08:00
PostgREST
|
52
StarkWhite 2019-09-18 15:00:41 +08:00
昨天看到有个支持在 URL 参数里写 key@=1&key==2&key<=3&page=1&pageSize=10 这种能自定义条件的开源项目
|
53
daijinming OP @StarkWhite 至于卸载 URL 里还是 form 里应该没啥太大区别吧,哪个项目,分享下吧
|
54
StarkWhite 2019-09-18 15:06:03 +08:00
C# 写的,Biarity/Sieve
GET /GetPosts ?sorts= LikeCount,CommentCount,-created // sort by likes, then comments, then descendingly by date created &filters= LikeCount>10, Title@=awesome title, // filter to posts with more than 10 likes, and a title that contains the phrase "awesome title" &page= 1 // get the first page... &pageSize= 10 // ...which contains 10 posts 这个就是你想要做的效果吧? https://github.com/Biarity/Sieve#send-a-request |
55
daijinming OP @StarkWhite 3Q,参考一下
|
56
StarkWhite 2019-09-18 16:00:37 +08:00
@StarkWhite 看了下文档和 issue,这个貌似也只支持单表
|
57
StarkWhite 2019-09-18 16:04:17 +08:00
@daijinming 不如 OData
GET http://host/service/Customers? $filter=Orders/any(o:o/TotalPrice gt 100) &$expand=Orders($compute=Price mult Qty as TotalPrice ;$select=Name,Price,Qty,TotalPrice) |
58
Varobjs 2019-09-18 16:07:07 +08:00 1
那个男人
|
59
soulzz 2019-09-18 16:07:30 +08:00
GraphQL 劝退+1
自由度太高导致一切都要自己配,然后很可能导致严重的性能问题 建议 restful 解决 |
60
StarkWhite 2019-09-18 16:11:29 +08:00
@soulzz 自由度不高的话怎么支持前端定制数据和结构呢?
性能问题看取舍,而且有 dataloader 可以解决 |
61
YUyu101 2019-09-18 16:20:22 +08:00
呵呵我也这么想过,前后端分离,写个屁的 api 烦都烦死了,干脆学 mongo 用 json 查询,后来想干脆上 graphql 吧,再后来恨不得传 sql 过去,到最后觉得 sql 出来还要前端处理数据,恨不得把 js 代码发到后端 eval 一下,后来我冷静下来想想,我的大脑是被前端腐蚀了,因为却靠近前端数据越不稳定,就越想把资源重心向前端倾斜,企图一劳永逸,然而是不可能的。
|
62
jhdxr 2019-09-18 16:23:06 +08:00
太复杂了,直接前端写 SQL 后端执行不就行了→_→
|
63
stevenkang 2019-09-18 16:28:00 +08:00
SQL 注入,满足你的需求。
|
65
areless 2019-09-18 16:58:35 +08:00
https://github.com/mevdschee/php-crud-api
然后用自己的加解密算法混淆下请求,扔给前端。后端就可以天天摸鱼了。 |
66
abcbuzhiming 2019-09-18 17:12:54 +08:00
@StarkWhite 性能问题来自于业务复杂度,怎么可能靠一个工具就彻底解决,你这工具不成银弹了,想想也明白不可能啊,只不过是你这工具没遇到真正麻烦的情况罢了
|
67
Rwing 2019-09-18 17:21:28 +08:00
@daijinming abp 了解一下
|
68
Rwing 2019-09-18 17:25:58 +08:00
我也想了解一下 graphql 在增删改的表现怎么样
|
69
daijinming OP @Rwing 朋友,graphql 只是规范,表现如何主要还是看后台开发人员水平。
|
70
newtype0092 2019-09-18 17:35:50 +08:00
千万不要,你写完后老板立马就会把你和所有后端的人开除,以后你们公司就不需要后端了~
|
71
StarkWhite 2019-09-18 18:01:37 +08:00
@daijinming 同意,后端完全可以灵活发挥,满足各种需求
|
72
tommyZZM 2019-09-18 18:05:25 +08:00
graphql
|
73
StarkWhite 2019-09-18 18:08:04 +08:00
@newtype0092 后端又不只是 CRUD,还可以做数据监控、统计分析、可视化等
|
74
StarkWhite 2019-09-18 18:14:24 +08:00
@StarkWhite 而且就算是只做 CRUD,也没有通用到全部需求都能覆盖的,那个吹上天的 apijson 也不能保证 100% 满足需求,复杂点的增删改也要自己写
|
75
StarkWhite 2019-09-18 18:15:27 +08:00
@StarkWhite 还不支持事务呢,也能就用来查询
|
76
omniversia 2019-09-18 18:21:33 +08:00
spring data jpa,crudRepository 搞起相当快,然后自己写个 CRUD 模板代码生成器应该可以的
|
77
StarkWhite 2019-09-18 18:24:21 +08:00
@omniversia 有推荐过类似生成代码的给楼主,看起来他不是要这种生成代码的项目,他要的是全自动的
|
78
omniversia 2019-09-18 18:26:08 +08:00
@StarkWhite 全自动可以的,自己写吧,难说项目就出名了呢,就跟当年 hibernate 一样,啊哈哈
|
79
StarkWhite 2019-09-18 18:30:23 +08:00
@omniversia 哈哈,难。而且 hibernate 也不是自动的。
就算真的实现了全自动,那安全、事务、权限等一堆问题也够呛 |
80
orzorzorzorz 2019-09-18 20:15:52 +08:00
最为简单省事的就是让前端写 sql,不会就只能 graphql 了。实际上还是感觉前者自由度更高,后者我到现在都不知道该怎么行转列...
|
81
orzorzorzorz 2019-09-18 20:17:13 +08:00
上面说的权限啊安全之类的,这些都要前端管了那还要你们干啥...
|
82
activemq 2019-09-18 21:41:30 +08:00
做好这些工作之后,老板就可以把后端炒掉了
|
83
StarkWhite 2019-09-18 21:45:32 +08:00
@orzorzorzorz 不,我是说他做全自动的项目,得保证接口安全性才能上生产环境,不然最多做原型或者只在内网用
|
84
ikaros 2019-09-19 00:23:41 +08:00
我不需要后端,我觉得前端的需求要大一些,因为后端你的增删改操作一般都会涉及自己的业务逻辑,所以后端肯定不好做通用,但是前端可以做通用,所以有没有这样的前端框架?
|
85
yegle 2019-09-19 00:42:34 +08:00
我之前做过把 query string parse 成 dict 然后直接扔给 Django 的 `QuerySet.filter()` 方法。
|
86
webshe11 2019-09-19 01:03:20 +08:00
直接从前端往后端传 SQL 就行了,我们外包公司都是这么写的,有人说 SQL 注入我们一般加一个密码一起 pots 过去就行了
|
88
NewExist 2019-09-19 08:39:15 +08:00
项目启动的时候将 sql 缓存到 redis 里面,前台直接传一个 sql 对应的一个 id 就行了
|
89
encro 2019-09-19 09:13:14 +08:00
今天早上又看到一个:
Introducing Appwrite: An Open Source Backend Server for Mobile & Web Developers https://medium.com/@eldadfux/introducing-appwrite-an-open-source-backend-server-for-mobile-web-developers-4be70731575d |
90
StarkWhite 2019-09-19 09:53:47 +08:00
@webshe11 这个密码是全局的吧?一旦破解密码,那就所有接口全都破解了
|
91
StarkWhite 2019-09-19 10:02:30 +08:00
@webshe11 直传 SQL,那业务代码都用存储过程写?还是都前端写?登录状态、权限验证、业务逻辑...
|
92
GoLand 2019-09-19 10:47:05 +08:00
APIJson 可能会迟到,但永远不会缺席。
|
93
encro 2019-09-19 10:47:41 +08:00
|
94
StarkWhite 2019-09-19 11:58:22 +08:00
@GoLand 简称 A 迟但到?/滑稽
|
95
YUyu101 2019-09-19 12:16:47 +08:00
@StarkWhite 直传 sql 意味着要解析 sql,等于又撸了一遍数据库权限系统
|
96
StarkWhite 2019-09-19 12:24:53 +08:00
@YUyu101 是的,麻烦得很,而且也很难说服前端去学
|
97
daijinming OP @encro 看着还不错,能给分析下吗,支持什么数据库
|
98
xiaotianhu 2019-09-19 14:21:18 +08:00 via iPhone
包装一下 前端直接写 sql 美滋滋
|
99
encro 2019-09-19 15:20:19 +08:00
|
100
Eugene1024 2019-09-19 15:34:06 +08:00
直接传 sql,但是权限和安全需要好好考虑下
|