GraphQL Architecture & Use case

“GraphQL has been released only as a specification. This means that GraphQL is in fact not more than a long document that describes in detail the behaviour of a GraphQL server.”。这是我在官网上看见的一个定义，比起“GraphQL是一种语言”的说法，我认为上边的定义更贴切。

 

什么是Specification

“Specification” 这个词大家并不陌生，我拿java举例子，如果你熟悉并能理解什么是J2EE，就会对这个词有很好的感受，翻译成汉语是“规范”的意思，就像我们写java的servlet，jdbc，jpa，我们只是面向接口编程，我们并没有关注具体的实现是怎么样的，但是我们很清楚我们的代码将会有怎么样的行为，这就是“规范”的作用，当我们的项目运行在不同的应用服务器上的时候（比如Tomcat，JBoss，Websphere）， 这些不同厂商的应用服务器会对J2EE的规范进行具体的实现。

 

为什么GraphQL是Specification

首先，如果你对GraphQL的概念比较模糊的话，你需要明确一点的是，GraphQL并不是一个写好的library，并不是一个框架，不是说你把代码download下来，然后在你的代码里调用它的function，并不是这样。

根据定义，GraphQL只是明确啦一种提供API的方式，比如定义啦type system，schema以及怎么对外提供API endpoint，现在有不同语言的实现比如java，nodejs。

 

下面是官网介绍的三种典型的use case，（比较懒，不翻译啦，大家练练英语阅读吧。。。）

 

Use Cases

In this section, we’ll walk you through 3 different kinds of architectures that include a GraphQL server:

1. GraphQL server with a connected database
2. GraphQL server that is a thin layer in front of a number of third party or legacy systems and integrates them through a single GraphQL API
3. A hybrid approach of a connected database and third party or legacy systems that can all be accessed through the same GraphQL API

1. GraphQL server with a connected database

This architecture will be the most common for greenfield projects. In the setup, you have a single (web) server that implements the GraphQL specification. When a query arrives at the GraphQL server, the server reads the query’s payload and fetches the required information from the database. This is called resolving the query. It then constructs the response object as described in the official specification and returns it to the client.

It’s important to note that GraphQL is actually transport-layer agnostic. This means it can potentially be used with any available network protocol. So, it is potentially possible to implement a GraphQL server based on TCP, WebSockets, etc.

GraphQL also doesn’t care about the database or the format that is used to store the data. You could use a SQL database like AWS Aurora or a NoSQL database like MongoDB.

 

2. GraphQL layer that integrates existing systems

Another major use case for GraphQL is the integration of multiple existing systems behind a single, coherent GraphQL API. This is particularly compelling for companies with legacy infrastructures and many different APIs that have grown over years and now impose a high maintenance burden. One major problem with these legacy systems is that they make it practically impossible to build innovative products that need access to multiple systems.

In that context, GraphQL can be used to unify these existing systems and hide their complexity behind a nice GraphQL API. This way, new client applications can be developed that simply talk to the GraphQL server to fetch the data they need. The GraphQL server is then responsible for fetching the data from the existing systems and package it up in the GraphQL response format.

Just like in the previous architecture where the GraphQL server didn’t care about the type of database being used, this time it doesn’t care about the data sources that it needs to fetch the data that’s needed to resolve a query.

 

3. Hybrid approach with connected database and integration of existing system

Finally, it’s possible to combine the two approaches and build a GraphQL server that has a connected database but still talks to legacy or third—party systems.

When a query is received by the server, it will resolve it and either retrieve the required data from the connected database or some of the integrated APIs.