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

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

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

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

@daryl 是的,没有银弹,现在只是一个对数据库操作的 dsl,专注的是提升效率和减低门槛,并不能解决全部问题

@nimrc 目前是通过路由直接控制权限,前端不能直接执行语句

@janxin 目前这个是一个用 orql dsl 来查询的框架,还没有支持到抛开全部后端,现在项目也是通过后端编写函数来处理这样来运行,有计划在这个基础上开发一个 baas,然后复杂的业务通过函数来处理

@janxin 分布式这块的愿景是做到透明化

@xuanbg 就像写代码写一个函数不用库使用复制的方式,一旦调整或者优化就会带来很大的麻烦

@janxin 目前的计划是提供分库分表的简单支持,分布式事务得依赖第三方中间件或者使用 newsql 做后端数据库

@lynskylate @ipwx 目前来说我们自己应用这些是在服务器直接写的,只是说前端可以参与,他们并没有在前端的 js 里直接调用,暴露成 api 给前端,分库分表这方面有开始在着手了,会提供一个规则,然后在这里对生成的 sql 进行自动分库分表

@otakustay 有一些调皮的前端想自己折腾的时候,这个会帮到,哈哈

@k9990009 也支持原生 sql 的查询,有类似 mybatis 这种的映射机制

@xuanbg 这个就涉及到静态抽象与动态抽象的问题,基本上复制的形式为导致维护困难,当然一次交付后续就不需要继续例会的情况下复制也是一种很好的选择

@hellowes 这个只是一个用更简单的方法来操作数据库的框架,它并不包含其他的功能,有考虑在该基础上封装一个 baas,这个 baas 会比较适合数据类型的后端,对于其他功能还是需要靠写原生的代码函数来支持

@hxt 是的,最开始的时候一度考虑使用 mongodb 作为后端数据库,后来因为事务和关联查询原因最后放弃了

@maemual 原则上全部的业务都是还需要开发,只是提升开发效率和减低开发门槛

@masker 设计风向都两年一大变了,前端业务比后端迭代快太多,ps 我是一个后端而已

@hellowes @askfilm 这只是一个数据库查询的 dsl,其他东西还是需要编码去实现