Yelp Opens an API Based on GraphQL

It’s only been four months since Yelp software engineer Tomer Elmalem first began playing with the GraphQL API query language, and despite that short amount of time, the company pulled back the curtains on its new GraphQL API Wednesday.
The new API takes advantage of the GraphQL Python library to implement a new query layer inside of Yelp’s data architecture. Elmalem said that the effort was undertaken because GraphQL makes it easier to access data that is stored across many RESTful APIs and systems inside Yelp, without requiring users to write separate queries for each individual system.
“When I started looking into it, it seemed like it would solve a lot of problems we had around APIs. With GraphQL, you get exactly what you ask for. You make a query and request specific data. We have a lot of requests to add data to all kinds of different endpoints. From a maintenance perspective and design perspective, it’s hard when our data is all over the place. Building with GraphQL would give people the flexibility to do whatever they want,” said Elmalem.
The speed with which Elmalem went from experimenting to rolling GraphQL out to production is both a factor of Yelp’s internal engineering culture, and of GraphQL’s ease of use. “Our culture is heavy on being able to iterate quickly and pushing to production. We don’t like developers being blocked on process, but the GraphQL design itself made it easy for us to drop it in. It fits nicely with what we want to do,” he said.
Internally, Yelp already uses Swagger but does not expose those assets to external developers. “We use Swagger a lot internally, but this will be side-by-side with our regular API for the time being. I tried to go pretty close to feature parity with the regular API. The only thing I didn’t bring over was our auto-complete support. It didn’t seem like GraphQL was going to be the best fit for that,” said Elmalem, referencing the need for responsiveness in auto-complete usage on mobile devices.
Elmalem said that his favorite part of GraphQL is “How reusable it is.”
“It was nice. I was able to define a couple queries and reuse the schemas in both of those,” he said. “It was harder in the rest APIs. We tried to create reusability on the response side, but that was still kind of hard.”
Elmalem said that he does expect it to take time for people to fully realize the potential of GraphQL. “I think people will probably not realize the full potential of GraphQL up front. That will take some time to adjust to, because of the learning curve around it. Making a query is easy, but using fragments and sending multiple queries at a time might take time for some people to adjust to.”
As for the current GraphQL ecosystem, Elmalem said that the Python library is now on par with the JavaScript GraphQL libraries. He said that he would like to see some query whitelisting features added in the future, but that for now, those features are not necessary for his implementation.
His advice for new GraphQL users? “Building schemas takes a little bit of thought. You want to make sure the schemas make sense for as much reusability as possible. The underlying data model matters. For us, it meant adding a bunch of bulk endpoints to replace endpoints that could only produce one request at a time.”
Feature image by Igor Ovsyannykov via Unsplash.