ReST vs GraphQL an invalid comparison

History

The original ReST idea, which is supposedly spelled out in the abbreviation, gets lost in the abbreviation.

It was simple, transfer a typically full representation of the state of your data in its entirety to every system that needs it to enable loose coupling and stateless distributed processing.

The idea behind ReST was perverted for the same reason that “Object Oriented” was perverted from the original meaning that Alan Kay, the creator of the term, used it for.

“I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind” -- Alan Kay, OOPSLA '97

People just did not understand that it was just that simple and wanted to make it more complex, or they realized it was that simple, but it was more complex to implement so they just decided to say it meant something else. What is now known as OOPy.

Inevitable Perversions

ReST became RPC over HTTP with JSON as the line format but using more than POST for extra steps. Throw in misusing PUT/POST and embedding versioning into the identifier as hold my beer extra points.

GraphQL is a reaction to so many people getting ReST so wrong for so many years. It is understandable, but I think that GraphQL had good intentions but did not learn from any of the REST mistakes in communication of the idea.

People getting microservices and ReST wrong at the same time and making way too many calls because they got the granularity of the calls and the data modeling wrong. Domain Driven Design and Behavior Driven Development are two of the most important reasons that microservices granularity is wrong, because both of those things were flawed, misinterpreted ideas and became more consultant dogma for billing hours than ideas for flexible approaches.

The idea behind GraphQL is sound for some solutions, the misinterpretation and implementation of it as a general query language for public api consumption is the problem. It is basically the flip side of the ReST/Microservice problem. It is the pendulum swung too far the other direction. Naïve implementations are no better than letting every end user submit adhoc SQL to an RDBMS.

History Ignored is History Repeated

In practice GraphQL seems to be a not invented here syndrome implementation of OData. Maybe they created it without knowing about OData?

OData was a reaction to address the same things that GraphQL was supposed to and does it in a fairly declarative fashion. GraphQL is the Facebook “not invented here” imperative version of OData.

I think that a combination of OData being an “extension” specification for RESTful paradigm, and more importantly, philosophical and/or political reasons for people picking GraphQL over OData or vice versa when they evaluate a protocol for their service.

It is more important to know what both of them do not support or at least make supporting extremely difficult than what they are supposed to do. I find fault with both specifications for many of the same reasons, they include too much kitchen sink functionality as “MUST” type behavior, they leave too much behavior as ambiguous to the point that implementations are not compatible.

Bad Idea in the 1990s.

We did this in the 1990s before the internet with server side “dynamic SQL” generation and ORMs. It was a bad idea then and a worse idea by the early 2000s when the Internet became ubiquitous.

My experience reading “in the wild” accounts of implementations and at my employer was that GraphQL was implemented by inexperienced developers as a naive way to just let the “front end” ask for what they wanted in an adhoc manner instead of providing a way to narrow down or expand the Representation of the data they were requesting as needed.

At my employer, this caused complete chaos for the “legacy RDBMS” teams when applications were generating ad-hoc SQL that was far from optimized, grinding the servers to a halt with a single call from a single client, and in a few cases crashing the server down to the OS level repeatedly.

In a couple of these cases, I had argued against it just for this very reason, and like Cassandra, was ignored. The reason was “the UI” will restrict what is requested. Nobody told the developers writing the UI this and they put selections that contradicted each other or created what were effectively cartesian joins from recursion. When asked why this did not come up in testing, they admitted there were so many fields that could be combined in so many permutations that there was no way to test it in a person's lifetime.

Incompetent People misusing things

Incompetent people misusing things and not being able to read for comprehension is not a reflection on ReST or GraphQL as good or bad.

ReST and GraphQL can both be done correctly. Understanding how not to do ReST or GraphQL is probably more important, since every other way is correct, even if not the most correct.

GraphQL leans into the community that did ReST as RPC with extra steps with JSON and POST/PUT wrong with a single endpoint and RPC semantics. This allowed an immediate comprehension, even if it is naive and at the expense of GraphQL being misinterpreted the same way the theory behind REST was.

Rearranging Deck Chairs

The initial implementation of GraphQL servers was to act as a facade over existing RESTful microservices which did nothing to alleviate the “too many calls at the wrong granularity” level problem, it only moved aggregation of them to the server side network.

It also made these implementations “reference” implementations by default, which misrepresented the correct implementation of GraphQL which was to parse the request and only query the data source for all the data that was needed at the same time not requesting the data that was not needed. Many GraphQL servers to this day just use a naive ORM to generate a query that requests all the data from all the entities and then filters out unwanted fields or entities during the serialization process. It just moves the problem to a potentially more expensive location.