Facebook recently open-sourced the language that powers hundreds of billions API calls a day enabling forming a community around it at graphql.org.
A GraphQL query is a string that is sent to the server irrespective of the complexity of the data schema. The server responds in JSON. GraphQL is strongly typed, avoids versioning and provides ability to evolve the query easily with evolving data.
InfoQ caught up with Lee Byron, a developer at Facebook and one of the original contributors to GraphQL.
InfoQ: GraphQL has been around for a few years. Can you briefly mention the history and how Facebook’s foray into mobile computing led to GraphQL?
Lee Byron: Facebook's origins as a website are deeply embedded into our original technical architecture. Up until 2012, News Feed could only be requested and delivered as HTML from our servers. During the effort to rebuild News Feed as a native iOS view we had to revisit this architecture to get raw data.
We started with a system that looked a lot like a traditional RESTful server but found it difficult to use as iOS developers, and saw conflict between our desire to load all information in a single round trip while keeping our REST resources well isolated.
In particular News Feed stories that are shares or aggregations of other News Feed stories (which themselves could be shares or aggregations of other News Feed stories) forced us to confront this issue and led us to rethink how we request data.
Ultimately these simultaneous efforts of figuring out how the raw data of News Feed should be shaped and determining the best way to request data over mobile networks led us to GraphQL.
InfoQ: Data is intrinsically hierarchical and is a graph of relationships. Is the central goal of GraphQL to express this graphical relationship? What are the other tenets of the language?
Lee Byron: We certainly found it strange that our app server code treated data as objects and relationships which it flattened to a tabular representation only to later be turned back into objects and relationships by mobile client code. An early motivation for GraphQL was to expose the server's data as clear and easy to use.
GraphQL has a few other important tenets. It's designed to fulfill the requirements of product views and the developers who build them rather than modeling some database or transport semantic. This helps make GraphQL easy to learn and use, but it also abstracts away any particular database or transport allowing it to be used in a myriad of ways. It's also strongly and statically typed which helps encourage discipline around information design, and supports a lot of interesting tools like error checking, IDE integration, and code generation.
InfoQ: Does data format on the server or the data storage on the server have any impact on GraphQL?
Lee Byron: It does not. GraphQL rarely interfaces directly to a data storage engine like MySQL or Redis, instead GraphQL interfaces with your existing application code. You can think of GraphQL as a sort of nested RPC for calling functions on your app server.
InfoQ: You talk about unashamedly being product centric to help UI developers? Is REST and JSON still relevant and how would this appeal to middleware developers who don’t care about UIs?
Lee Byron: I think being product centric helps a lot more than just UI developers. GraphQL has been a really powerful force for clarity within server code at Facebook. JSON is definitely still relevant and is the primary transport for GraphQL. GraphQL has replaced using REST at Facebook for building our products, however REST remains a useful tool for providing public APIs.
InfoQ: What is the GraphQL server? Can you elaborate on the strong typing and roadmap for GraphQL. What is missing today?
Lee Byron: The GraphQL server is a relatively small bit of code; it's responsible for a few things. It provides utilities for defining your type system and how it interfaces with your server code. It accepts GraphQL queries and will validate that they can be safely and unambiguously run within your type system. Then of course it executes the query by calling into your code as you defined within your type system while handling things like asynchronicity, parallelism, and error catching for you.
The roadmap ahead is two-fold. First, better tools for client developers for doing things like code generation and query management. Relay is our primary and most significant tool for the client. Second, better support for streaming and pushed data within GraphQL. We've been exploring these areas at Facebook and are excited to share our successful experiments in the future.
InfoQ: Apart from Facebook, can you mention a few companies that are already using GraphQL and how robust is the community? What is Nuclide? What other tools should developers pay attention to?
Lee Byron: GraphQL is still a nascent technology. We released a preview of GraphQL only a few months ago and since then we've already seen a lot of interest from companies big and small. Red Badger, a consultancy based in the UK, has been using GraphQL while building the Financial Times applications. Reindex.io is a new company providing GraphQL as a service. The community isn't just using GraphQL, but building it too. We released a version of GraphQL for JavaScript a couple months ago and since then community members have built versions of GraphQL for Ruby, Java, Scala, Go, .NET, and Python. I'm pretty thrilled with the progress in such a short amount of time.
Nuclide is Facebook's IDE developed with React Native in mind built using Github's Atom editor. React, Relay, and React Native are all really interesting tools that offer fresh perspective on product engineering. DataLoader is another tool we just recently published which captures a pattern we've used at Facebook for years and has helped us build efficient GraphQL servers.
The documentation includes how to get started.
