Are you ready to adopt GraphQL?

 

GraphQL                             In this article let us explore GraphQL. Let us first understand what GraphQL is? GraphQL is a specification from Facebook. GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL gives clients the power to ask for exactly what they need and nothing more by avoiding over fetching or under fetching of data. We can understand it more when we are going to see GraphQL implementation in action. Till then hold your curiosity. 

Wait,Wait… So far we are using REST(Representation State Transfer) to expose our services as APIs. Let us ask some questions ourselves before getting deeper into GraphQL.

Why do I need to adopt GraphQL?
What problems am I facing with REST APIs? How GraphQL solves those?
                     To answer above queries let us take a use case to build an e-commerce application for web, mobile and native clients. We decided to expose APIs for various e-commerce functionalities.  For example I have product detail REST API which gives specific product information as JSON which includes product data attributes, specifications data, reviews data, etc. As we are having many attributes in product JSON, the size of it is more.  Each client (web and thin clients(mobile and tablets))  has it’s own front end requirements to display product data as they have different screen sizes, memory, network bandwidth, etc. Now my clients started consuming product detail API. Though mobile and tablet interfaces doesn’t require entire product JSON as web, still product detail API is giving entire product data. It is evident that clients doesn’t have control on the data what they want from server. This is called over fetching. The pictorial representation of REST over fetching issue is given below.REST                        We can solve over fetching issue with various approaches. The straight forward approach is to maintain different APIs for thick and thin clients. Though this design solves over fetching issue but has other problems like code maintenance,  implementation of enhancements across different APIs, deployment of thick, thin client APIs, more compute, more man power, etc., which puts more cost to project. The other approach is having middleware to intercept the client request. Based on client request filter the response to return. This adds additional layer to application which has same issues like previous approach.

                   Now let us discuss second issue with REST called under fetching. To avoid over fetching, we decided to create granular APIs so that clients will make API calls for which ever the data they required. Let us take product detail page for web. It has product information, specifications and reviews to display. Now to render product detail page client is not going to get data in single API call. So client needs to make multiple API calls (like basic product API, specification API, Reviews API) to cater its data requirement. This design has performance issues with increased number of round trips to backend server and APIGateway. The other issue is requiring of more compute power and network as rise in number of requests to serve. Below is pictorial representation of under fetching.REST Under Fetching                 Let us see third issue with REST that is, evolving APIs with versions. Any API will evolve as business needs will change with time. As per our customer needs we might need to add data attributes(most of the cases we won’t remove data attributes as we need to have backward compatibility) to existing APIs. When we do any changes to existing APIs, we need extra vigilant as the changes might break the clients. To avoid that we will do versioning of APIs as and when we plan to release changes to existing APIs. When we introduce new versions which puts burden of managing more APIs(i.e. more compute power, more man power), planning to deprecate older versions. Discipline and communication is needed when we have more versions of an API. With REST we can not do silent releases.

                  The above issues are leading us to look for other solution called GraphQL. We will see how GraphQL addresses the above said issues by implementing an API in coming article. Meanwhile let us see request and response paradigm with GraphQL and how GraphQL makes clients happy by serving what they want.GraphQLHere are some of the adopters of GraphQL https://graphql.org/users/.
In the coming article we will see implementation of an API with GraphQL. Till then Spread love for APIs!!!

 

 

Advertisements

I am Siva Prasad Rao Janapati. Working as a software developer. Has hands on experience on ATG Commerce(DAS/DPS/DCS), Mozu commerce, Broadleaf Commerce, Java, JEE, Spring, Play, JPA, Hibernate, Velocity, JMS, Jboss, Weblogic,Tomcat, Jetty, Apache, Apache Solr, Spring Batch, JQuery, NodeJS, SOAP, REST, MySQL, Oracle, Mongo DB, Memcached, HazelCast, Git, SVN, CVS, Ant, Maven, Gradle, Amazon Web services, Rackspace, Quartz, JMeter, Junit, Open NLP, Facebook Graph,Twitter4J, YouTube Gdata, Bazzarvoice,Yotpo, 4-Tell, Alatest, Shopzilla, Linkshare. I have hands on experience on open sources and commercial technologies.

Tagged with: ,
Posted in GraphQL, Uncategorized
3 comments on “Are you ready to adopt GraphQL?
  1. Sushant Dadhwal says:

    Couldn’t you implement a client based response filtering at the API Gateway level if you are already using one? What advantage you get from GraphSQL in that case?

    • Putting logic at APIGateway level or building middleware(I think we did this approach for our implementations) to filter response based on client has issues like manageability of code(I mentioned this in my article) . Even if you put logic at Gateway level clients doesn’t have freedom to get what they want from server. For example I am building API for mobile native clients. Different customers are using my API to build applications. In that case each customer’s data requirement is different. But still I give same data for all customers. This over fetching data issue has been addressed by GraphQL. GraphQL gives freedom to clients to query what data they want from server. In the coming article I will show you how it works.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

DZone

DZone MVB

Java Code Geeks
Java Code Geeks
%d bloggers like this: