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

[daijinming]

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

[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]

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