腾讯开源 APIJSON 连创五个第一

腾讯第一个码云推荐项目，// 其它最早创建的是 TencentOS-tiny(码云) 2019.8.23

腾讯第一个码云 GVP 项目，// 其它最早创建的是 TencentOS-tiny(码云) 2019.8.23

腾讯码云官方所有项目中 Star 第一，// 其它最高是 TencentOS-tiny(码云) 272 个 Star

腾讯所有后端开发项目中 Star 第一，// 其它最高是 libco(GitHub) 5.8K Star

腾讯所有网络编程项目中 Star 第一。// 其它最高是 TencentOS-tiny(GitHub) 4.7K Star

https://www.oschina.net/news/120011

腾讯开源 APIJSON 连创五个第一

腾讯第一个码云推荐项目，// 其它最早创建的是 TencentOS-tiny(码云) 2019.8.23

腾讯第一个码云 GVP 项目，// 其它最早创建的是 TencentOS-tiny(码云) 2019.8.23

腾讯码云官方所有项目中 Star 第一，// 其它最高是 TencentOS-tiny(码云) 272 个 Star

腾讯所有后端开发项目中 Star 第一，// 其它最高是 libco(GitHub) 5.8K Star

腾讯所有网络编程项目中 Star 第一。// 其它最高是 TencentOS-tiny(GitHub) 4.7K Star

https://www.oschina.net/news/120011

-news

腾讯 APIJSON-零代码接口和文档 ORM 库

使用安全简单 (自动增删改查、自动生成文档、自动管理版本、自动控制权限、自动校验参数、自动防 SQL 注入等)

灵活定制业务 (在后端编写 远程函数，可以拿到 session、version、当前 JSON 对象 等，然后自定义处理)

解决十大痛点 (APIJSON 大幅提振开发效率、强力杜绝联调扯皮、巧妙规避文档缺陷、非常节省流量带宽 等)

开发提速巨大 (CRUD 零代码热更新自动化，APIJSONBoot 对比 SSM、SSH 等保守估计可提速 20 倍以上)

腾讯官方开源 (使用 GitHub、Gitee、工蜂 等平台的官方账号开源，微信公众号、腾讯云 + 社区 等官方公告)

社区影响力大 (GitHub 9.6K Star 在 350W Java 项目中排名前 150，远超 FLAG, BAT 等国内外绝大部分开源项目)

各项荣誉成就 (腾讯开源五个第一、腾讯首个 GVP 获奖项目、腾讯后端项目 Star 第一、GitHub Java 周榜第一 等)

多样用户案例 (腾讯内部用户包含 互娱、音乐、云与智慧，外部用户包含 500 强上市公司、数千亿资本国企 等)

适用场景广泛 (社交聊天、阅读资讯、影音视频、办公学习 等各种 App、网站、公众号、小程序 等非金融类项目)

周边生态丰富 (Android, iOS, Web 等各种 Demo、继承 JSON 的海量生态、零代码 接口测试 和 单元测试 工具等)

文档视频齐全 (项目介绍、快速上手、安装部署 等后端、前端、客户端的 图文解说、视频教程、代码注释 等)

功能丰富强大 (增删改查、分页排序、分组聚合、各种 JOIN、各种子查询、跨库跨表、性能分析 等零代码实现)

高质可靠代码 (代码严谨规范，商业分析软件源伞 Pinpoint 代码扫描报告平均每行代码 Bug 率低至 0.15%)

兼容各种项目 (对各类 Web 框架集成友好且提供 SpringBoot, JFinal 的 Demo，协议不限 HTTP，与其它库无冲突)

工程轻量小巧 (仅依赖 fastjson，Jar 仅 280KB，Java 文件仅 59 个共 13719 行代码，例如 APIJSONORM 4.3.1)

多年持续迭代 (自 2016 年开源至今已连续维护 4 年，累计 2000+ Commits、70+ Releases，不断更新迭代中...)

https://github.com/Tencent/APIJSON

腾讯 APIJSON 在 功能、安全、性能、易用性、Java 版生态 (继承 JSON 的相关生态) 等都大幅领先 GraphQL。 https://github.com/Tencent/APIJSON/issues/63

没看到，目前 腾讯 APIJSON 应该只有官方的 Java 版和其它作者开发的 C#, Python, Node, PHP 版 https://github.com/search?o=desc&q=apijson&s=stars&type=Repositories

前后端分离能够让专业的人干专业的事， 不管是前端还是后端效率都提高很多， 但分离后又给前后端开发人员增加了很大的沟通成本。

所以只有当前端和后端达到一定的复杂度后， 分离后才在整体上体现出优势， 否则就是杀鸡用牛刀嫌刀顿了。

APIJSON 就是用来解决分离后各种扯皮、联调等问题的工具， 自动将前端传的 JSON 参数转为 SQL 语句执行并返回结果， 期间自动校验权限、结构、内容，自动防 SQL 注入。

通过自动化 API，前端可以定制任何数据、任何结构！ 大部分 HTTP 请求后端再也不用写接口了，更不用写文档了！ 前端再也不用和后端沟通接口或文档问题了！再也不会被文档各种错误坑了！ 后端再也不用为了兼容旧接口写新版接口和文档了！再也不会被前端随时随地没完没了地烦了！

在线解析 自动生成文档，清晰可读永远最新 自动生成请求代码，支持 Android 和 iOS 自动生成 JavaBean 文件，一键下载 自动管理与测试接口用例，一键共享 自动校验与格式化 JSON，支持高亮和收展

对于前端 不用再向后端催接口、求文档 数据和结构完全定制，要啥有啥 看请求知结果，所求即所得 可一次获取任何数据、任何结构 能去除重复数据，节省流量提高速度

对于后端 提供通用接口，大部分 API 不用再写 自动生成文档，不用再编写和维护 自动校验权限、自动管理版本、自动防 SQL 注入 开放 API 无需划分版本，始终保持兼容 支持增删改查、模糊搜索、正则匹配、远程函数等

后端接口和文档自动化，前端 (客户端) 定制返回 JSON 的数据和结构！ 创作不易，GitHub 右上角点 Star 支持下吧，谢谢^_^ github.com/TommyLemon/APIJSON

@sapphire @hegwin @tangmonk

完爆 Facebook/GraphQL，APIJSON 全方位对比解析 (三)-表关联查询 https://my.oschina.net/tommylemon/blog/1857762

完爆 Facebook/GraphQL，APIJSON 全方位对比解析 (二)-权限控制 https://juejin.im/post/5b13cda1f265da6e4a6bcfee

完爆 Facebook/GraphQL，APIJSON 全方位对比解析 (一)-基础功能 https://juejin.im/post/5ae80edd51882567277433cf

有两个公司试过了，发现复杂难用，一大堆概念，线上 Product 级别的 Demo 又少，学习和迁移很高，所以都没用起来。其中有一家改用 APIJSON 了。 https://github.com/TommyLemon/APIJSON

完爆 Facebook/GraphQL，APIJSON 全方位对比解析 https://my.oschina.net/tommylemon/blog/1857762

有两个公司试过了，发现复杂难用，一大堆概念，线上 Product 级别的 Demo 又少，学习和迁移很高，所以都没用起来。 其中有一家改用 APIJSON 了。 https://github.com/TommyLemon/APIJSON

完爆 Facebook/GraphQL，APIJSON 全方位对比解析 https://my.oschina.net/tommylemon/blog/1857762

完爆 Facebook/GraphQL，APIJSON 全方位对比解析 (一)-基础功能 https://juejin.im/post/5ae80edd51882567277433cf

完爆 Facebook/GraphQL，APIJSON 全方位对比解析 (二)-权限控制 https://juejin.im/post/5b17518c6fb9a01e75463096

完爆 Facebook/GraphQL，APIJSON 全方位对比解析 (三)-表关联查询 https://juejin.im/entry/5b4ff88f6fb9a04f914a8df5

除了目标一致，其它完全不一样，不管是思路还是实现。 GraphQL 是查询语言，APIJSON 是 JSON 传输结构协议 (也包括内容)。 用 GraphQL 就要学习一堆概念和语法，前端要后端要写一大堆 schema 才能用对应 schema 结构的特定格式来请求，正因为 GraphQL 格式特殊，整个后端都要重写。 而 APIJSON 只是一个简单的 JSON 对应协议，采用标准且通用的的 JSON 格式，只有少数几个简单的概念，没有所谓的语法，Request 和 Response 的结构严格对应，支持任意组合任意嵌套任意内容，并且还能和原来的 RESTful API 无缝兼容，几乎无迁移成本。 可以试试 https://github.com/TommyLemon/APIJSON

确实很复杂，概念就很多很绕了，schema,mutation,Subscription,Source Stream,Notation Conventions... 而且 Request 和 Schema 并不是严格对应，尤其是多层嵌套的时候，Schema 内层对象得通过外部函数调用来获取。 字段关联居然要手动 resolve，前端发的每个 Request 都必须在后端先有对应的 Schema 声明。 GraphQL 并没有替代 REST，而是在 Web/Client 到 REST Sever 中间用 GraphQL Server 做了个中间层，最后还是调 REST API.

@chenge

你好，感谢你的关注。
查询：
GraphQL-半自动化，只有过滤字段实现了自动化，且字段需要手动 resolve。
APIJSON-完全自动化，任意结构任意内容，只要数据库里有。

兼容性：
GraphQL-GraphQL 特定格式，只能用 GraphQL Server,Client,Web 全套。
APIJSON-标准 JSON 格式，能用 JSON 的地方就能用 APIJSON。

为了公平起见，以下 GraphQL 的所有示例都出自官方文档及代码。

1.查询条件
GraphQL:

table(key0:value0,key1:value1,...) {
}

{
  user(id: 4) {
    id
    name
  }
}

APIJSON:

Table: {
    key0:value0,
    key1:value1,
    ...
}

{
    "User":{
        "id":38710
    }
}

2.返回字段
GraphQL:
只返回已声明字段

{
    key0
    key1
    ...
}

{
  user(id: 4) {
    id
    name
  }
}

APIJSON:
默认返回全部，可加上以下条件限制

"@column":"key0,key1,..."

{
    "User":{
        "id":38710,
        "@column":"id,name"
    }
}

3.查询数组：
GraphQL:
需要后端在 schema 中手动 resolve

query noFragments {
  user(id: 4) {
    friends(first: 10) {
      id
      name
    }
  }
}

APIJSON:
"[]":{} 自动解析

{
    "[]":{
        "count":10,
        "User":{
        }
    }
}

4.关联查询：
需要后端在 schema 中手动 resolve 关联
GraphQL:

query inlineFragmentTyping {
  profiles(handles: ["zuck", "cocacola"]) {
    handle
    ... on User {
      friends {
        count
      }
    }
    ... on Page {
      likers {
        count
      }
    }
  }
}

APIJSON:
"key@":"key0/key1/.../targetKey" 自动解析

{
    "[]": {
        "User": {
            "name$": ["Strong", "Mike"]
        },
        "Moment": {
            "userId@": "[]/User/id"
        }
    }
}

5.后端定义结构
GraphQL:
读、写操作都需要，代码中，且字段要手动 resolve。
Node.js

var schema = new GraphQLSchema({
  query: new GraphQLObjectType({
    name: 'RootQueryType',
    fields: {
      hello: {
        type: GraphQLString,
        resolve() {
          return 'world';
        }
      }
    }
  })
});

Java

GraphQLObjectType queryType = newObject()
                        .name("helloWorldQuery")
                        .field(newFieldDefinition()
                                .type(GraphQLString)
                                .name("hello")
                                .staticValue("world"))
                        .build();

        GraphQLSchema schema = GraphQLSchema.newSchema()
                        .query(queryType)
                        .build();

APIJSON:
只有写操作才需要，自动解析自动校验，而且是在数据库 Request 表中定义，完全可视化。

{
    "Moment":{
        "DISALLOW":"id",
        "NECESSARY":"userId,pictureList"
    }
}

6.前端查询灵活性
GraphQL:
1.所有结构都要后端先定义，前端/客户端才能按照已定义结构查询。
2.多层嵌套需要后端在结构外声明内部结构，不够直观，Request 和 Response 不能完全对应 (Request 少了内层结构)。

后端定义：

const UserType = new GraphQLType({
    name:'User",
    fields:{
        id:{
            type:GraphQLInt
        },
        name:{
            type:GraphQLString
        }
    }
})

const CommentType = new GraphQLType({
    name:'Comment",
    fields:{
        id:{
            type:GraphQLInt
        },
        toId:{
            type:GraphQLInt
        },
        userId:{
            type:GraphQLInt
        },
        content:{
            type:GraphQLString
        }
    }
})


const MomentType = new GraphQLType({
    name:'Moment",
    fields:{
        id:{
            type:GraphQLInt
        },
        userId:{
            type:GraphQLInt
        },
        title:{
            type:GraphQLString
        },
        content:{
            type:GraphQLString
        },
        user:{
            type:new GraphQLObject(UserType)
            resolve:(moment) => getUserById(userId)
        },
        comments:{
           type:new GraphQLList(CommentType),
           resolve:(moment) => moment.commentIds.map(id => getCommentById(id))
        }
    }
})


function getUserById(id) {
    //查询User...
    return new UserType(id) //这里只是模拟，实际代码一般会比较多
}

function getCommentById(id) {
    //查询Comment...
    return new CommentType(id) //这里只是模拟，实际代码一般会比较多
}

前端请求：

query momentFragmentTyping {
     moments(first: 10, text: "a") {
            id
            userId
            title
            content
            user {
                id
                name
            }
            comments(first: 2) {
                    id
                    toId
                    userId
                    content
            }
     }
})

注：实在找不到官方的，群里问出了这个。

APIJSON:
1) 不需要后端定义，只要 类声明 + 权限注解 + 权限注册 3 行代码配置 Model 允许的操作及对应的角色。
3) 可任意组合、任意嵌套，Request 和 Response 完全对应。

后端定义：

//注册表并添加权限，以下都用默认
@MethodAccess
public class User {
}

@MethodAccess
public class Comment {
}

@MethodAccess
public class Moment {
}

//AccessVerifier内添加权限
accessMap.put(User.class.getSimpleName(), getAccessMap(User.class.getAnnotation(MethodAccess.class)));
accessMap.put(Moment.class.getSimpleName(), getAccessMap(Moment.class.getAnnotation(MethodAccess.class)));
accessMap.put(Comment.class.getSimpleName(), getAccessMap(Comment.class.getAnnotation(MethodAccess.class)));

前端请求：

{
  "[]":{                             //请求一个数组
    "page":0,                        //数组条件
    "count":2,
    "Moment":{                       //请求一个名为Moment的对象
      "content$":"%a%"               //对象条件，搜索content中包含a的动态
    },
    "User":{
      "id@":"/Moment/userId",        //缺省依赖路径，从所处容器的父容器路径开始
      "@column":"id,name,head"       //指定返回字段
    },
    "Comment[]":{                    //请求一个名为Comment的数组，并去除Comment包装
      "count":2,
      "Comment":{
        "momentId@":"[]/Moment/id"   //完整依赖路径
      }
    }
  }
}

7.前端写操作请求
GraphQL:
代码中定义 mutation schema。

mutation {
  likeStory(storyID: 12345) {
    story {
      likeCount
    }
  }
}

APIJSON:
操作单条记录必传"id":Long，操作多条记录必传"id{}":[Long]，还有自动化权限校验，保证安全性。

{
    "Moment":{
        "id":12,
        "praiseUserIdList+":[
            38710
        ]
    }
}

等我有时间再发篇博文，做一个详细的比较。
APIJSON 目前有 Java Server,Android,JavaScript 3 种实现，如果要和 GraphQL 比，这几种语言随便挑。

APIJSON 在线测试
http://39.108.143.172

APIJSON 项目主页
https://github.com/TommyLemon/APIJSON

欢迎使用、建议、吐槽、反馈 ^_^