最近我们 team 计划做相关的事情,大致调查了一下业内的解决方案,无外乎如下几种:
在服务端聚合,也就是我们现在的模式:通过人工的方式写代码来处理,这样虽然可以解决问题但是会耗费比较大的人力,而且做这件事情的人可能会感觉没有挑战,基本是重复劳作。
在客户端聚合,通常见到的实现有 graphQL,这样的好处是服务端可以保持简单精简,但工作量其实下放到了客户端,而且版本控制变得不太好处理了(比如兼容多个客户端版本)
我目前可以想到的自己觉得还可以的方法,就是结合如上两种方式:客户端请求服务端时带参数和 graphql 的 id,服务端根据 id 可以获取到 graphql 的查询体,这样其实就是将接口聚合的工作放到了 graphql 查询的维护上面,类似的实现可以看下 instagram 的接口。但是同样也有问题,那就是 graphql 查询 的维护这个工作应该谁来做?
小弟第一次发帖,希望大佬们多多给点建议~ 没有建议的对我想的这个方法提一些意见,或者可能会有什么坑之类的都可以说说看~
1
TommyLemon 2018-07-16 18:26:20 +08:00
APIJSON,自动将前端传的 JSON 转化为 SQL 执行并返回对应结构的 JSON。
后端接口和文档自动化,前端(客户端) 定制返回 JSON 的数据和结构! |