The Fallacy of GraphQL

In The Beginning…

History tends to repeat itself. And the question is, of course, can we learn from it?

Now, that might be interesting, but totally unrelated to Software, right? Wrong!

It’s quite easy to see that trends in the software industry tend to repeat, and that they come in waves. Every time we, the developers, have great reasons for this repeat, and we can always explain why the current trend, which is the exact trend we abandoned a few years ago, is the best we can get.

Let’s look, for example, at the desktops.

Desktop History Trends

Desktop Trends

In the beginning, all the power lied in a big, noisy, formidable computers (no one called them “Servers” back then). The way to communicate with this monstrosity was using a terminal, that was used solely for the purpose of sending data to the central computer, and displaying its output. No logic whatsoever. (Hence the “dumb” terminal).

A few years later, and the PC was born. Suddenly the end user had a (relatively) lot of power under his hands. Games, spreadsheets, word processors – they were all right here, in front of everyone. The computers were no more “dumb”, they were everything we needed! Rich clients where everywhere, and the only use for Servers was for central, huge (again, relatively…) databases.

 

And then came The Internet.

And we were immediately hooked.

Our world was changed once again, and suddenly web browsers were all the rage. Netscape was valued at 2.9$ Billion (that’s a B, right?) on its first IPO day, and sold for 10$ Billion to AOL, 4 years later. It was later demolished by IE, which, in turn, was destroyed by Google Chrome.

Those happy days saw websites that where little more than glorified text books. Almost no logic was executed on the browser side (aside from some validation), and everything was done on the Web Servers. We were back at square one, but instead of Dumb Terminal, we now called it Thin Client.

Enter jQuery.

What now is viewed as an outdated, limited, and, mainly, unfashionable JavaScript framework, showed us all how strong JavaScript is, and how useful it is in the browser. Couple it to the more advanced and powerful browsers, and suddenly – we’re having Single Page Application all around us. Modern frameworks such as Angular, React & Vue.js allow us to execute much of the logic on the client side, and the role of the server side focuses mainly on retrieving and storing data.

Which was exactly the way we used our computers in the VB6 heydays.

So, yes.

History DOES tend to repeat itself.

GraphQL – We’ve Been Here Before

What all this has to do with GraphQL?

Good question.

The concept behind GraphQL is nothing new. We had it for years, and we despised it. A lot. Actually, we hated it so much we invented a new concept which was much easier to use, much simpler to understand, and with virtually no entry barrier. What was the name of this new concept? REST. And what was the name of the old, outdated concept it replaced? SOAP.

Yep, that’s true.

Let’s take a short trip down memory lane.

SOAP (Simple Object Access Protocol) was introduced in 2003 (actually, it was introduced in 1998, but became a standard in 2003) as a standardized way to communicate between web services across the internet, in a platform agnostic way, using XML.

SOAP services communicated with each other using proprietary message format, which contained the method name to be executed.

The server, after receiving the message, had to parse the message, and execute the method indicated in the message.

Here is an example of a SOAP request message:

SOAP Sample

(From https://en.wikipedia.org/wiki/SOAP)

SOAP was incredibly popular back then, but, as its usage soared, its drawbacks became more and more apparent:

  1. SOAP is an extremely verbose protocol, and requires special libraries for creating and parting the message. This became especially painful in light of the proliferation of the various JavaScript frameworks, that had a hard time handling SOAP.
  2. Because its verbosity, SOAP was extremely inefficient network wise. In tight bandwidths, its bloated XML-based format became a real nuisance.
  3. It was complicated. There are so many hidden attributes and settings, that in order to take advantage of its full potential, one has to be a real master of the SOAP opera.

The world realized it, and came with a brilliant solution: REST!

REST was, and is, a great solution to all of the above problems: It’s lightweight, standards-based, and you can’t get easier-than-that to learn and use.

Everything was good.

Until someone decided it’s not. And came up with SOAP v2, AKA GraphQL.

GraphQL is the reincarnation of SOAP, only in a fashionable, facebook-powered disguise.

Don’t believe me? Take a look:

  SOAP GraphQL REST
Proprietary Protocol YES YES NO
Server-Side parsing required YES YES NO
Needs to declare required output YES YES NO
Needs to specify the function name to be executed YES YES NO

 

So yes, GraphQL definitely offers added value over SOAP, mainly around its JSON return value and the flexibility in its output. All of these can be implemented easily with REST (OData anyone?)

So what do we have here?

A shiny new guy in the block, bringing back distant memories of proprietary protocols and function names, and aims to replace the clean, minimalist, oh-so-simple-to-use REST.

Now, I’ve seen my fair share of overhyped trends in the software world, but for the life of me, I just can’t figure out what’s the story of GraphQL.

Help!

 

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.