Why Bustle Switched Their API to GraphQL

Facebook’s baby GraphQL is the hot new thing in APIs promising to topple REST from its perch. But how does a newbie go about using it and what for? And why might you not want to use it? David Iffland over at InfoQ sat down with Steve Faulkner, director of engineering at Bustle, to talk about how they adopted GraphQL and why.

First things first. What does Bustle use GraphQL for? Steve explains that it powers all its APIs, its CMS as well as its frontend interfaces. The frontend talks to GraphQL via a Preact app that powers its frontend. 

Before, the team had a Rails backend with public and internal apps interfacing via REST and Steve was reluctant to change things, not being a great fan of GraphQL. He liked the simplicity of REST in comparison with GraphQL. Two things changed his mind: the presence of types, which helped resolve communication issues between developers, and the fact that the front-end guys immediately jumped on it and started using it wherever they could. 

This freedom GraphQL gave the development team convinced Steve to more or less abandon REST. The major problem it solved was the developer communication problem; specifically, how do you communicate changes to APIs and docs? GraphQL’s advantage over REST is that it’s much stricter, which means developers are forced into good patterns and docs can be auto-generated. The GraphiQL API explorer also automates many of the tedious tasks developers usually have to perform when creating APIs. 

Steve cautions, though, that GraphQL isn’t perfect. There are issues around securing and operating it in production environments, while queries can become complex and authentication tricky. Bustle found its own solution to these problems but there’s no community standard at present. 

Original Article

Switching to GraphQL at Bustle



Luca Mattia-Ferrari

if developed correctly or with the right tool, documentation for REST service can be autogenerated as well. I still see some pain points for GRAPHQL around authentication (with REST you have a section specifically dedicated to it and a lot of granularity if coupled with OAuth or OIDC) and separation of concerns. I don't think there will be a winner necessarily between REST and GRAPHQL, they can have different field of application.