It's really validating to see Yelp putting a GraphQL API out there as there were a number of questions on whether or not GraphQL made sense as we approached introducing a new API. We (Kiva) also just released our own GraphQL API, though very much in "Beta" it is available at https://api.kivaws.org/graphql with some general API info at https://build.kiva.org
We're still working on documentation among other things before further publicizing it. Hope to take lessons from Yelp and others on best practices with it.
I'm not going to lie, this is the first time I've heard of Kiva. Can you talk about some of the reasons why you chose GraphQL and what some of the technical problems that you've solved that were drastically easier in GraphQL vs REST? I'm trying to decide if it's worthwhile internally to consider a GraphQL API build out, but I'd like to get others perspectives on some of the problems that have been significantly easier to solve, and what was surprisingly more difficult.
There's nothing that you can do with a RESTful api that can't be done with GraphQL. If you wanted to you could build a RESTful GraphQL api -- we did this at my previous company.
GraphQL allows you to do things though like query for nested data structures without making round trips, require typed arguments for queries, and pass arguments to specific fields, things that would take a bit of doing with a non-GraphQL api.
It's certainly not perfect, for example I at least have found query tuning for large nested queries to be a bit more complicated than I'd like it to be, but overall I've had a really positive experience with it and unless I have a good reason not to will be using it for any apis I'm building going forward.
"There's nothing that you can do with a RESTful api that can't be done with GraphQL"
We discussed GraphQL internally, and came to the conclusion that it mostly makes sense as a performance optimization, which was its original use case, and not as an "alternative" to REST APIs.
Drawbacks:
- you loose the ability to easily cache
- your API is more strongly coupled to your data model, which makes evolving it more difficult
So GraphQL makes sense when
- data size / performance is key
- the app is mature and the data model doesn't change very much
We have struggled from performance perspective because we have a relational database at the back. GraphQL has been limited our overall use of JOINS which means multiple queries to fetch data for different data which could've been fetched in a single JOIN query.
If your database is PostgreSQL (which it should be :P) then https://subzero.cloud might solve that for you. Each GraphQL request is translated to a single database query.
The other non-obvious thing is it has been easier to introduce people to use, especially newer programmers. Being able to walk through examples in the browser, all on the same endpoint, just makes it a lot easier for sharing the concept of getting data. Though it may speak to the fact that our audience is primarily people seeking data, not trying to perform actions.
Much appreciated! And the other users comment was super helpful!
I wonder if there would be any interest(or even feasibility) in implementing a REST api data explorer that wraps the REST Api into a GraphQL endpoint so you can have similar discoverability without having to rewrite your entire back end.
We're still working on documentation among other things before further publicizing it. Hope to take lessons from Yelp and others on best practices with it.