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
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.
Which was exactly the way we used our computers in the VB6 heydays.
History DOES tend to repeat itself.
GraphQL – We’ve Been Here Before
What all this has to do with GraphQL?
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 was incredibly popular back then, but, as its usage soared, its drawbacks became more and more apparent:
- Because its verbosity, SOAP was extremely inefficient network wise. In tight bandwidths, its bloated XML-based format became a real nuisance.
- 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:
|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.