GraphQL :: A data query language

GraphQL was internally developed by Facebook in 2012. Facebook’s mobile apps have been powered by GraphQL since 2012. A GraphQL spec was open sourced in 2015 and is now available in many environments.

Relay is the javascript client for GraphQL that Facebook uses. It’s actually a software that adds many things on top of GraphQL such as query merging, pagination and deferred queries.

A GraphQL query is a string that is sent to the server to be interpreted, which then returns JSON back to the client in a specified format.

Some important features to be noted:

• The first thing to be noted is that GraphQL queries mirror their response. This makes it easy to predict the shape of the data returned by the query as well as to write the query according to the data which we actually need.
• Another important feature is its hierarchical nature. GraphQL naturally follows relationships between objects, where a RESTful service generally requires multiple round-trips.
• It is a strongly typed language. Each level of GraphQL query corresponds to a particular type and each type describes a set of valuable fields.
• The shape of the data which is returned is determined entirely by the client’s query, so servers become simpler and easy to generalize i.e. instead of defining the structure of responses on the server, the flexibility is given to the client.
• GraphQL doesn’t require any specific technology or language. A GraphQL server can be built in any technology , just like a REST server.

Comparison between REST (left) and GraphQL (right)

How GraphQL can challenge the REST:

GraphQL challenges REST. The core idea is that the code that best knows what data is needed for a UI is not on the server but on the client. The UI component knows best what data it wants.

REST delivers all the data a UI might need about a resource and it’s upto the client to go look for the bits it actually needs to show. If that data is not in a resource it already has, the client needs to go off to the server and request more data. What GraphQL does, UI gets exactly the data it needs.

Why REST is not enough:

When we want to build any view in our app that requires a tree of related resources e.g. a feed of shared photos with comments on them, you have to make multiple requests which can be very slow especially when those requests can’t be made in parallel. The code to perform these fetches can also become quite complex. You end up creating custom end points for specific needs of your app, with lot of backend code.

A GraphQL backend has a schema that defines which fields and calls are available for each type of data. This means adding new models or fields becomes a simple task of adding or modifying types in the schema. When a field has been added in the schema it can be queried. A frontend developer can then go and make a change in just the component that actually uses the data and it works. GraphQL makes it possible to build a backend and integrate it with the frontend with much less custom plumbing than before and to make fast changes with less fear of breaking things.

Conclusion:

All this is wild speculation, as we don’t really know enough about GraphQL yet to fully understand its capabilities. It’s quite possible that I’m throwing away some important property of GraphQL away by mapping it to a REST API. Scalability, for instance. Then again, usually my scalability use cases aren’t the same as Facebook’s, so I might not care as long as I get Relay’s benefits to client-side code development.

It’s also possible that it’s actually easier to implement a single GraphQL-based endpoint than to write or adapt a REST API to support these patterns. Who knows.

If you want to explore GraphQL more, get your hands dirty with this :)