GraphQL, the application query language developed by Facebook, is gaining ground in the API landscape at an increasing pace. I’ll try to give a brief summary of some of the reasons why companies of all sizes are looking at GraphQL over RESTful API technologies.
Instead of being borne out of an abstract research project, Facebook designed GraphQL to tackle an imminent and existential threat to their mobile growth strategy. Setting out to deliver a rich, individualized experience to a billion users over mobile connections is bound to expose any shortcomings in your data transport mechanisms. GraphQL specifically eliminates two critical weaknesses typical in RESTful client/server interactions: over-fetching, i.e. receiving fields or records that won’t end up on the screen, and under-fetching, i.e. the need for multiple requests to populate the screen.
GraphQL is a specification and a language. As part of that, you will continously get up-to-date documentation for any GraphQL API. Combined with super-simple mocking tools, this means that your internal server and client teams can quickly agree on the overall data requirements, i.e. schema, before they embark on their respective projects. The client team can code against a mock API from day one instead of the entanglement hell that often plagues RESTful API projects — if you haven’t experienced incomplete or out-of-sync Swagger docs, lucky you! Any new data requirements can be added to to the mock API immediately, isolating the backend team from becoming a bottleneck to client-side innovation.
The value of schema-first development gets further pronounced when you open your APIs to external developers and the apps that they can come up with. It’s incredibly easy to have all of your progress stall because you simply can’t manage communicating and supporting the changes to people you’ll rarely or never meet. With GraphQL, this concern is all but taken off the table.
In the five years since Facebook launched their first apps using a GraphQL API, they’ve released hundreds, if not thousands, of client application versions into the wild. The number of API versions: one. That’s right: FB apps from five years ago still continue to be supported by that same API today, even though the API has evolved by leaps and bounds. Implementing a versionless API strategy does take a bit of proper planning — but the payout is huge.
Apart from the demands of service evolution, GraphQL happens to be a great facading technology. It’s very simple to wrap existing RESTful or RPC APIs behind a GraphQL proxy. In fact this is a very typical way for companies to experiment and get familiar with the benefits of the technology, because it frees you from having to go all-in before you really know how it aligns with your goals.
For sure, GraphQL won’t be the silver bullet to solve every data interchange problem on the planet — and it won’t make your existing REST API investments obsolete overnight. But it’s picking up steam for a good reason: a good chunk of today’s B2B and B2C applications revolve around richly nested, structured or semi-structured data. This is where an increasing number of companies are finding their sweet spots.