If you look up any interviews or posts about GraphQL, the first impression you’ll get is that it’s better than sliced bread. Looking beyond the immediate flaw in that logic – you can’t put ham and cheese on GraphQL – there’s more to the story here.
GraphQL doesn’t answer all problems. It even causes a few. So while there’s a specific reason it’s used, it’s important to remember that if something is made with specificity for one thing, then it inherently might not cover others.
We’re not pointing out the negatives for the sake of being contradictory. We just wrote a blog about ways GraphQL is better than REST. Our purpose here is to make sure you look at it with balanced expectations.
So why isn’t it adopted everywhere yet? For the classic reasons: money and risk. Making changes to already-established applications is a huge undertaking unless you’re starting from scratch. And even then, there are other issues when using GraphQL.
In short, will GraphQL replace REST? Here are a few reasons why it won’t.
Caching is the storage of data. It’s there so that future data requests can be retrieved quickly. Caching is built into in the HTTP specification which RESTful APIs are able to leverage. GraphQL APIs aren’t.
With REST, you access resources with URLs, and then cache on a resource level because you have the resource URL as identifier.
In GraphQL this gets tricky, as each query can be different even though it operates on the same entity.
For instance, in one query you might be interested in an artist’s name. In the next query you might want to get the artists' tracks and release dates. This is the point where caching gets complex. It requires field-level caching, which isn't easy to achieve with GraphQL and its single-endpoint nature. [LINK ABOUT GQL ENDPOINTS]
That said, the GraphQL community recognizes this and continues to make efforts towards easier caching. Libraries have been developed within the community to help with similar scenarios. It still doesn't completely cover things like browser and mobile caching, but like everything else with GraphQL, it’s still developing.
Too much from complex queries
One of GraphQL’s main attributes is that you can get the specific information you need in one query. It’s a big deal. But if you ask for a lot in that one request, you can receive way more data than you counted on. Once a query hits a certain level of complexity it could have detrimental effects on the application. REST might take a lot of calls in this situation to get the data you need, but they’re all finite. A few big queries with GraphQL, on the other hand, will turn into an avalanche of data.
For instance, say a user calls for a list of all the reviews of all the restaurants in Boston. Simple request. But this query could potentially get tens of thousands of rows of data in response.
As good as it is that users can request whatever they need, requests like this can slow down performance and kill the efficiency of GraphQL applications. Some may ask “Is GraphQL safe?” But that’s not what we’re bringing into question. Although in situations like this it can be a little risky.
For complex queries, a REST API might be easier to design because you can have several endpoints for specific needs, and for each endpoint, you can define specific queries to retrieve the data in an efficient way.
Speaking of secure, at baseline GraphQL is still a little tricky. Standards are still in development for universal use. With such a flexible language and no standards in place, things can get out of hand fast if you don’t proceed with caution. See above about complex queries.
In addition, without protocols in place, there may be different naming conventions among API providers. With great flexibility, you lose consistency. This may well change as time goes on, but for now it’s still important to know.
Learning a new query style
This is more for those people who have been completely immersed in REST for years: GraphQL lingo might take a while to understand. While offering convenience, understanding and implementing simple GraphQL queries can burn valuable time. Be prepared to need a lot of pre-development education like learning the Schema Definition Language. Not every project has the time and resources to get properly acquainted with GraphQL, so they may go for REST as it offers less complexity.
GraphQL is great, but don’t count REST out yet. It was awesome when they invented it, and it’s still awesome now. The times where GraphQL can be used – which are adding up every day – make it super useful. But considering GraphQL vs REST should be an exercise on a case-by-case basis.