Thank you, Félix. I’m certainly glad that GraphQL is working for you in your specific circumstances, and I have absolutely seen a lack of design and implementation consistency and empathy for front-end application developers in many custom REST endpoints that could lead to something like GraphQL being called upon to “fill the gaps”.

Speaking only for myself, I would much prefer to fix the REST endpoints, but I’ve been doing this long enough and in enough different contexts to understand that this isn’t always an option. At then end of the day, we have to make this stuff work, and the perfect should never be allowed to be the enemy of the good.

My real objection, which I may have failed to make clear enough in my original response to the article, was the author’s much-too-broad “Stop Using REST” title and (I believe) unsupported“GraphQL is WAY Better” assertion.

I’m glad you brought up the question of the cost of filtering, assembling, and querying in REST vs GraphQL. This is something I’ve been very curious about and have asked several GraphQL “experts” about. So far, all I’ve gotten is no response (“staring at their shoes”) or more “Hurray! GraphQL!!!” marketing spiel. If you come across a good engineering-based comparison, I would be most grateful if you’d share it.

My gut is that a well-designed RESTful API over a collection of consistently-implemented business entities, processes, and rules, optimized with properly-configured server-side caching could beat the pants off of GraphQL, but I haven’t come up with a good way to prove this yet. One of these days, this might make a good article. ;)

Best regards, Félix, and thanks again for the positive and productive conversation!