[15] – Will GraphQL make REST API paradigm obsolete?

Image Credit: www.shutterstock.com, www.networkworld.com

Please pardon the provocative title. If we want to be dramatic, we can answer the above question as YES. But the answer is NO.

GraphQL will Not make REST programming model obsolete.

However, if you are contented with this answer, you are missing the bigger picture. There are so many technology innovations happening around us right now, that we can ask similar questions

• Will Serverless computing make Virtual Machines Obsolete?
• Will React make Angular or traditional Html way of creating web and mobile apps Obsolete?
• Will DynamoDB NoSQL make RDBMS database like Oracle Obsolete?

Let’s address each of these questions to find out more than just the Yes/No part of answer. For this, lets start with a question that you could have asked in 1908.

Cars v/s Horse carriages

Henry ford introduced the first car Model-T using an assembly line that would be able to mass-produce many cars.

If we were in 1908, we may have been wondering

Will Model-T make Horse carriages Obsolete?

The answer, today also, may be NO, as somewhere in the world, you may still be able to find people using horse carriages as means of transportation (Have you heard about Amish communities?)

But that is misleading answer. More important point is, the invention of Model-T using assembly line was such a revolutionary one that over the next few decades, it become the primary means of transportations.

Now if you were a lay man, you may or may not have understood the potential of this invention and it would have been fine as you may have started taking notice eventually.

But if you were somehow related to Horse carriage industry, it meant, your earning prospects were in perennial decline. Right. Even if you did not notice changes immediately, the trend accelerated in coming years and overtime, it became exponential.

So, bottom line is, when revolutionary inventions happen, it behooves us to stand up and take notice

Mainframes v/s Open systems

Let’s come a few decades forward and in 1980’s, most of so-called IT Systems were Mainframe computers. These required big hardware and slow components to do the processing.

During these time, Open systems were invented. This consisted of systems that were smaller in size in terms of hardware and smarter and more efficient in their operations. There were also improvements in software side of things with better operating systems and programming languages. We could have asked similar question

Will Open systems make Mainframes obsolete?

Now you know the answer and get the gist.  We also know how the story unfolded. There was an Open system revolution (with Unix/Solaris and Java/Perl/Php etc.) and slowly all enterprise IT systems started getting replaced from Mainframes to Open systems.

Today also, you can find Mainframes that are being used as System of Record in many places. But they are considered Legacy systems and are the burden that enterprises carry since they are harder or impossible to replace.

Just a month back, I was introduced, by our HR, to a mainframe programmer we recruited in our company for a maintenance project. So, unlike Dodo, they are still existent. But if you asked him how his job prospects are from last few decades, you can see a frown on his face.  If you ask him his salary increments in last few decades, you would see a bigger frown on his face.

So bottom line is, revolutionary inventions not just impact companies, they also impact us individuals. Hence it is good to always have a pulse of what is changing and where are things going.

Serverless computing v/s Virtual machines

If you have not been living under the rock in last few years, you would have seen that Compute is moving from on-premise data centers to Cloud.

This is a trend that will accelerate as we go forward and is a good step in right direction if you are a company that is not in the business of maintaining data centers but are doing as a by-product of having big IT usage.

However, an even revolutionary invention happened when AWS announced Lambda 2015. This led to advent of what is now loosely called Serverless computing.

This is the best case of pay exactly for what you use, as with Lambda, you are charged for Compute in increments of 0.1 second of your code execution.

Hence if someone visits your website and it requires 3.4 seconds of processing to serve him the web page, you will be charged only for that as far as compute is concerned.

This model is still in early stages and it has its Pros and Cons. However, over a period, you will see it take away a large chunk of market share from running VMs in cloud. And why not, some organizations have adopted it and have clocked savings from between 50% to 90%. So, shouldn’t you experiment to see if your use-case fits into the serverless computing paradigm and realize the potential benefits if it does.

Now, there are other nitty-gritty’s about this comparison that you are read it on internet and see and compare both sides of the coin. But it is an invention to take notice.

You are still not convinced. You still think you have this small EC2 VM running with AutoScaling configured and hence your cost of operation is not that much. However, you may soon realize that in order to have High-availability setup, you need 2 VMs running. Further, in order to build zone-failure redundancy, you might spread this 2-VM configuration of yours in 3 zones, making it a total of 6 VMs.

But what if the whole region fails. For example what if us-east-1 region with all its availability zones is down. You might say, well thats a bit of stretch. The whole region cannot go down. Can it. Well you are in luck, because we have an example where AWS S3 service was down for the whole us-east-1 region. And i am not finger pointing on AWS. Such incidents have happened on Microsoft Cloud Platform (Azure) as well as Google Cloud Platform (GCP). So what can be done. Well, you have to architect for Regional redundancy now. Which means 6 x 2 = 12. So there you go, you have a small constellations of 12 VMs now

See how the costs adds up. Also don’t ignore complexity that increases exponentially. Compared to that, Lambda are by design Highly available and you can deploy them in 3 zones without incurring any charges, as you are charged for each execution irrespective of the zone. So, check it out!

React/JavaScript v/s traditional websites

Similar thing is happening at Front-end. The old way of rendering website by doing html processing on server-side and submitting page each time you need to get new data is old school.

Innovations like React have split the front-end into many pieces, each having the ability to get/refresh data when state changes in VirtualDOM and it takes care of making updates to the real DOM.

Hence today’s web and mobile apps are more responsive and do not need to submit webpages to get new data.

Similarly, on programming language front, there was a time when JavaScript was considered language of Nerds and Tin-foil hat wearers. During that time, languages like Java and C-Sharp (C#) were considered Enterprise Language and most of the code was writing in them.

But in last few years, that trend has shifted to using JavaScript/TypeScript as the primary language of programming your websites, mobile apps, APIs etc. It helps because JavaScript can work for both client-side and sever-side programming.

The combination of JavaScript and Node.js has been able to perform better than multi-threaded enterprise languages.

 Recently in China during the Singles day (which is equivalent to Black Friday in US), Alibaba sold goods worth of 1 Billion dollars in first 5 minutes on their website. And guess which stack the website is programmed in? Of course, JavaScript + Node.js

So, you can see a shift happening here also.

What about Database space?

DynamoDB v/s traditional RDBMS

Here DynamoDB represents example of a NoSQL database. So, the question is, Is anyone using NoSQL databases in enterprise?

If you see in recent years, polyglot persistence (using different database for different use case) has gained traction on its own and in programming Micro-services. Gone are the days where everything is retrofitted to make use of Enterprise RDBMS like Oracle whether it works or not.

Why not. There are benefits in terms of Cost, Performance, Maintenance and every other aspect of using a Database. But you are still doubtful if you require NoSQL DB for your use case. Let me try to persuade you a little.

Amazon.com website uses DynamoDB for 90% of its operations.

Now if your use case is more complex than Amazon.com, you have a valid point that it entails a deeper discussion. But if not, try to see how you can serve your customers better by breaking out of the mold of RDBMS.

On the other end of spectrum, you might say, your use case is not that big as Amazon or complex enough to justify going for web scale databases like DynamoDB. Fine. But keep an open mind and do take a look at it and see if it is useful in any way.

Also, DynamoDB, when used properly, has capacity to execute query in single-digit millisecond. Now, isn’t that Fast?

Even more compelling innovation is Aurora Serverless. This is another pay exactly what you use type of invention. No more charges of keeping database services running in multiple regions 24×7, waiting for users to come. It will charge you per transaction execution. No more no less.

It is still in the early stages but again this is going to be a game changer. When was the last time you got pay-per-execution on Database layer? NEVER. Correct.

GraphQL v/s REST

Now that you understand the argument that all the above innovations caused massive disruptions in the usual way of doing things at that time, let’s circle back to where we started. GraphQL

GraphQL (https://graphql.org/) was invented at Facebook Inc. and it is currently supported by a foundation, which boasts the top companies of the world and all are contributing for the better good.

This invention is taking the Data layer by storm. It is challenging the dominance of REST paradigm for creating APIs.

REST is 20 years old and if you see jokes circulating on internet, it looks like its time for it to REST in Peace (RIP).

But you are still thinking, what the hell is this guy talking about. The whole world has taken fancy to API way of programming system interactions and the de-facto method of doing that is REST.

Agreed. But that may Not be the best method right now. Let us see why.

In terms of analogy GraphQL is to API what Structured Query Language standard (SQL) was to Databases. The advent of SQL standard consolidated various ways of querying databases. Similarly, you can think of GraphQL as the query language for your APIs. With GraphQL, you can Ask your APIs what data is required.

But we are getting ahead of ourselves. Let’s take it one step at a time.

Let’s consider you have an API for retrieving information of Products from backend catalog

In order to retrieve details of a product, you supply the ProductId and you get back 20 fields that consists of various details of your product.

Now let’s see where we will make use of this API

Let’s consider places where this API will be used.

1. You may use it on your ProductListing page, which may show many products of similar kind together
2. You may use it on your ViewProductDetails page, where all the 20 fields of the product are displayed
3. You may show some information of each product in your ShoppingCart page before Checkout.

However, if you observe, in first instance, you may require only 5 out of 20 fields of data that GetProduct API returns. In second case, it utilizes all fields. But again, in third case, you require only 3 fields out of 20.

This means that your API is sometimes fetching extra data than you require. This is called as the case of Overfetching

This adds to costs of retrieving data, network transfer of data and time lag in rendering the page. You can optimize it and create 3 APIs, each specific to the above use-case. So you will have

GetProductsSmall, GetProductMedium, GetProductLarge

You will agree that this is not a good solution, as overtime, you will have huge number of APIs to manage. Alternatively, you can parametrize it so you can have

GetProducts?param=S/M/L

But this is also not a very elegant solution.

So, what can be done. Answer of course has to be GraphQL, Why the hell would you be reading this blog post yet 😊

Well, GraphQL doesn’t disappoint. In fact, it shines in such use-cases.

In GraphQL you can send the following query to your API and it will return the following results

There you go. Now all you have to do is specify the fields you want while creating Query Requests and GraphQL will oblige by returning exactly that much data. No less No more. So basically, this helps solve the problem of Overfetching data for our API’s

Continuing our SQL analogy, you can compare it to having ability to now say “Select Field1, Field2, Field3 from…” with GraphQL rather than only having option of saying “Select * from…” in REST GET API.

This is just one feature of GraphQL, although an important one.  In other blog posts, we will explore more features.

Happy Clouding!

Advertisement