<sigh>

I grow so weary seeing these paeans to GraphQL claiming it is some kind of panacea and that REST is yesterdays news. Why? Why? Because they gloss over the fact that REST and GraphQL are really best for different use-cases.

So these "GraphQL is the future!" are tiring and tedious. Use the right tool for the job.

It makes me wonder if the authors of these types of posts actually understand REST, its history and what it was designed for or if they really only speaking from their own limited experience of having tried to write clients for both of them and found one easier to work with? That is a lot like blind men arguing over the nature of an elephant.

But since I don't want to be critical of someone I've never met and only read one article from, let me instead suggest they study more about REST before proliferating untruths unintentionally:

• REST Architectural Constraints
• Representational State Transfer

Saying "GraphQL is better than REST" is like saying an SUV is better than a bullet train simply because you get to control the SUV and you can go more places with an SUV than a bullet train. Though the latter parts of that statement would be correct the assertion that that makes an SUV "better" completely ignore the benefits of the bullet train and the respective trade-offs of choosing an SUV.

Absolutely, an SUV has its use-cases where it is better than a bullet train. But where a bullet train shines, an SUV cannot compete.

GraphQL use is highly coupled between client and server and when building bespoke mobile apps that is an acceptable tradeoff given its benefits. This is fine if your API is proprietary and/or don't expect your API to live more than a few years. Then you can gain the benefits of smaller and more exact payloads.

But REST, with its hypermedia constraint in tact, was designed to be robust and workable over decades. It was designed to decouple the client from the server as much as possible, and allow clients to interact with servers without having the client developer coordinate with the server developer, or coordinate as little as possible.

So to say the GraphQL replaces the need for REST is a gross misunderstanding of why REST is here to stay. After all, REST was merely a codification of the architecture of the web after the fact, albeit REST APIs need to adhere to more constraint than the we at large.

For those of you who read the post I am commenting on, or similar posts, and are tempted to think "Wow, REST is stupid and GraphQL is a panacea!" do yourself a favor and read these articles which provide a more balanced view of REST vs. GraphQL:

• Advantages and Disadvantages of GraphQL
• GraphQL vs REST: Overview
• REST vs. GraphQL: A Critical Review
• REST vs GraphQL APIs, the Good, the Bad, the Ugly

We here at moesif, an API analytics company, are seeing a sharp uptake of GraphQL APIs.

Although, right tool for the right job still applies. GraphQL works better in some situations, RESTful works better in others.

Good one Leonardo Maldonado, Waiting for next tutorial.

Great article! 👍

It is safe to use GraphQL for internal use cases, like your internal apps or parts of a bigger picture. You expose your data only to “trusted” developers. But to expose your critical data and DB schemes outside can be dangerous, ideas can be easily stolen.

That's a good article! Well, like any other technologies out there, GraphQL has downsides too. At-least from what I've experienced while building one.

Now, time for perspectives.

From the Frontend developer standpoint: I love GraphQL as a Frontend Developer. There's nothing like it, Period. So far with every frontend dev I've interacted with, either loves GraphQL or isn't aware of it. There is no in between. Why? First, underfetching irritates client developers. And, when the backend dev asks them to make one more API call to get the required data/state, they almost curse that backend dev. Second, API docs. We all have been there.

From the Backend developer standpoint: The amount of bloatware that it ends up in the Controller layer is just ridiculous. If you use NodeJS(JS) + MongoDB, you wouldn't feel much (loosely typed + json) but if you use strictly-typed languages like Java, it would be an ocean of bloated classes. And upon that, if you use MySQL database, god save you. You'd have to follow any of the GraphQL design pattern and stick to it carefully.

Introducing either Access Management or showing fields based on Persona forces us to do a redefine things in Controller layer. The access definitions which you build in the business logic layer will have to be replicated in the form of Fragments in GraphQL. It can be done but..

In the verge of writing a generic code to provide hassle-free endpoints, we end-up compromising particular API based DB/Cache Query optimisations. Particularly in SQL-based DBs, The indication for invoking a procedure/view over a generalised Prepared Query statement is blurred out, again, unless you follow the design.

From the REST Performance standpoint, HTTP/3 - Quic is coming up. Network bandwidth allocation from the Browser Client to a target happens only once even though you make 10s of request to the same target. So it removes a greater amount of overhead.

Let's suppose, GraphQL comes up with provisions for all the above scenarios, yet we might find it difficult for Enterprises adopting GraphQL as their primary backend API interface. And Why is that? because the innovation in the Web ecosystem is very rapid. That's not the problem. It's the deprecation of the same innovation happens very rapid too -- And Backend ecosystem is not used to this because it prefers stability even its legacy. That's probably one of the reasons why Java is still active in the market.

And if you say Facebook or Github uses it -- they needed an easy interface for their developer API integrations. Infact, Github mentions it in one of their posts. All the other adopters so far, use it for the same purpose. Ease of Integration.

I can go on like this but its not that I want to bi*ch about GraphQL or I'm taking support for REST over GraphQL. The point I'm trying to make is -- GraphQL is a really solid concept and it overcomes the problems that exist in REST by costing to something else, probably because its in an infant stage. Too many REST endpoints aren't manageable either. I hope it evolves to a greater extent so that it blurs out a markup between Web client and backend API layer.

Please correct me in case I've pointed out something wrong, I'd be happy to discuss. Cheers!

Nice one. Waiting for the next!