Open TommyLemon opened 6 years ago
建议: 如果作为前端或APP开发人员,无疑是要增加他们进行拼接条件的工作量 可以开发一个辅助工具,自动生成url工具
@liliang8858 太赞了,非常感谢。加个QQ详聊吧
建议: hot 数据预加载到 redis 解除DB层压力
@liliang8858 APIJSON建议请求JSON由后端给出哦,在APIJSONAuto上测试通过后 点右侧倒数第2个按钮 上传(共享),前端就能看到了 演示 http://apijson.org/auto 源码 https://github.com/TommyLemon/APIJSONAuto 如果是前端让用APIJSON的话,让TA自己TA写他也应该会愿意的, 最多是你把表外键关系给TA(最好是表字段注释里说明,例如 userId 注释:等于User表的id )就行了。
Redis缓存这个建议很好,不过由于业务的不确定性,我打算只在库里面缓存一些配置,其它的业务表数据由开发者自行决定更好
APIJSON JavaScript什么时候出支持react native的版本?谢谢,还有PHP的也需要。
@angelfreedomv 感谢建议。 APIJSON其实是不需要前端做特别的支持的, 封装请求JSON和解析结果JSON完全可以用以前的一套(原生、第三方库等都行)。 不过React Native的Demo倒是可以加上。
PHP我不会哦,希望有热心的开发者做出来, 目前APIJSON后端除了Java版 https://github.com/TommyLemon/APIJSON/tree/master/APIJSON-Java-Server
C#版也已经可以用了, https://github.com/liaozb/APIJSON.NET
Python版也完成了基础设施搭建(作者zeromake的回复) https://github.com/TommyLemon/APIJSON/issues/38
给热心的作者们点Star支持下吧^_^
@TommyLemon 谢谢作者,我的建议是建立一个qq群或者telegram群,接受反馈,不断完善项目。
@angelfreedomv 欢迎加群,一起交流探讨、学习进步 607020115
20200308 更新,已完成。 查询User数组和对应的User总数:
{
"[]": {
"query": 2,
"User": {}
},
"total@": "/[]/total",
"info@": "/[]/info"
}
返回的数据中,总数及分页详情结构为:
"total":139, //总数
"info":{ //分页详情
"total":139, //总数
"count":5, //每页数量
"page":0, //当前页码
"max":27, //最大页码
"more":true, //是否还有更多
"first":true, //是否为首页
"last": false //是否为尾页
}
具体见 功能符 > 数组关键词的 query,total 和 info https://github.com/APIJSON/APIJSON/blob/master/Document.md#3.2
建议完善分页信息。
目前 总页数、是否有下一页 等分页信息可通过 total,count,page 得出, 总页数 int totalPage = Math.ceil(total / count) 是否有下一页 boolean hasNextPage = total > count*page 是否为第一页 boolean isFirstPage = page <= 0 是否为最后一页 boolean isLastPage = total <= count*page
见 通用文档 的 数组关键词 ③ https://github.com/TommyLemon/APIJSON/blob/master/Document.md#3.2
但是后端只需要牺牲非常小(可以忽略不计)的性能,就可以计算好这些信息返回给前端,例如 查询User数组和对应的User总数: 原来是
"[]": {
"query": 2,
"User": {}
},
"total@": "/[]/total"
返回
"[]": [...],
"total": 100
变为
"[]":{
"query":2,
"User":{}
},
"pagination@":"/[]/pagination"
返回
"[]": [...],
"pagination": {
"total": 100,
"hasNextPage": true,
"isFirstPage": false,
"isLastPage": false
}
点赞(右上角+表情)数超过10个就开发。
还有什么需要的信息大家可以补充下。
@angelfreedomv APIJSON PHP 版已经有了🎉 创作不易,给热心作者点 ⭐Star 支持下吧^_^ https://github.com/orchie/apijson
老大 啥时候把APIJSON和ZBlibrary整合一下,原Android端的一直没跟上ZBlibrary的进度啊。APIJSON-Android这样的前后一体的实在是太实用了,上手就等于项目完成一半了。希望老大抽空更新一下呗!!!
全局关闭所有权限验证怎么设置 急需测试 未找到配置的地方 望指点
@wq201 最近更新了一小部分 https://github.com/TommyLemon/APIJSON/releases/tag/3.1.7
@Onesimu DemoParser 3个构造方法里面最后(super方法后)加
setNoVerifyRole(true);
顺便说下,这里只用来提交建议,提交问题请 New Issue https://github.com/TommyLemon/APIJSON/issues/new/choose
谢谢, 确实很强大. 其实配置的问题也算一个小小的建议, 对于数据库连接 开启验证 开启日志这些最基本的配置最好能够放在配置文件里, 就像spring boot那样. 这样更符合生产环境的使用方式. 另外, 不知道有没有关于在生产环境使用的例子或最佳实践. 现在做的一个项目用的spring data rest, 但是写灵活一些的查询比较繁琐, 所以考虑把APIJSON集成进来. 但是还有一些问题要考虑
@Onesimu 感谢建议。 1.可以通过自动化权限管理来控制,细分到 每种角色、每种操作、每张表、每条记录 https://github.com/TommyLemon/APIJSON/issues/12
2.自定义业务建议优先使用 远程函数 来实现,其次是 重写相关方法 https://github.com/TommyLemon/APIJSON/blob/master/Document.md#3.2
3.可以在 Log.java里的 DEBUG 统一配置是否开启输入 APIJSONORM 的日志 https://github.com/TommyLemon/APIJSON/blob/master/APIJSON-Java-Server/APIJSONORM/src/main/java/zuo/biao/apijson/Log.java
想請問一下,在 GraphQL 中,每個 Object(例如:User、Comment)都各自有一個來源的 Resolver。
這個 Resolver 裡面可以透過 TCP/gRPC/JSON-RPC 去和對應的資源微服務進行互動。
post {
comment {
}
}
像上述 GraphQL 範例:Post 可以在 Resolver 中呼叫 Post 微服務、Comment 則呼叫 Comment 微服務以請求資源,以此類推。
APIJSON 看起來像是沒有 Resolver(以我從網路上收集到的認知),那麼要如何在這部份切分相關資源以符合微服務的相關呼叫措施呢?
@YamiOdymel APIJSON 可以用 1.远程函数
{
"Moment": {
"id": 301,
"isPraised()": "isContain(praiseUserIdList,userId)" //远程函数
}
}
在后端实现远程函数,做你想要的呼叫 Post 微服务等。
2.重写 ObjectParser.onParse(String key, Object value) 判断 table 和 key,符合你需求 table+key 的就调用对应的服务
提醒一下,这是建议收集的地方,有问题单独发 issue 哦
建议支持websocket, 便于实现数据实时同步和双向消息通知. 数据结构最好和具体传输方式解耦. 这样即使要用在socket传输或者将来的HTTP2/3 等各种场合都能适应. 建议作者评估一下, 做成通用数据接口, 或者给出思路和demo, 让社区去贡献具体传输方式实现.
@Onesimu 感谢建议,这样是可以的。 APIJSON 的核心就是 解析 JSON -> 转为 SQL -> 封装 JSON 的 ORM 库 APIJSONORM, 网络协议用 HTTP, TCP, UDP, Websocket 等都可以,只要支持传输 JSON 格式的文本就行了。
20190401 更新:已完成 https://github.com/TommyLemon/APIJSON/releases/tag/3.5.0
增强 LEFT JOIN / RIGHT JOIN 原来
"join": "</Comment/userId@"
这种 LEFT JOIN
LEFT JOIN (SELECT content FROM Comment) AS Comment ON Comment.userId = User.id
外层的 SELECT Comment.content ,即返回副表 Comment 的字段 必须 与 内层的一致, 但某些需求需要不一致,可以增强下 join 键值对,提供第二种写法:
"join": {
"</Comment/userId@": { //指定子查询外层的各种属性
"@column": "momentId,content",
"@order": "date-",
"@group": "momentId",
"@having": "momentId>100"
}
}
<dependency>
<groupId>org.postgresql</groupId>
<artifactId>postgresql</artifactId>
<version>42.2.5</version>
</dependency>
比较重要的一个问题
- 查询条件是前端页面动态拼装的,如果别人有意识地攻击接口,随意组装成十表联查的SQL语句,或者是拼装几个大表的笛卡尔积的SQL语句,数据库会吃不消
好的地方
- 这个项目可以让后端从curd的业务解放出来
- 缩减前后端对接的时间,提高效率
待完善的地方
- 看这个项目的多数都是Java开发的,其实介绍文档可以完全忽略eclipse导入Java项目过程。文档要写得精简,重点突出
- apijson的java项目,JavaScript项目,Android项目,单独划分出去,作为单独的项目
- 项目目录结构和项目命名大小写规范一点,无关重要的文件可以删掉,Oracle,MySQL,postgresql的初始化脚本各提供一份就可以了,不需要单独建文件夹去存放
- 项目应该全部改成maven形式,无须在libs引入postgres的jar包或者引入apijson-libarary的jar包,应该改成maven引入
<dependency> <groupId>org.postgresql</groupId> <artifactId>postgresql</artifactId> <version>42.2.5</version> </dependency>
不破不立
@hegphegp 感谢建议。 针对第一段的问题,APIJSON 目前做了 maxQueryCount,maxQueryPage 等查询数量限制,能导致笛卡尔积的 CROSS JOIN 也默认禁用了,不过确实还需要加强对连表的限制,提供 maxJoinCount,maxTableCount,maxArrayCount,maxDepth 等。 【更新】已提供 maxObjectCount, maxArrayCount, maxQueryDepth,其中 maxObjectCount 可限制 JOIN 数量。
说得挺到位的,不过还有节约流量等别的好处哦 https://github.com/TommyLemon/APIJSON/wiki
1.小白太多了,连导入工程、导入表等基础操作都希望有视频教程,我也很无奈,现有的教程还是保留吧。
2.之前划分出去过,但从下载量和提问来看,不少用户都没找到,反正也不大,都放一块吧,TensorFlow 也这么干的。 【更新】已把 ORM 外的源码及文档抽取到单独的项目 apijson-framework, APIJSON-Demo
3.这个会作为以后的优化点。
4.这个会作为一个优化重点,不过我对提交 Maven 仓库没啥经验,需要学习下,如果有热心的用户愿意帮忙就更好了。 【更新】APIJSON, apijson-framework 都以支持 Maven, Gradle 依赖
再次感谢你的建议。
1.建议结合python、c#版的文档对现有文档进行简化拆解,将apijson规范和apijson-java实现的部分区分开来,比如apijson规范的说明,apijson-java入门、apijson测试网站及工具介绍和使用教程、apijson-c#入门、apijson-java仿朋友圈教程等等
@wanghaisheng 感谢建议,目前 APIJSON 主项目(设计规范+Java版实现)的文档是已经简化拆解过的, 至于 C# 版, PHP 版, Python 版, Node(TypeScript) 版 APIJSON,这些都是其它作者维护的,可以给他们发 issue。
@TommyLemon 你可以稍微看一下c#和python 写的比java简明易懂多了 当然你可能还是会觉得现在的已经kangpick了
@wanghaisheng “写的比java简明易懂多了” 是指文档还是代码呢? APIJSON-CSharp 和 APIJSON-Python 都只是提供它和 Java 版不同的地方的文档, 其它都是指向 APIJSON 主工程,所以就省掉了很多 介绍、示例、规范 等文档。
如果说的是代码更简洁,主要原因是它们相对 Java 版来说功能还不够全(JOIN,子查询等), 其次是因为 C#, Python 语言本身就比 Java 更简洁,一般实现同样的功能代码量更少。
另外 kangpick 是啥意思?
apijson 目前的文档分为几大类 1.概要性的说明 用以说明apijson spec以及apijsonauto等提供的特性 与rest graphql的区别之处 对于前端开发 后端开发的好处 以及其潜在的应用场景(可以以行业为编排,比如说社交场景朋友圈动态或其他 这里可以与第二点呼应) 2.配置安装上手的入门 getstarted 针对不同的服务端实现,从基础环境(操作系统、编程环境、数据库环境)、apijson服务端的部署和发布、配置文件的修改/代码的修改说明; 客户端调用的说明(结合postman或不同编程语言调用代码,结合一中所提到的应用场景(比如说现在有的社交朋友圈的场景)说明apijson spec具体的使用,辅以与传统rest方式调用请求的对比) 3.apijson服务端实现(针对不同的编程语言实现,包括每种实现使用的框架、各模块的说明比如说APIJSONParser,每种实现与apijson功能点的对应关系,哪些实现了哪些没实现,哪些支持哪些不支持,甚至具体的api文档) 4.apijsonauto工具的介绍、使用,在2的基础上,说明该工具在具体场景中的应用(数据库层面、服务端层面、客户端调用层面)
虽大多数可能内容都有一些,就我来看,组织上是非常混乱的,可以调整的更好,更易于上手和传播
@TommyLemon kangpick==完美
@hegphegp 非常感谢,已经在原来的基础上又实现了 getMaxSQLCount, getMaxObjectCount, getMaxArrayCount, getMaxQueryDepth 4 个限制请求的方法,都有已经调好的默认值,可以重写这些方法自定义哦。 Parser.java https://github.com/TommyLemon/APIJSON/blob/2d01a5a2cf6cec551771d8c156c799fa2fb9d184/APIJSON-Java-Server/APIJSONORM/src/main/java/zuo/biao/apijson/server/Parser.java
AbstractParser.java https://github.com/TommyLemon/APIJSON/blob/2d01a5a2cf6cec551771d8c156c799fa2fb9d184/APIJSON-Java-Server/APIJSONORM/src/main/java/zuo/biao/apijson/server/AbstractParser.java
@wanghaisheng 不好意思啊,这么久没回。 对的,分了好几类,基本都有,只是确实还不是很清晰, 暂时也没时间去补充,还在完善功能呢, 要加 存储过程 啥的,文档后面再说哈。
@TommyLemon 我觉得你理解岔了 我是说你提供一些信息,我/社区可以帮助把不足的不够详细的都补充起来。但一些思路性的原理性的我是补不出来的 能力不够
@wanghaisheng 这样啊,非常感谢,请问需要提供哪些信息呢?
@TommyLemon 你现在这个项目里其实包含了两部分 一部分是spec的 一部分是java实现的 spec的部分 文档说明我觉得都问题不大 要调整都是细节 另外就是java实现这部分,按照我之前的想法,可以结合已有的其他语言实现所提供的环境配置、配置文件修改这些地方进行完善。我不太能理得清楚配置文件这块,因为其他语言的都比较简明易懂。 " 针对不同的服务端实现,从基础环境(操作系统、编程环境、数据库环境)、apijson服务端的部署和发布、配置文件的修改/代码的修改说明;"
@wanghaisheng 是的,主项目包含 设计规范(Specification) 和 Java实现(APIJSONORM),还有 APIJSONBoot(基于 SpringBoot),APIJSONFinal(基于 JFinal),Android, iOS, JavaScript 等各种 Demo 及相关文档。
目前 Java 版的配置有 1.@MethodAccess 权限注解 + Verifier 权限注册 Java 代码配置,这个以后会去掉,改成数据库配置动态加载,群友贡献了一个,在群文件里,叫“重载”; 2.数据和结构校验的配置,写在 Request.sql 表里面,校验规则及用法具体见 Wiki-实现原理; 3.角色访问权限文档配置,写在 Access.sql 表里面; 4.远程函数文档配置,写在 Function.sql 表里面;
具体和 APIJSONAuto 文档怎么对应的见 这个 Issue 以及内部关联的 另一个 Issue。
具体使用除了原有的 配置和部署文档,还有群友贡献的 详细的图文说明文档。
其它的后面再说吧,希望有热心的用户发 Pull Request 贡献下。
关于请求限制,可以自动把所有 预发布环境 的请求 Hash 或 MD5 后再保存下来, 线上环境就只允许这些请求,其它全都不允许通过,直接返回错误, 这样既保证了功能正常开发和使用,又保证不会接收到任何出乎意外的请求导致各种攻击等。
至于实现, 预发布环境下 保存到数据库,线上环境读数据再对比,需要一个环境的标识,后端控制, 类似现有的 boolean Log.DEBUG,发布到线上环境前修改下值就行。
建议加一些性能分析关键词 cache, explain 等
{
"[]": {
"page": 0,
"count": 50,
"join": "@/User/id@",
"cache": false, //设置 SQL_NO_CACHE,解决调试时缓存影响执行时间
"explain": true, //返回执行计划,而不是数据? 那就 query: 3 / query: "explain" 替代 ?
"Moment": {
"content$": "%a%"
},
"User": {
"id@": "/Moment/userId",
"@column": "id,name,head"
}
}
}
更新:已实现 @explain: true/false 和 @cache: "ALL"/"ROM"/"RAM",例如
{
"@explain": true,
"@cache": "RAM", //0-"ALL", 1-"ROM", 2-"RAM"
"User": {
"@column": "id,name"
},
"[]": {
"Comment": {
"userId@": "User/id"
}
}
}
@wanghaisheng 关于 "3.apijson服务端实现 之间的共同点和差异",部分库已经有说明了 APIJSON Python 版 uliweb-apijson (基本说明 + @combine 与 @expr + 自动化权限、数据、结构校验 的方式等) https://github.com/zhangchunlin/uliweb-apijson/blob/master/uliweb_apijson/apijson/README.md
APIJSONParser (基本说明 + JOIN 的写法 + 黑白名单 + 表权限、字段权限 等) https://github.com/Zerounary/APIJSONParser
APIJSON C# 版 APIJSON.NET (基本说明 + 额外提供的另一种 远程函数 写法等) https://github.com/liaozb/APIJSON.NET/tree/master/APIJSON.NET
希望实现SQL中的 distinct 关键字的功能。
@wanghaisheng
有个热心的 APIJSON 用户贡献了 apijson-doc 项目,并且部署到 GitHub 服务器了 🎉 https://vincentcheng.github.io/apijson-doc/zh/
点 ⭐ Star 支持下他吧 ^_^ https://github.com/vincentCheng/apijson-doc
@xiehuiSheldon 感谢建议,已支持去重关键词 DISTINCT
{
"[]": {
"Comment": {
"@column": "DISTINCT momentId;count(DISTINCT userId)",
"@group": "momentId"
}
},
"@explain": true
}
使用过程中看到控制台打印的日志都是红色的,建议加一个日志插件,使用日志插件打印日志,也能直接定位打印位置,也更灵活
@rxxy 感谢建议
加入事务控制 https://github.com/APIJSON/APIJSON/issues/105
更新: 已加上 5810ecf
@angelfreedomv 另一个 PHP 版 APIJSON,看起来功能比原来那个多不少,可以试试,点 Star 支持下吧^_^ https://github.com/qq547057827/apijson-php
另一个 APIJSON Node 版本也出来了, 支持单表、关联、数组、分页查询等,有比较完善的文档, 我测试过,除了项目提供的表有 utf8 编码问题导入不了 (用我自己的表测试可以),其它都可用。 作者是微医的,已经写了不少测试用例,在他公司内部用起来了。
点 Star 鼓励作者继续完善吧 ^_^ https://github.com/kevinaskin/apijson-node
建议新增 WITH AS 语法,提高某些情况下的 SQL 的性能和可读性。 鉴于子查询已实现,可基于子查询语法基础上新增 "with": true , 例如:
{
"sql@": {
"with": true, //表示这个子查询使用 WITH AS
"from": "User",
"User": {
"sex": 1
}
}
}
自动生成
WITH sql AS (SELECT * FROM User WHERE sex=1)
目前只有 User.id = Comment.userId 这种等价的 JOIN ON 关联方式,并且只有这个才能加到 ON 上。 希望支持复杂 JOIN ON ,并且支持把 WHERE 条件加到 ON 上(提前减少关联数据量,优化性能)
{
"[]": {
"join": {
"&/User/id~@": { //Comment INNER JOIN User ON User.id ~ Comment.userId, 其它 $, {}, <> 等同理
"@combine": "&sex,&name~" //表示 这两个条件加到 ON 上 ON ... AND (sex=1 AND name ~ 'a')
}
},
"Comment": {
"content$": "o"
},
"User": {
"id~@": "/Comment/userId",
"sex":1,
"name~":"a"
}
},
"@explain": true
}
@hegphegp 感谢建议,APIJSONORM 的 postgresql-42.2.4.jar 已替换为 42.2.5 的 Maven 依赖 https://github.com/APIJSON/APIJSON/commit/58d99bb2cf3c57158f8cb7648d84468403f930ae 已通过 APIAuto 接口管理平台的自动化测试
@hegphegp 感谢建议,APIJSON ORM 已支持 Maven, Gradle 等远程依赖方式,具体见 https://github.com/APIJSON/apijson-orm
202000302 更新:已实现
@zhoulingfengofcd 感谢建议 希望主项目新增时,可以支持采用数据库自增id,而不是业务代码生成 https://github.com/APIJSON/APIJSON/issues/120
这个需求大家反复提及,会优先实现(预计下个版本)
感谢建议:增加递归查询(recursive) https://github.com/APIJSON/APIJSON/issues/128
有什么功能建议可以在这里回复,点赞数高的回复将会被加入开发计划