我的梦想是后端都不用写 curd,正在开发能大幅度减低 curd 甚至让前端来写 curd 的框架,希望大家多多关注与支持

[qiuxiaojie]

经历了从模板渲染到前后端分离的时代,一直在苦苦思考,怎么样才能少干点活(大笑).在某天与前端对接接口时,突然顿悟,既然数据都是从 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 支持.

我的梦想是做一个可以让编程也自动化的程序员,擅长代码抽象和生成,希望有共同兴趣的人大家能一起交流.

[fyxtc]

只有我觉得 nodejs 节点的配色风格还挺好看的吗。。。

[Vegetable]

复杂度守恒

[bnlt]

可以看一下 postgraphile，算是比较成熟，权限问题也基本解决了，但数据库必须是 postgresql。
一般项目已经可以不要后端，但是改要一个 DBA [手动狗头]
https://www.graphile.org/postgraphile/

[qiuxiaojie]

@Vegetable 还有的程序员认为只有打孔才是编程

[akira]

这不就是 rest 了么。。

[qiuxiaojie]

@bnlt 有参考了 graphql 的语法,然后对它做了简化

[jzmws]

我的想法还是前端只展示,后端提供数据 , crud 可以在前端写,要是核心的部分是否容易被攻击 ?

[version]

事务,并发,数据权限,限制是个问题..
nodejs 写 20 个 crud.不是很容易么 sequelize 那么强大.mongodb 也有 orm
前端传对象直接插入 json 就好.业务限制就覆盖判断 json 字段.

增加表字段就改 Schema nodejs 重启完事.

前后分离的时候.不能因为为了减少服务端自己的工作量而增加别人的逻辑负载
等你有一天写全栈就知道了..十几张表往上.或者 mongo..为了应对后期需求修改.
crud:前端需要 80%, 服务端 20% 的时间分配.

[qiuxiaojie]

@jzmws 现在都是在后端编辑 orql 暴露成 api 给前端调用，然后前端可以根据他们需要自己去编写，在前端直接写会面临很多问题

[xuanbg]

@qiuxiaojie 模板不是你所想的这种场景使用的。。。公共的代码，自然是抽到一个公共的包里面提供 api 来调用的。模板解决的是那种结构相同、事物不同的问题。譬如你要管理客户数据、商品数据等等，都是简单的增删改查。这个时候，要做一个通用的增删改查组件是费力不讨好的，但模板就能派上用场了。复制一个服务实现类，基本上改改里面的实体类，再针对管理的数据特征，做一些特殊化的处理，就出来一个全新的服务了。
为什么说做通用组件不讨好，因为很难将这些不同对象的特性从逻辑上完全剥离，从而将共性抽象成一个公共组件。硬要割裂这些特性和共性之间的逻辑关系，只会把简单的事情搞复杂，这个是软件工程中应该首先避免的事情。

[qiuxiaojie]

@version 我就是一个全栈，前端 app 都有开发，所以也很了解前后端数据对接是一件不容易的事情。这个框架的设计也站在前端这些需要使用数据的角度去考虑，前端根据 orql 就可以很容易知道返回的数据的结构，能节省很多的双方沟通时间。

[richard1122]

话说楼主有没有用过 leancloud 或者 firebase 的数据库，他们一大特点就是靠权限配置、直接让前端访问数据库，可以做到理论上无服务端开发。
https://leancloud.cn/docs/storage_overview.html
https://firebase.google.com/docs/firestore/

想听听楼主的看法？

[qiuxiaojie]

@richard1122 有试用过,权限这块怎么说呢,它们都是在每一个表甚至每一条记录里面去控制,但是实际使用的确会造成很多困扰,一不小心容易导致出现问题,而且 api key 这些直接暴露了,整个应用的数据都不安全.

[version]

@qiuxiaojie 现在前端用 vue 或者 react 基本也是组件开发.其实组件抽象起来就是表的结构.一般给全部表字段或者数据库他们访问.或者服务端数据库定义 Schema 代码..基本对接 api 是能看懂的了.根本不需要那么复杂的了..你写一套框架.很多人不一定接受的呢.框架还要看 api....前端传的 key 和服务端和数据库不一样的时候.排查沟通也累..

还有现在基本都是内部 rpc 微服务开发(特别是 nodejs)
.给前端 sql 操作不符合,复杂业务需求解藕.分布式部署和某个小业务迁移重构

[eurokingbai2]

GraphQL 这种技术对 REST 架构约束造成了极大的破坏，长久的话可能不利于 Web 发展。我可以按照 Roy Fielding 博士论文的理论进行解释：
1 ）破坏了缓存约束，最直接的后果是传统的分层代理、缓存中间件不能有效命中前端的查询结果，因此极其不利于系统的可扩展性。
2 ）这个类似于远端执行（ REV ）约束了，而 Roy Fielding 早有断言该约束不可取，主要是破坏了可见性。一方面因为前端传来的代码愈发不可控不安全，后端审查起来存在较大苦难；另一方面，后端线程和进程间的代码可见性也被破坏，分布式事务等请求无法保证。

这类技术是个不错的 Trick，但不适合大范围使用。

[qiuxiaojie]

@version @eurokingbai2 这个是在后端用的查询 dsl,并不像 graphql 那样做的是前端请求数据格式的描述,是发送给数据库的请求数据格式描述

[eurokingbai2]

@qiuxiaojie 一样的。莫非你的意思是完全不要 Web 了？直接让数据库做后端暴露接口？

[skadi]

GraphQL

[qiuxiaojie]

@eurokingbai2 肯定不能这样,是这个 dsl 起到 sql 的作用

[WispZhan]

OData