接口聚合

[CntChen]

背景

前端页面与后台的交互方式一般是在页面解析完成后，使用异步接口请求后台数据，然后根据数据渲染出前端页面．前后端交互的关键在于接口：

• 接口协议为 HTTP/HTTPS，调用方式为 XHR/Fetch；
• 接口的协议参数(headers)，请求类型，状态码，缓存，内容类型，跨域；
• 页面数据完成展示需要调用的接口数，影响用户的等待时间；
• 接口交互的数据和数据的使用率，应该减少不必要数据的传输，以减少带宽；

存在的问题

前端的特定场景，比如首页，需要不同维度的多种数据，数据需要调用多个接口才能获得，导致前端的请求过多，在移动端这种非健壮性网络下导致页面白屏时间长。所以存在以下矛盾：

• 前端不想调用原子接口，而是后台提供聚合的接口;
• 后台接口设计思路是接口单一职责和原子性，不会直接提供大接口。

另外一方面，在不同场景，希望接口可以返回指定的数据，减少没必要数据的传输。在 RESTful 上的实现，通常是带上查询参数，接口使用场景多了后，接口中的处理逻辑变得复杂和难以维护。

RESTful

Representational state transfer 是目前主流的客户端和服务端交互方式。REST 服务允许客户端通过预先定义的无状态操作，访问或修改用文本表示的服务端资源．

• 使用 URI 描述服务端资源；
• 定义对资源的操作　GET/POST/PUT/DELETE。

后台微服务 microservice

将后台服务拆分为功能独立的系统，具有业务的独立性和完整性，减少服务间的依赖。微服务可以独立部署，便于负载管理和优化。微服务通过API Gateway 提供 RESTful 的接口。

外观接口/接口聚合

RESTful 下的接口聚合，服务端的业务复杂度，接口性能不高，并且复用性不高。

GraphQL

query language for APIs - GraphQL

GraphQL 是一种标准语言，类型系统，创建前后端强契约的规范，使得前后端的数据交互处理过程得到简化。客户端可以从服务端的数据集中获取自定义结构的数据．

特点

• 调用方描述所需数据，并得到可预测的返回
• 通过单接口获取多种资源，减少调用方调用的接口数量
• 使用接口描述进行接口演变，不需要更新版本
• 可以在已有数据和代码基础添加 GraphQL，支持多种编程语言

REST vs GraphQL

• 大规模的应用中 REST 的请求多
• GrapaQL 返回的数据可制定，都是有效的负载；REST存在冗余，使用带查询参数的方法拓展性差
• REST 的接口变动通常需要新的 EndPoint，因为无法确定那些字段不再被使用，新的 EndPoint 接口代码和文档的增加；
• GraphQL 可以统计接口字段的使用情况，接口演化通过修改 Schema 实现；
• 开发体验相关

GraphQL 部署实践

关键思考

• 如何将 GraphQL 与现有后台接口结合起来使用
• Node 中间层

References

• REST 2.0 Is Here and Its Name Is GraphQL

https://www.sitepoint.com/rest-2-0-graphql/

• GraphQL文档

http://graphql.org/learn/

EOF

https://www.one-tab.com/page/lSkFh92GTB6S-iierEr7Kw