干掉 RESTful!GraphQL 真香!
- 前言 -
滥用REST接口,导致大量相似度很高(具有重复性)的API越来越冗余。 对于前端而言:REST API粒度较粗,难以一次性符合前端的数据要求,前端需要分多次请求接口数据。增加了前端人员的工作量。 对于后端而言:前端需要的数据往往在不同的地方具有相似性,但却又不同,比如针对同样的用户信息,有的地方只需要用户简要信息(比如头像、昵称),有些地方需要详细的信息,这就需要开发不同的接口来满足这些需求。当这样的相似但又不同的地方多的时候,就需要开发更多的接口来满足前端的需要。增加了后端开发人员的工作量和重复度。
- GraphQL 简介 -
GraphQL是一种新的API标准,它提供了一种比REST更有效、更强大和更灵活的替代方案。 它是由Facebook开发并开源的,现在由来自世界各地的公司和个人组成的大型社区维护。 GraphQL本质上是一种基于api的查询语言,现在大多数应用程序都需要从服务器中获取数据,这些数据存储可能存储在数据库中,API的职责是提供与应用程序需求相匹配的存储数据的接口。 它是数据库无关的,而且可以在使用API的任何环境中有效使用,我们可以理解为GraphQL是基于API之上的一层封装,目的是为了更好,更灵活的适用于业务的需求变化。
GraphQL 对比 REST API 有什么好处?
- GraphQL 思考模式 -
GraphQL执行逻辑
使用了GraphQL就要完全抛弃REST了吗? GraphQL需要直接对接数据库吗? 使用GraphQL需要对现有的后端服务进行大刀阔斧的修改吗?
GraphQL应用的基本架构
GraphQL特点总结
声明式数据获取(可以对API进行查询): 声明式的数据查询带来了接口的精确返回,服务器会按数据查询的格式返回同样结构的 JSON 数据、真正照顾了客户端的灵活性。 一个微服务仅暴露一个 GraphQL 层:一个微服务只需暴露一个GraphQL endpoint,客户端请求相应数据只通过该端点按需获取,不需要再额外定义其他接口。 传输层无关、数据库技术无关:带来了更灵活的技术栈选择,比如我们可以选择对移动设备友好的协议,将网络传输数据量最小化,实现在网络协议层面优化应用。
- GraphQL 支持的数据操作 -
查询(Query):获取数据的基本查询。 变更(Mutation):支持对数据的增删改等操作。 订阅(Subscription):用于监听数据变动、并靠websocket等协议推送变动的消息给对方。
GraphQL的核心概念:图表模式(Schema)
对于数据模型的抽象是通过类型(Type)来描述的,每一个类型有若干字段(Field)组成,每个字段又分别指向某个类型(Type)。这很像Java、C#中的类(Class)。 GraphQL的Type简单可以分为两种,一种叫做Scalar Type(标量类型),另一种叫做Object Type(对象类型)。
- 标量类型(Scalar Type) -
String Int Float Boolean Enum ID
对象类型(Object Type)
类型修饰符(Type Modifier)
列表:[Type] 非空:Type! 列表非空:[Type]! 非空列表,列表内容类型非空:[Type!]!
- 其他类型 -
- Graphql 技术接入架构 -
- 服务端实现 -
- 客户端实现 -
作者:起个帅的名
来源:
https://juejin.im/post/6863283398727860238
评论