说说GraphQL

graphql
rest

#1

REST的现实问题

under-fetching问题

现如今,典型的手机应用如社交网络APP,其软件界面只是复杂后端(云端)数据的前端展示,单个界面需要加载的数据资源非常多,对应于 REST 架构而言,这些数据分属于不同的资源(endpoint),以 REST 的方式没有办法一次请求加载,需要多个请求才能加载,有的资源因为之间的关联关系,加载还有先后顺序要求,因此使用 REST 的方式处理这样的单页就意味着多个 REST 请求,甚至多个往返的的 REST 的请求,在移动互联网不是很稳定的情况下,这种加载造成的延迟往往会影响用户体验。这个问题就是under-fetching问题,在某些应用场景下, REST 一次接口调用的数据满足不了需求。

over-fetching问题

REST 架构的接口是以资源为中心,接口定义不仅简单而且具有自描述的特点,每一个action(比如show)加上资源(endpoint URI)就定义了接口的功能,但是 REST 架构的接口语义没有关于资源更加细粒度的数据范围定义,所以利用这个架构可以描述这么一种需求:“show id 为xx的post资源”,这时post资源的数据将“全部”返回给客户端,但不能描述这样的需求:“show id为xx的post资源,且只返回title和body属性内容”,这个问题就叫做over-fetching,为什么之前的“全部”加上引号呢,因为对于 REST 架构的接口语义而言,他的语义就是全部,但是在实际的实现上是可以在后端进行过滤的,比如一般你会将user资源的password或者password_digest过滤掉,也可以在URI中加上其它的参数进行限定,但是这种过滤对 REST 架构的接口而言是透明、非接口化、非规范化的。

GraphQL解决了上述问题。

In GraphQL, describe your data, ask for what you want, get predictable results.

GraphQL是什么

GraphQL是一种开源的数据查询和操作语言,也代表支持该类型数据查询和操作语言运行时。由Facebook于2012年开发并内部使用,2015年Facebook公司正式将其对外发布。可以说GraphQL的产生背景是现有的REST接口架构难以满足移动互联网(应用),需要更加灵活、高效解决方案。不同于REST架构,GraphQL允许客户端指定(定义)请求所需的数据结构、属性和数量等需求,服务端按照客户端的需求返回数据,避免了REST架构存在的over-fetching和under-fetching问题。此外,GraphQL支持读、写和订阅三种操作,其中读、写操作覆盖了REST中的index、show、update、create和delete所有操作,订阅则是可被动接收服务端数据变化的推送。

Major GraphQL clients include Apollo Client and Relay. GraphQL servers are available for multiple languages, including Haskell, JavaScript, Python, Ruby, Java, C#, Scala, Go, Elixir, Erlang, PHP, R, and Clojure.

未完待续

The Fullstack Tutorial for GraphQL


#2

期待下文,最近也关注到GraphQL


#3

最近比较懒,希望不要烂尾 :smiley:


#4

Introspected REST: An alternative to REST and GraphQL


#5

@kevin 有意思


#6

这文章好长,感觉 Graphql 可能是一种过度技术