Facebook describes GraphQL as "a query language for APIs and a runtime for fulfilling those queries with your existing data." Unlike REST calls where a client asks a REST endpoint for a "thing", GraphQL queries allow the client to specify what it's looking for.
While GraphQL is heavily used within Facebook, it's still early days for the specification in the community. InfoQ sat down with Steve Faulkner, director of engineering at Bustle, to talk about GraphQL, how it's used at Bustle, and what teams looking at GraphQL should consider.
InfoQ: How is GraphQL used at Bustle?
Steve Faulkner: Right now, GraphQL powers all of our production stuff. All of our APIs, all of our back end CMSs, as well as our front end websites, all talk to GraphQL. We have two separate chunks of stack at Bustle. We have the back end CMS stuff, which is internal and custom, and then we have our front end server side rendered Preact app [which] talks to GraphQL as part of that.
InfoQ: What did Bustle switch from?
Faulkner: We were using all kinds of in-house REST stuff. The Rails-style REST conventions was generally how things were. I was actually not a fan of GraphQL at first. I pushed back pretty hard on the people who were trying to bring it into Bustle. I was like, "Well REST is good enough; it does all these things; this GraphQL thing is really complicated; I don't know how it's going to fit in here; I don't want to make our stack more complicated than it has to be".
There's two things that really turned me on to it. Number one was the types. When I first started playing with it and using the types, it helped us solve a lot of communication issues between developers. It wasn't so much a technical thing, it was improving our ability to develop faster. The second one is how quickly our front end people grabbed onto it. We were experimenting with it in production and suddenly we were using it for a ton of stuff, mostly because our developers didn't have to ask anybody. They could say 'Oh I need a new query that's formed a different way. I can just go get it.'
InfoQ: How did the decision to switch happen?
Faulkner: Bustle has a lot of freedom in our engineering team. We trust all our developers to go out and build the things they think need to exist. One of our developers said, 'I think GraphQL is the future', and I think he was right about that. We started playing with it. We have a policy that if we see something cool and we want to play with it, we'll just put it into production and see how it does. We have small chunks of the site that are easy for us to play with.
InfoQ: What kind of problems did it solve?
Faulkner: The biggest one is the people problem. How do you communicate around changes to APIs, documentation? All that comes with GraphQL out of the box. It's a language for developing APIs that is much stricter than REST. It forces you into better patterns, but it also allows the documentation to be auto-generated. The API explorer (GraphiQL) that's included out of the box all works automatically. It removes all these not hard problems, but they're things people have to spend time doing. And when you eliminate them, it allows you to develop faster.
InfoQ: What kinds of questions should teams ask themselves if they're considering switching to GraphQL?
Faulkner: I think there's some deficiencies [with GraphQL], especially around securing and operating GraphQL in production; query complexity, authorization, authentication. We solved some of those ourselves, but they're not solved in a community-wide sense yet. I think people should be concerned about that. If you're a bank and want to do a GraphQL endpoint, you should really think hard about "what extra steps do we need to take in order to really make this production-grade?"
Faulkner gave a presentation at QCon London 2017 on how Bustle uses serverless to power their back end.