我的梦想是后端都不用写 curd,正在开发能大幅度减低 curd 甚至让前端来写 curd 的框架,希望大家多多关注与支持
qiuxiaojie · 2019-03-03 11:19:37 +08:00 · 10041 次点击这是一个创建于 2079 天前的主题，其中的信息可能已经有所发展或是发生改变。
经历了从模板渲染到前后端分离的时代,一直在苦苦思考,怎么样才能少干点活(大笑).在某天与前端对接接口时,突然顿悟,既然数据都是从 json 回去的,为什么不能直接使用类似 json 这样的语法来查询呢.在大胆的设想下,设计并实现了一套查询语法,给它起名为 orql(Object Relational Query Language 关系对象查询语言缩写).
就以 V2EX 举例说明一下它的用法
查询首页帖子列表,包括帖子标题 发布时间 回复数量 发帖人名称和头像以及节点名称:query post: [id, title, createAt, commentNum, user: {id, name, avatar}, node: {id, name}].
查看某帖子,包括帖子标题 内容 回复和回复人信息:query post(id = $id): [*, comments: [id, content, createAt, user: {id, name, avatar}], user: {id, name, avatar}]
发布一个帖子:add post: {title, content, user}
当然还支持其他的操作 update delete count 等,在模型方面支持 1:1 1:N N:M N:M 关联,更多的用法也可以通过在 github 中查看 https://github.com/orql/orql-mapper .如有兴趣者可以私聊,加微信大家交流,希望大家可以点一个 star 支持.
我的梦想是做一个可以让编程也自动化的程序员,擅长代码抽象和生成,希望有共同兴趣的人大家能一起交流.
第 1 条附言 · 2019-03-03 19:54:09 +08:00
关于前端使用问题
orql 的设计目的是为了提供一种能简化后端 curd 开发的 dsl，在前端直接使用虽然可以，但是会带来权限管理事务控制多端修改无法同步和内部逻辑暴露等问题，在早期就已经放弃在前端执行的可能，当然前端只要知道模型结构是可以自行编写部分 api，无需对 sql 熟悉。
框架集成进系统与其他 orm 框架是类似的，也支持原生 sql 的 mapping，对复杂的查询使用原生的 sql，但是这部分在大部分系统中比例很低，甚至没有。
现在也在考虑在这个基础上进行 baas 的封装，普通 api 直接通过 orql，复杂 api 通过编写函数方式进行支持。
orql 的设计目的是为了提供一种能简化后端 curd 开发的 dsl，在前端直接使用虽然可以，但是会带来权限管理事务控制多端修改无法同步和内部逻辑暴露等问题，在早期就已经放弃在前端执行的可能，当然前端只要知道模型结构是可以自行编写部分 api，无需对 sql 熟悉。
框架集成进系统与其他 orm 框架是类似的，也支持原生 sql 的 mapping，对复杂的查询使用原生的 sql，但是这部分在大部分系统中比例很低，甚至没有。
现在也在考虑在这个基础上进行 baas 的封装，普通 api 直接通过 orql，复杂 api 通过编写函数方式进行支持。
 |
101
qiuxiaojie OP |
 |
102
suikatw 2019-03-04 11:19:53 +08:00
这个想法其实是顺应了时代潮流的，并且已经有很多人在做了，一旦做成，则是在开发方式上的降维打击，值得深入思考。建议作者也可以看看 serverless
软件工程的目的之一就是尽可能的消灭脑力劳动，从脑力密集型变成劳动密集型 而绝大多数的业务开发背后主要有区别的工作就是模型设计、从一个主体转成另一个主体以及业务逻辑，那从这个角度来看，像运维、数据库 /缓存操作、负载均衡、扩容都能够抽离干净让业务无感知。做到这一步之后，具体的开发工作自然可以让不具有服务端知识的前端来完成，甚至让产品来完成，大大降低开发成本。 |
 |
103
zhang77555 2019-03-04 11:22:27 +08:00
后端的工作不是只有 CRUD，而且只要数据库设计的够好，CRUD 基本都不占什么工作量，把这部分由前端解决反而会产生更多问题，当然项目规模小的时候根本不需要分什么前后端，这样想怎么玩都行。
|
|
104
qiuxiaojie OP @suikatw 是的,谢谢你的理解,后端云化和轻量化是一种趋势,因为性能的优化和分布式拓展等等这些是与具体业务无关的,是可以透明化的,这些部分会慢慢被云端接替
|
 |
105
KuroNekoFan 2019-03-04 11:38:27 +08:00
graphql 也是要后端做大量的工作才能实现的吧？
|
 |
106
passerbytiny 2019-03-04 11:51:07 +08:00
@qiuxiaojie #81 没说让你生成全套界面，我说的是为 CRUD 生成全套功能——包括界面——的东西，早就有了。你最后的一句话是大误，只有 CRUD 不能叫 ORM，ORM 的全程是对象关系映射——程序中的对象与关系数据库的映射。
|
|
107
qiuxiaojie OP @passerbytiny ??orql 的工作原理是将描述的结构生成 sql 去执行查询,然后再将查询结果映射回描述的结构上,所以才称为 orql,至于属不属于 orm,这就得看严格的定义了
|
 |
108
TommyLemon 2019-03-04 12:32:59 +08:00
楼主的创造和开源精神值得鼓励。
首先一定要相对现有的开源项目有自己独特的优势，然后在平衡功能、安全、性能 时候也要深思熟虑。 可以看下这个 码云最有价值开源项目，4.9 K Star，已有多家企业公开使用 https://github.com/TommyLemon/APIJSON |
 |
109
jsun 2019-03-04 13:03:12 +08:00
合久必分，分久必合。生命在于折腾！
|
|
110
qiuxiaojie OP @TommyLemon 是的,谢谢,相比较我们优势在于语法简洁,采用 node.js 平台,非 curd 功能拓展容易,建议可以考虑把 orql 也作为 api 配置的一种方式,使用 dsl 配置比 json 配置无论从简易性还是开发效率和一目了然都更有优势.
|
 |
111
checkzhzzzzz 2019-03-04 13:56:35 +08:00
这个背景看到难受
|
|
112
TommyLemon 2019-03-04 14:52:33 +08:00
@qiuxiaojie APIJSON 不需要后端写代码就能实现 CRUD 哦
https://www.oschina.net/news/101787/apijson-3-1-0-released#comments |
 |
113
namebyrant 2019-03-04 14:57:24 +08:00
crud 很多时候里面都会有别的操作 同步 多线程 事务。你以为每次都是单纯的增删改查？
|
|
114
qiuxiaojie OP @TommyLemon 很容易抽象泄露
|
 |
115
guanhui07 2019-03-04 16:32:17 +08:00
很抽象
|
|
116
TommyLemon 2019-03-04 17:02:11 +08:00
@qiuxiaojie 具体说下？
|
|
117
qiuxiaojie OP @TommyLemon 可以把微信发我邮箱 qiushijie#outlook.com 大家微信讨论讨论
|
 |
118
sampeng 2019-03-04 22:54:49 +08:00 via iPhone
咋一眼看…这和 mongdb 的请求没什么区别吧…
|
|
119
TommyLemon 2019-03-04 23:02:00 +08:00
@qiuxiaojie
APIJSON 对安全做了大量优化，自动校验权限、自动校验数据和结构、自动防 SQL 注入 等 https://github.com/TommyLemon/APIJSON/issues/12 |
|
120
qiuxiaojie OP @sampeng 有参考了 mongodb，但是它不支持多张表关联，而且写比较表达式也麻烦
|
 |
121
1515319667 2019-03-05 09:25:26 +08:00
CURD 往往是和后续的优化以及项目结构绑定在一起的，让前端来写，后果不堪设想
|
Select Language