GraphQL - A Cool Kid on the Block - HashedIn Technologies

GraphQL - A Cool Kid on the Block

Technology - 08 Feb 2017
Aman Raj

Before we proceed and learn about GraphQL, let’s understand issues faced by REST APIs.

I don’t want to support multiple version of the same API

You are writing your REST API which returns city information


Okay, so it works for now. But wait. It’s never late for trouble.

Now you have a slightly different requirement. For example, one more airport is being constructed in the same city so you modify your API to return more than one airport name


Here comes the hammer, bam.

This new change will work pretty well for the new clients but what about those unlucky ones, who are still expecting airport name as a single string, not a list of strings. They are doomed. Aren’t they?

You would think to make two version of the same API which returns two different responses. But does it make sense to do so? Wouldn’t it be easier if you stop supporting older ones and support only new APIs? Yeah, it’s entirely possible but here is the bummer.You are not living in an ideal world. There might be few clients who are still using them. So you cannot just throw your old APIs away.

Congratulations, you are stuck with your older APIs forever and will be hammered again and again unless you convince your customers to migrate to newer versions or come up with a brilliant plan to support both versions together.

Just give me exactly what I want

Let’s say I have hosted an API which returns stock exchange data.


You being one of my clients are using this API for your mobile platform. You find three or four fields (say Profit Margin, Current Ratio, Return on Assets) useful to you and rest of the data is nothing but just a useless traffic over cellular network. So just to reduce the latency in the network you request me to provide you with one more API which just returns these three or four fields which you need for your application.

Now if you are paying me enough then I might think of adding an API as per your needs. But in any case, it will be quite clumsy for me to add and maintain new ones.

What I could do is, provide single point entry to my APIs and allow my clients to query whatever data they want and get exactly same data. It will make my life easier and I would never have to write different versions of the same APIs to support different requirements of each customer.

This sounds perfect. Right? Yeah, Why not. As long as I don’t have to do much of the work myself. But is it even possible with REST APIs?

Cool kid to the rescue

GraphQL is a very powerful library which implements an interface between client and server for data query and data manipulation. It helps to write simple and clear API to suit everyone’s taste and meet almost any requirement. Now why I say almost is because, the implementation for various frameworks is underway, so it’s quite possible that a particular feature, which your framework supports may not be available in GraphQL yet.

Significance of GraphQL

GraphQL is flexible enough in a sense that instead of defining response structure on the server, it allows clients to define request structure and fetch response accordingly. It only returns data which is explicitly requested. So if you request city name, my GraphQL API would serve you with grace and return a single field which is city name. If you request city name and airport name, the same API would return city name and airport name.

GraphQL is about – What You Ask is What You Get.

With GraphQL you can modify your API without worrying about breaking your client applications. That means it makes versioning process very easy. In fact, you don’t need to version your APIs at all as long as you make sure that existing fields are not hampered. And how is that possible? To answer that, let’s take a step back and go to our ‘city’ example.

Let’s say I want to add more airports(and if you remember, it was causing a serious issue in REST APIs). I can add one more field (say airports) which returns a list of airport names in that city. So, my schema would look like


Now my old clients need not make different query than what they were already making


And new clients would make query as


And that too using the same API. No one has to freak out about the changes in API. So I managed to keep both of my clients happy and keep getting paid from both of them without doing much of the work.

Win Win situation for everyone.

Query looks like more of a JSON data. Also, request and response structure mirrors each other. It makes query writing much easier because of familiarity with JSON.


categories is your table name and name is column name. Response to above query would be


How it differs from REST

Where REST requires many requests, GraphQL requires only one i.e. it follows single endpoint-driven approach. You can retrieve any data using a single resource URL ( say myhost/api/graphql).

With REST you request too much or too little but with GraphQL, you request exactly what you need.

Note: Big players like facebook, twitter, github have already adopted GraphQL. It works well for them doesn’t mean it’s going to work for your business use case too. So before using it in production first try it and see how well it fits your application.

So, what’s your take? Are you sold and ready to play with GraphQL? If yes then give it a go.

Share
Tweet
+1
Share

E-book on Digital Business Transformation