-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
不是很懂apiJSON的原理,能讲解一下吗?我想写一个node.js版的apiJSON服务端 #6
Comments
@testsla 太好了,领导说要转node,但现在看来还要过一段时间。你实现一个node版到时候我可以参考下嘿嘿😜 1.解析请求的JSON结构: 2)Parser.parseResponse() 整体解析,主要解析数组JSONArray:[],并将对象JSONObject:{}交给ObjectParser解析 3)ObjectParser.parse() 解析对象JSONObject:{} 2.解析请求的JSON内容: 2)SQLConfig.newSQLConfig() 解析表对象内容Table:{},getSQL()函数会根据表对象内容生成SQL语句 3.执行SQL语句并返回JSONObject: 4.原路返回结果并用结果替换原来的请求内容 |
@testsla 可以用敏捷开发方式,一开始只做核心功能,其它所有功能都不管。等核心功能实现了再加入其它功能。性能一开始也不考虑,先实现后优化。 |
@TommyLemon 周五吃了老板的鱿鱼,所以没回复。 |
@testsla 这样啊,祝你找到满意的工作 |
@testsla 看看这个,自动生成markdown文档,可展开/收起的带高亮格式化JSON,嘿嘿 |
@testsla Nodejs现成的SQL builder有 knexjs ,难点在于解析字符串、和APIJSON用同一套规范解析字符串…… 一堆正则 一堆if else等着呢…… 兄弟,搞么?…… |
@lgh06 // Query both of the rows.
.then(function() {
return knex('users')
.join('accounts', 'users.id', 'accounts.user_id')
.select('users.user_name as user', 'accounts.account_name as account');
}) 这种调join,select等函数的静态封装方式都做不了APIJSON的JSON转SQL语句这个功能的。 APIJSON-Java-Server里的Library也是一个ORM库,它通过SQLConfig来动态封装SQL语句。 |
不应该把knexjs归类为ORM,而应该归类为 辅助SQL语句生成的 一个库。 用Java来定义Model是第一步,必选项…… 我现在是非常懒,不想一个一个去定义model,而graphql要求定义model,所以找了找类似的。 目前来看,参照parse和leancloud,后端使用mongodb吧…… (nodejs是个动态类型的语言,用JSON.parse/JSON.stringify就能在json和对象间转换,没必要学java去定义各种model和字段名…… mongodb也不要求必须定义字段类型…… node还是和mongodb配……) (其实后端逻辑减少了之后,前端的逻辑会相应增加,各种查询的约束条件、列选择,都写在了前端中…… ) |
@lgh06 GraphQL可不止是要定义Model(官方叫Type)啊,还要针对每个需求定义Schema,才能按照Schema的结构来请求,灵活性仅仅限于字段和成语接龙式的嵌套(A schema里包含B schema,B schema里包含A schema,就可以写成 {
A {
B {
A {
B {
...
}
}
}
}
} 这种,但不能是 {
A {
}
B {
}
} 也不能是 {
A {
}
C {
}
} 等其它任何结构,除非后端再写对应的一大堆Schema。 APIJSON的开放查询请求不限制结构内容,传任何结构和内容都行,都是APIJSONLibrary这个ORM库完全自动化解析成SQL语句,期间根据@MethodAccess注解配置自动校验权限。 1.搜索内容【以…结束】的动态 {
"[]": {
"count": 5,
"page": 0,
"Moment": {
"content$": "%…"
}
}
} 2.搜索内容【以A开始】的动态+【内部】放发布者User {
"[]": {
"count": 5,
"page": 0,
"Moment": {
"content$": "A%",
"User": {
"id@": "/userId"
}
}
}
} 3.搜索内容【包含A】的动态+【外部】放发布者User {
"[]": {
"count": 5,
"page": 0,
"Moment": {
"content$": "%A%"
},
"User": {
"id@": "/Moment/userId"
}
}
} 4.每个Moment内比3多了一个评论Comment列表 {
"[]": {
"count": 5,
"page": 0,
"Moment": {
"content$": "%A%"
},
"User": {
"id@": "/Moment/userId"
},
"[]": {
"count": 3,
"Comment": {
"momentId@": "[]/Moment/id"
}
}
}
} 5.将4中的评论列表项Comment去包装(提取一层) {
"[]": {
"count": 5,
"page": 0,
"Moment": {
"content$": "%A%"
},
"User": {
"id@": "/Moment/userId"
},
"Comment[]": {
"count": 3,
"Comment": {
"momentId@": "[]/Moment/id"
}
}
}
} 6.将5中的User只返回id,sex,name {
"[]": {
"count": 5,
"page": 0,
"Moment": {
"content$": "%A%"
},
"User": {
"@column": "id,sex,name",
"id@": "/Moment/userId"
},
"Comment[]": {
"count": 3,
"Comment": {
"momentId@": "[]/Moment/id"
}
}
}
} APIJSON和GraphQL的初步详细对比 |
@lgh06 APIJSON目前写model都是为了权限管理,只需要3行代码就能配置一张表的权限。 |
@lgh06 关于前端逻辑增加,这个是定制后端返回的数据内容和结构必然会带来的问题,不过APIJSON提供了一套统一且简单清晰的规范以及丰富的示例: 加上APIJSON提倡后端把 测试用例(请求的URL和JSON参数)填好上传到APIJSONAuto接口管理工具 所以前端直接复制过来就行了。 Android,iOS客户端可以复制右侧自动生成的代码。 |
确实牛逼……
建议:
暂时写这么多。 |
@lgh06 哈哈,非常感谢。 |
不行 不行 求nodejs实现 |
@yuu2lee4 APIJSON Node 版已经有了,给热心的开发者点 Star 支持下吧 ^_^ |
@lgh06 @yuu2lee4 另一个 APIJSON Node 版本也出来了, 点 Star 鼓励作者继续完善吧 ^_^ |
No description provided.
The text was updated successfully, but these errors were encountered: