The Significance of GraphQL — Part 2 (How Facebook, Coursera and Artsy use GraphQL?)

In this article, I am going to discuss “How different companies like Facebook, Coursera and Artsy use GraphQL?” . (Before reading this article it would be better if you can have basic knowledge of GraphQL core concepts.)

How Facebook uses GraphQL?

Facebook uses GraphQL mainly in 3 ways.

  • Considers data in an application as a Graph.

Posts, comments, etc. on Facebook are considered as objects. The relationships between those objects are depicted by the edges of the graph. So while GraphQL is not a query language for graph databases, it is still an appropriate name because it queries the graph of your application data.

  • Single Source of Truth

Every time when you change the code or implement a new feature, you do not need to reimplement data fetching, business logic or security.

  • Considers the API Layer as a Thin Layer

The above concepts make the API layer as thin as possible and it does not consist of business logic. You can design your backend as you wish (you can design it as REST if you want) and put the GraphQL layer on top of it. This also means you can change your API without ruining your business logic.
Facebook has considered this layered architecture with 3 layers: External Interfaces, Business Logic , and Storage Layer .


If we consider a type of data, it has its own object model. Single Source of Truth is considered here, where a single function is called when there is a need to get an object from the backend. In here, always an object called Viewer will be accepted. Viewer represents the entity currently asking for data.


We can do authorization by passing the appropriate Viewer and information about the object to be fetched. This viewer is also known as the context in open source versions of GraphQL.


Fetching so much information in one request is not efficient. This leads to the concept called batching. Batching goes in the business logic layer. An open source JavaScript package is used known as DataLoader , which will collect the list of IDs we need to fetch and pass them to the batch function all at once.


After fetching an object if we can store it so that in future we can use it again without requesting it again from the backend. DataLoader does this by default.
If you want to learn more about How Facebook uses GraphQL? please refer the below link.

How Facebook organizes their GraphQL code

How Coursera uses GraphQL?

Coursera uses a tool in the middle to dynamically translate all their REST APIs to GraphQL.
In the beginning, Coursera has used APIs for courses, instructors and course grades only. But due to the demand, they had to extend the number of APIs they are using. New problems grew around the performance, documentation and general ease of use.

Challenges when Coursera was moving to GraphQL

  • Due to a large number of different REST endpoints at Coursera (over 1000), migration costs can be high.
  • For inter-service communication, all of the backend services used REST APIs. Also, the same APIs were exposed to both backend services and frontend clients.
  • Coursera had mainly 3 different clients which are web, iOS, and Android. So need a flexible method when moving on.

By considering all the challenges above they thought to add a GraphQL proxy layer on top of their REST APIs. ( )
They have taken 2 steps when migrating to GraphQL, where the 1st step has failed.

First Step — Failure

  • They built a few GraphQL resolvers and launched a GraphQL server in production to make downstream REST calls to their source endpoints.
  • They have used GraphiQL for verification and checked whether the data is being displayed on a demo page. In the beginning, this looked like a success but suddenly every GraphQL query has begun to fail.
  • Downstream course catalog service was rolled back to a previous version due to an unrelated bug, and the schema that they had built in their GraphQL service was now out of sync.
  • It was a tedious task to update the schemas manually because 1000 different resources backed by over 50 different services and keeping everything up to date was impossible.

Second Step

  • Thought of deterministically building their own GraphQL layer, reflecting what was currently running in the architecture not what thought was running.
  • Each service was able to dynamically provide with a list of REST resources running on it. For each of the resources, they could introspect the list of endpoints and arguments (i.e. a course endpoint would have a fetch by id, or lookup by instructor) Additionally, they received Pegasus Schemas, defined by our Courier schema language for each model returned.
  • Once discovered the different pieces that need to build a GraphQL schema, they set up a task on the GraphQL server to ping every downstream service every five minutes, and request all of that information. They were able to write a 1:1 conversion layer between the Pegasus Schemas and GraphQL types.
  • Then simply defined a translation between GraphQL queries and REST requests.

Overcoming the Problems with relating resources

  • Their initial approach only provided a one-to-one mapping between the models. Like in REST, several round trips were needed when fetching data from GraphQL.
  • REST APIs each live in a SILO but in GraphQL models and resources do need to know about each other, and how everything is connected.
  • Defined a simple annotation known as Forward Relations that developers could add to resources to specify the relations between them.
  • As an Example — A course resource should have an instructors field representing the instructors who teach that course. And to fetch those instructors, we should look up instructors by id, using the instructor Ids field already available on the course.
  • What they implement was when we wanted to go from one resource to another where there wasn’t an explicit link, do a reverse lookup to fetch it

How Artsy uses GraphQL?

  • Non-legacy code for their web and mobile apps communicates with a GraphQL server built in Node.js and express.
  • Provides a single API endpoint for the client and forwards requests to the core API.
  • Recently gave the support mutations via Relay.
  • They were able to build faster mobile apps.
  • Their decision to move from Swift to React Native was heavily influenced by the desire to use GraphQL.


Since this article is getting lengthy, I will discuss other organizations which use GraphQL in the next article. Until then, Good Bye!

Previous Article

The Significance of GraphQL — Part 1 (GraphQL vs. REST)

📝 Read this story later in Journal .
🗞 Wake up every Sunday morning to the week’s most noteworthy Tech stories, opinions, and news waiting in your inbox: Get the noteworthy newsletter >

This content was originally published here.

Other FinTech Healines