Top Ten GraphQL Myths Debunked
There are a lot of myths out there (flying horse, anyone?). There’s even myths about GraphQL, which can lead to misunderstandings around it’s use cases, and even at times unwarranted fears over it’s usage. Let’s take a look at the top 10 most common GraphQL myths and see if we can’t assuage some worries and shed some light on the truth.
Myth #1: GraphQL is a query language for graph databases
Reality: GraphQL is a query language for your API
This is one of the most common misconceptions about GraphQL, and understandably so! I mean – GraphQL. Graph + (S)QL. Graph Query Language. One can see the confusion here. It sure sounds like the kind of name you’d give to a query language for a graph database. The reality is that this is simply a way to send queries to your API for data retrieval and modification.
Myth #2: GraphQL requires you to use a graph database
Reality: GraphQL is data layer agnostic
Another one that is undoubtedly connected to the admittedly confusing name, this myth is equally unfounded (and common). GraphQL not only does not need a graph database for you to use it, but it actually can be used with any underlying data-layer (or combination thereof), including but not limited to:
- REST
- SOAP
- SQL databases
- NoSQL databases
- Static data files
- Serverless
- Your custom in-house standard
- etc.
Myth #3: GraphQL is (better/worse) than REST
Reality: GraphQL and REST are different tools with real pros and cons
No, REST is not “dead”, as some proclaim. GraphQL and REST tackle the problem of exposing data through an API in fundamentally different ways, but this in no way makes one inherently better or worse than the other. In fact, the two can oftentimes be used together to create a truly powerful solution.
Myth #4: If you use GraphQL, Facebook owns your code
Reality: Facebook doesn’t own your code (seriously)
This myth actually used to be a real concern. Facebook originally created GraphQL, and when they first open-sourced it, there were concerns about the terms of the license, but these have since been rectified by re-licensing it under OWFa v1.0 and later moving the GraphQL spec into it’s own foundation.
Myth #5: GraphQL exposes my whole database
Reality: GraphQL gives you full and fine-grained control over what you expose (and how you expose it)
This myth is certainly helped by the number of libraries out there for generating GraphQL APIs based on your database, but this is neither GraphQL itself nor something I would recommend for 99.99% of use-cases (translation: please please please don’t generate an API that you plan to expose to the world from your database schema). In the same way that a REST-like API gives you the power to decide what data to expose through your API, GraphQL requires you to make informed decisions about precisely what you expose.
Myth #6: GraphQL queries are complex (like SQL)
Reality: GraphQL queries are much simpler than SQL
This one couldn’t be further from the truth. SQL is notoriously complex (albeit very powerful), but it’s a fundamentally different tool than GraphQL. Feast your eyes on the simplicity of the following GraphQL query:
{
currentUser {
firstName
lastName
email
}
This query asks for the currently logged in user’s firstName, lastName, and email. That wasn’t so scary or hard to understand, was it?
Myth #7: GraphQL doesn’t scale
Reality: Some of largest companies in the world are using GraphQL at massive scale
As previously noted under #4, Facebook is the company who originally created GraphQL, and they’ve been using it since 2012 to power Facebook mobile, and today it serves most or all of their traffic from mobile and desktop. It’s not just Facebook though – many others have been using it at scale to great success such as The New York Times, Nike, and Intuit.
Myth #8: Caching is not possible with GraphQL
Reality: Caching is quite simple, with the notable exception of HTTP caching (explanation below)
GraphQL sometimes gets a bad rap because of caching, but this is mostly a misunderstanding. There are many different kinds of caching, and different points at which they happen in the lifecycle of a request. There is no reason why you can’t do caching at the resolver or data-access layer, for example. Things do get a bit more complex when it comes to HTTP caching, but it’s still possible to do. In any case, the performance gains that come from a single HTTP call with GraphQL vs multiple round-trip calls with REST-like APIs almost always offset any lack of HTTP caching that may come with GraphQL.
Myth #9: GraphQL is only for startups
Reality: GraphQL is uniquely positioned to help the enterprise solve it’s data-access problems
Far from being an immature technology, GraphQL has been solving Facebook’s data-access problems since 2012. It has proven to be a powerful tool for discoverability, data integration, automatic API documentation, and clarity of the available data and functionality. Couple this with the view of GraphQL as a facade layer, and you’ve got a technology that was practically tailor-made for the enterprise. Also, see #7 again.
Myth #10: Only front-end developers care about GraphQL
Reality: Back-end developers can benefit greatly from GraphQL
Let’s address the elephant in the room on this one. Per the GraphQL spec:
“GraphQL is unapologetically driven by the requirements of views and the frontâ€end engineers that write them”
(source)
And certainly, as a way to accomplish this, GraphQL shifts complexity from many places (the front-end clients) to a single place (the server), but this does not mean that it’s only good for front-end developers. The architecture of GraphQL allows back-end engineers to build more elegant APIs, iterate on API design and release new features more quickly, and throw versioning out, just to name a few.
Conclusion
There are plenty of misconceptions and myths floating around out there about GraphQL. In this article, we’ve addressed 10 of the most common in the hopes that it will help clarify the reality to those who have perhaps misunderstood something about it.