这是一个创建于 1891 天前的主题，其中的信息可能已经有所发展或是发生改变。
我考虑重写一套通用的 [增删改查的数据接口] ,这样就可以不用费劲再开发这样简单的 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 1
@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,但是权限和安全需要好好考虑下
|
Select Language