Recently I went for lunch with my family at my favorite restaurant Flat Top Grill, I love this place as I have flexibility to choose what I want, how I want and how much I want. As I was sitting and waiting for my meal to come, I thought about GraphQL that we experimented and successfully implemented in a recent project. This project is live in production and handling complex queries from a modern AR/3D based configurator public website.
GraphQL is similar to Flat Top Grill in a way customer have flexibility to choose, customize and configure their request and end result is seamless, yum (in Flat Top Grill’s case), optimized to your needs and efficient to environment — as you are only requesting what you want, so in turn for every request you are optimizing the resource usage.
At that point I decided to share our successful journey with rest of the world. I’m thinking to start a sequence of articles that I will collaborate with my colleagues at Publicis Sapient Prashant Arora and Naveen Kumar.
In this very first article I would keep it to basics and based on the interest we can dig deeper and talk about how it is different from traditional APIs, how to build a right structure and how to test, document and release into production.
Our Story
We recently built a data intelligence layer consisting of data from various sources, predictions from machine learning models, and set of interfaces to ‘smartly’, ‘efficiently’ and ‘dynamically’ access the huge and complex datasets in a rapidly changing production environment.
These APIs/interfaces were created to serve entire organization’s data needs, in particular, to empower newly developed Configurator experience (from web and mobile) where consumers can build their vehicle, add parts and visualize the experience in AR/VR/3D fashion depending on the experience and device. With this context, our data query requirements were dynamic, complex and rapidly changing as we release new features in production.
We have bulit a culture of independently working PODs hence our data POD needed something that can serve the needs of experience POD without hassle of contract negotiations. We started development with traditional micro-service based APIs. Despite changing the signature and outcome of query based on different use cases through multiple negotiations, we had issues serving diverse needs. We were seeing drastic performance issues with our server-less architecture between client requests.
That’s when we started to experiment and perform a small POC on other alternatives. GraphQL came to the rescue because of it’s flexibility, configurability, and query notion. It improved the contractual hassles and query performance. We also discovered that GraphQL is a great tool for integrating multiple APIs including REST and other third-party APIs.
Impact on our Journey
- Reduced integration timelines significantly and speed up the production rollout, eventually improved time to market
- Adoption across the teams was smooth and easy due to GraphQL playground and ownership balance between application client and server (we will discuss in future article on this topic)
- Added element of Canonical Data Model in our architecture so all teams can speak ONE language (Key element of data governance)
- Improved application performance
What is GraphQL
As the name indicates, it is a query language for your API where client can write a query in API request to configure and customize their request.
Dan Schafer, GraphQL Co-Creator defined the GraphQL, “GraphQL is a query language for your API that shifts the contract between clients and servers that allows the server to say ‘these are the capabilities that I exposed’ and allows the clients to describe their requirements in a way that ultimately empowers product developers to build the products they want to create.”
Client (it can be a website or mobile app or anything that needs data) no longer need to request everything as they had to do with traditional APIs. in the Traditional APIs, the developer defines the outcome, but with GraphQL, client can define the outcome the need from API. We will discuss more in upcoming articles on how GraphQL is different from traditional APIs — for now, let’s keep it to basics.
for example, if you are looking for some attributes on an Medium article:
Request:
Response:
GraphQL Evolution
GraphQL is not very old, actually in this rapidly changing dynamic technology landscape it’s aging now. It was first developed by Facebook in 2012 when they started feeling pressure from the limitations imposed by traditional APIs as they moved to mobile. Their news feed and other implementations on mobile caused huge network usage and that resulted negative performance of their mobile app (Andorid and iOS). So, they had to invent to find something that’s lightweight, Client can dictate the data requirements to get in return only what you need.
Conclusion and What’s Next…
In this introductory article, we have started building the context around our problem statement, provided a very basic brief introduction to GraphQL, and it’s evolution thus far. As we move forward, we will build a use case with code samples and touch on schema design, development and deployment.
Stay tuned!
Next article: Decision Between REST APIs vs GraphQL
