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

graphql 了解一下？

graphql 吧

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

facebook 的 graphql + 1

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

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

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

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

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

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

请定义通用

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

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

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

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

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

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

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

没用过.net 不了解

没用过不了解

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

或者看看 parse-server

馊主意

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

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

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

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

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

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

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

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

胆子放开点，步子迈大些

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

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

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

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

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

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

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

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

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

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

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

firebase，aliyun,qcloud 等的云函数。

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

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

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

https://c4ys.com/archives/1850

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

jsonapi 1.0

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

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

@encro 重点不应改在这里

finale + sequelize = `finale-rest`

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

@guolaopi 感谢老兄

graphql 一般用来查吧...

tk.mybatis，MyBatisCodeHelper

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

PostgREST

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

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

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

@StarkWhite 3Q,参考一下

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

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

那个男人

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

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

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

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

SQL 注入，满足你的需求。

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

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

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

@daijinming abp 了解一下

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

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

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

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

graphql

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@webshe11 233 传 SQL。666 没毛病。

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

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

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

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

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

基于 google translater 修改了下 ：

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

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

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

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

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

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

@daijinming

猜测是 mongodb

https://appwrite.io/docs/database

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