为前端准备通用的增删改查的数据接口，大家有没有好的思路

[daijinming]

我考虑重写一套通用的 [增删改查的数据接口] ,这样就可以不用费劲再开发这样简单的 CRUD 接口来，不知道大家能不能谈谈各家的思路，借鉴一下

[Mogugugugu]

graphql 了解一下？

[gz911122]

graphql 吧

[daijinming]

@Mogugugugu
@gz911122 最近学习了下 graphql ,我还整理来网站 https://graphql.im ，不过这个需要在后台定义 Schema,还是要写逻辑填充数据，只是入口唯一了，接口调用规范了。不能实现通用的 CRUD，我正考虑使用这个 graphql 写套通用的 CRUD

[StarkWhite]

facebook 的 graphql + 1

[StarkWhite]

顺便问下，那个人来推广 apijson 了吗？

[StarkWhite]

@daijinming 可以接 prisma，这样就省掉 CRUD 的代码了

[daijinming]

@StarkWhite 我觉得 apijson 有很多借鉴的地方，非常通用，当时我考虑前台标准和 graphql 不兼容，所以不考虑全盘采用

[wysnylc]

允许我笑一会哈哈哈哈哈哈哈哈哈

[fxyswh]

不知道大家对通用的增删改查接口怎么理解。比如说是接口地址、请求操作、请求返回统一还是其它的情况？

[Caballarii]

把你所有表的增删改查全部放给前端就通用了

[arischow]

请定义通用

[daijinming]

@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 相关的

[daijinming]

当然，参考 apijson 中，对操作的表的范围，操作的类型（比如允许查，不允许查询）可以进行一些限制

[chinvo]

你把这些开放给前端，安全性怎么办

[daijinming]

@chinvo 开放的都是基础表单、采用 JWT 验证用户角色

[agee]

parse-server
https://github.com/parse-community/parse-server

[airfling]

spring data jpa rest，只需要设计好模型和 hibernate 的映射就可以了。会自动映射一些简单的资源接口

[daijinming]

@agee
@airfling 有没有 dotnet 或 dotnet core 的资源

[airfling]

没用过.net 不了解

[agee]

没用过不了解

[chinvo]

@daijinming #15 既然这样你也是要在后端验证单一条目 crud 权限的，如果只是感觉写 viewmodel 麻烦，可以和 ef 共用 model （ ef 的 model 可以直接拿给 mvc 当 vm 用）

或者看看 parse-server

[mcfog]

馊主意

这和写一个巨大的 main()处理所有业务有什么区别呢，等客户端发版了不能改了，产品需求又改了，你这个接口就得 if 插入 A 表记录 {一坨业务} if 删除 B 表记录 {另一坨业务}

业务上是不同的对象操作就应该写不同的接口，如果你写一组朴素的 CURD 的接口还觉得费劲，那你要做的是做或者加强你的框架来减少这类接口的开发成本，而不是写一个通用的接口然后等着需求迭代把他变成怪物

[StarkWhite]

之前用有个人在 v 站推广自动生成 CRUD 的工具，和你这个思路一样吧？
https://www.v2ex.com/t/507187

[daijinming]

@StarkWhite 不一样，我考虑的是不用后端针对每个表单做开发，提供一个可以访问表单的通用接口，无需为一些简单需求，比如查询、更新哪些字段开发代码。而不是自动生成代码

[StarkWhite]

@daijinming 像你这个 List_InParams 不也是自动生成的？还是手写的？

[mrobot]

你其实要的是动态表单功能

[hellodigua]

@daijinming 按你 24 楼的说法，你思路都有了，按照 RESTful 的规范开发一套接口，接口末尾用 key 做识别不同的表单，然后跟前端约定好分页、查询等的规范就好了，不明白你的疑惑是什么

[StarkWhite]

@hellodigua 这样做就是 mybatis-plus 那种了

[tabris17]

胆子放开点，步子迈大些

不如直接把 SQL 接口暴露给前端 /狗头

[loading]

只要一个接口:
post
/api/crud
参数 sql

你让前端自己拼 sql 过来，你直接给数据库跑就行了，反正是普通表，哈哈

[daijinming]

@StarkWhite 参数字段需要前端出入，前台手写，后台不开发任何代码了

[daijinming]

@tabris17
@loading 这个我可不敢，前端也不会 SQL 语句

[daijinming]

@hellodigua 亲啊，疑惑在标准，前台采用 graphql 标准看看前台能否接受，后台采用声明 ORM，还是直接拼 SQL，那种更灵活。希望能集思广益，征求下前后台开发的意见

[oott123]

postgrest 不知道你听说过没有
确实有这样用的，不过后端逻辑一般就从后端移动到了数据库上

[tinycold]

项目中用了一段时间的 GraphQL，劝退，坑还是不少，一切都是美好的想象，我现在只想 RESTful。

这种需求不是该上 BFF 吗？用 Nestjs 搞个 BFF 服务，让说不定还没让前端自己去折腾

[wangxiaoaer]

Postgresful 好像是这个，基于 pg 的表自动生成 restful 接口。

但最大的问题还是关联了。

[encro]

firebase，aliyun,qcloud 等的云函数。

[xuanbg]

顺便问下，那个人来推广 apijson 了吗？

[encro]

django rest, yii gii+ rest, 野狗, leancloud，都有类似的吧

我的一篇 blog 不完全搜集了类似 firebase 的开源程序。

https://c4ys.com/archives/1850

[encro]

主要考虑的是权限问题（细化到数据，字段级别的权限控制）

[nuance2ex]

jsonapi 1.0

[daijinming]

@tinycold 好像经历来好多，rest 美好

[daijinming]

@tinycold BFF 之前还是没怎么听说过，使用过吗，怎么样？

[daijinming]

@encro 重点不应改在这里

[wisetc]

finale + sequelize = `finale-rest`

[guolaopi]

原来公司有个大佬推广过 Odata
不知道符不符合要求，你可以看看。
.NET 的

[daijinming]

@guolaopi 感谢老兄

[SjwNo1]

graphql 一般用来查吧...

[StarkWhite]

tk.mybatis，MyBatisCodeHelper

[StarkWhite]

@SjwNo1 query 用来查，mutation 用来 增删改

[LokiSharp]

PostgREST

[StarkWhite]

昨天看到有个支持在 URL 参数里写 key@=1&key==2&key<=3&page=1&pageSize=10 这种能自定义条件的开源项目

[daijinming]

@StarkWhite 至于卸载 URL 里还是 form 里应该没啥太大区别吧，哪个项目，分享下吧

[StarkWhite]

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

[daijinming]

@StarkWhite 3Q,参考一下

[StarkWhite]

@StarkWhite 看了下文档和 issue，这个貌似也只支持单表

[StarkWhite]

@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)

[Varobjs]

那个男人

[soulzz]

GraphQL 劝退+1
自由度太高导致一切都要自己配，然后很可能导致严重的性能问题
建议 restful 解决

[StarkWhite]

@soulzz 自由度不高的话怎么支持前端定制数据和结构呢？
性能问题看取舍，而且有 dataloader 可以解决

[YUyu101]

呵呵我也这么想过，前后端分离，写个屁的 api 烦都烦死了，干脆学 mongo 用 json 查询，后来想干脆上 graphql 吧，再后来恨不得传 sql 过去，到最后觉得 sql 出来还要前端处理数据，恨不得把 js 代码发到后端 eval 一下，后来我冷静下来想想，我的大脑是被前端腐蚀了，因为却靠近前端数据越不稳定，就越想把资源重心向前端倾斜，企图一劳永逸，然而是不可能的。

[jhdxr]

太复杂了，直接前端写 SQL 后端执行不就行了→_→

[stevenkang]

SQL 注入，满足你的需求。

[repus911]

graphql
数据库通用的话试试 prisma
postgres 数据库有一个 hasura.io

[areless]

https://github.com/mevdschee/php-crud-api
然后用自己的加解密算法混淆下请求，扔给前端。后端就可以天天摸鱼了。

[abcbuzhiming]

@StarkWhite 性能问题来自于业务复杂度，怎么可能靠一个工具就彻底解决，你这工具不成银弹了，想想也明白不可能啊，只不过是你这工具没遇到真正麻烦的情况罢了

[Rwing]

@daijinming abp 了解一下

[Rwing]

我也想了解一下 graphql 在增删改的表现怎么样

[daijinming]

@Rwing 朋友，graphql 只是规范，表现如何主要还是看后台开发人员水平。

[newtype0092]

千万不要，你写完后老板立马就会把你和所有后端的人开除，以后你们公司就不需要后端了～

[StarkWhite]

@daijinming 同意，后端完全可以灵活发挥，满足各种需求

[tommyZZM]

graphql

[StarkWhite]

@newtype0092 后端又不只是 CRUD，还可以做数据监控、统计分析、可视化等

[StarkWhite]

@StarkWhite 而且就算是只做 CRUD，也没有通用到全部需求都能覆盖的，那个吹上天的 apijson 也不能保证 100% 满足需求，复杂点的增删改也要自己写

[StarkWhite]

@StarkWhite 还不支持事务呢，也能就用来查询

[omniversia]

spring data jpa,crudRepository 搞起相当快，然后自己写个 CRUD 模板代码生成器应该可以的

[StarkWhite]

@omniversia 有推荐过类似生成代码的给楼主，看起来他不是要这种生成代码的项目，他要的是全自动的

[omniversia]

@StarkWhite 全自动可以的，自己写吧，难说项目就出名了呢，就跟当年 hibernate 一样，啊哈哈

[StarkWhite]

@omniversia 哈哈，难。而且 hibernate 也不是自动的。
就算真的实现了全自动，那安全、事务、权限等一堆问题也够呛

[orzorzorzorz]

最为简单省事的就是让前端写 sql，不会就只能 graphql 了。实际上还是感觉前者自由度更高，后者我到现在都不知道该怎么行转列...

[orzorzorzorz]

上面说的权限啊安全之类的，这些都要前端管了那还要你们干啥...

[activemq]

做好这些工作之后，老板就可以把后端炒掉了

[StarkWhite]

@orzorzorzorz 不，我是说他做全自动的项目，得保证接口安全性才能上生产环境，不然最多做原型或者只在内网用

[ikaros]

我不需要后端，我觉得前端的需求要大一些,因为后端你的增删改操作一般都会涉及自己的业务逻辑,所以后端肯定不好做通用,但是前端可以做通用,所以有没有这样的前端框架？

[yegle]

我之前做过把 query string parse 成 dict 然后直接扔给 Django 的 `QuerySet.filter()` 方法。

[webshe11]

直接从前端往后端传 SQL 就行了，我们外包公司都是这么写的，有人说 SQL 注入我们一般加一个密码一起 pots 过去就行了

[gIrl1990]

@webshe11 233 传 SQL。666 没毛病。

[NewExist]

项目启动的时候将 sql 缓存到 redis 里面，前台直接传一个 sql 对应的一个 id 就行了

[encro]

今天早上又看到一个：
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

[StarkWhite]

@webshe11 这个密码是全局的吧？一旦破解密码，那就所有接口全都破解了

[StarkWhite]

@webshe11 直传 SQL，那业务代码都用存储过程写？还是都前端写？登录状态、权限验证、业务逻辑...

[GoLand]

APIJson 可能会迟到，但永远不会缺席。

[encro]

基于 google translater 修改了下 ：

[Appwrite 介绍：开源的移动和 WEB 后端服务]( https://c4ys.com/archives/1959)

[StarkWhite]

@GoLand 简称 A 迟但到？/滑稽

[YUyu101]

@StarkWhite 直传 sql 意味着要解析 sql，等于又撸了一遍数据库权限系统

[StarkWhite]

@YUyu101 是的，麻烦得很，而且也很难说服前端去学

[daijinming]

@encro 看着还不错，能给分析下吗，支持什么数据库

[xiaotianhu]

包装一下 前端直接写 sql 美滋滋

[encro]

@daijinming

猜测是 mongodb

https://appwrite.io/docs/database

[Eugene1024]

直接传 sql,但是权限和安全需要好好考虑下