Loading Form...
Sep 27, 2021 | 9 minute read
written by Kirsten Aebersold
Graph QL is a protocol for designing application programming interfaces (APIs). It was cultivated so that programs built on different types of platforms could easily handle and pass data between each other.
By definition, GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. It was developed by Facebook in 2012 to address challenges the company faced while building their mobile application for iOS and Android platforms.
In 2015 it was publicly released and eventually moved to its own open-source foundation, hosted by the Linux foundation.
GraphQL now manages billions of API calls a day, is supported by almost every major programming language, and has become a popular alternative to rest-based APIs amongst developers world-wide, especially for those who develop headless ecommerce sites and experiences.
To understand how and why GraphQL works with not only headless ecommerce, but ecommerce solutions in general, it’s important to highlight the differences between the query language and the other most commonly used API architectural pattern, REST.
Until recently, REST (Representational State Transfer) was the standard style for designing web APIs. It surpassed its predecessor, SOAP (Simple Object Access Protocol), in popularity shortly after its birth in 2000, due to its more flexible and easy-to-use nature.
REST was specifically designed to overcome the common challenges developers faced with SOAP, such as bandwidth constraints, statelessness, caching, and the complexity of coding processes. SOAP is a protocol, whereas REST is an architectural pattern, meaning it is focused more on how a server or client receives data and is presented, as opposed to actually structuring and organizing the data. This means that whatever data is being handled, it can be more easily recognized by all possible end points.
The appeal of REST APIs lies in their ability to send requests through common software and web browsers, and don’t require special libraries or initialization. Despite their modern structure, REST APIs have their own shortcomings, and in a similar fashion to the history of SOAP, GraphQL was created to address the problems Facebook was seeing when attempting to adapt their rest services to mobile platforms.
The key difference between GraphQL and Rest APIs is that GraphQL is a query language that optimizes the performance and flexibility of existing APIs, whereas rest is an architectural concept that has made it easier to build and call on new APIs.
Chat with an expert today to see if GraphQL is the right choice for your ecommerce framework.
Rest APIs are notorious for over or under fetching data, meaning that a client is either downloading superfluous and unnecessary datapoints, or is required to make additional requests because it’s not receiving everything it needs on the first call. This can complicate and slow down performance for apps that use them.
Imagine a simple ecommerce app for book lovers. Based on the user search criteria and filtering, the app is designed to display a list of book titles on a screen and the author’s name. The API however, also pulls the original publication date, the paperback release date, total number of pages, and the rating when it hits the ‘title’ and ‘author’ endpoints. On the flip side, imagine the client needing to hit the ‘title’ and ‘author’ endpoint for each and every individual book that meets the search criteria.
REST APIs can also struggle to fetch and compile data from different endpoints. They are fairly simple and easy to manipulate if there is a single endpoint that requires a single task.
Imagine however, searching for flight options through a compiler, like Expedia or Scott’s Cheap Flights. Behind the web interface, the client is requesting access to information such as the airline name, flight date, and departure time. To complete this full query with a REST framework, multiple API calls would need to be made, one for each piece of information that would then be returned to the screen for you to see.
Some of the most common patterns or ways in which REST APIs are used also make it difficult to rapidly iterate on needed UI updates or changes, ultimately slowing down developer productivity.
Yes. In the eCommerce world, businesses strive to deliver the most relevant experiences for each of their users and shoppers. There are several benefits to using GraphQL for ecommerce development:
It is easy for developers to iterate their frontend applications quickly because the GraphQL layer is responsible for providing up-to-date data, which means developers don’t have to spend time chasing down the API. This helps to accelerate time-to-market for new experiences.
Because GraphQL allows you to fetch only the data that you need through parallel requests to different systems within your application ecosystem, it minimizes over- and under- fetching. This improves network performance, positively impacting the overall customer experience.
With GraphQL, frontend applications don’t need to maintain the logic required to call different systems and then reconcile the data. GraphQL also eliminates the need for backends for frontends. Altogether, this reduces code duplication and allows to eliminate channel silos that can lead to inconsistent customer experience.
GraphQL also helps developers avoid API versioning, which is used regularly to ensure that any API consumer won’t experience breaks when changes need to be made to the code. This can often happen new endpoints need to be added. With GraphQL, teams can add new fields to a API without having to adjust an existing query, making it easier to track revisions, help troubleshoot any issues that do arise, and ensure any client calling the API is still being delivered the right data.
Developers can also leverage their existing data and code with GraphQL and is supported by all of the major languages today, including Python, ReactJS, VueJS, meaning it can be adopted by teams with the right skill set, faster.
Headless commerce is an approach to ecommerce where businesses will decouple the front end, the UI, from the backend solution that drives the overarching experience. This includes the commerce functions and backend business logic that powers all digital commerce touchpoints.
Many companies have selected “headless” or API first approaches because it allows for greater flexibility in creating front end experiences, as compared to more monolithic eCommerce platforms that tightly couple the backend and frontends. Because headless commerce places emphasis on the data, GraphQL allows front ends to retrieve just what they need, allowing businesses to build more unique experiences.
GraphQL ultimately amplifies the myriad of benefits of developing with a headless architecture, and streamlines the data retrieval process on the front end so business can build the unique customer experiences their business demands.
In the world of performance and efficiencies, GraphQL has a lot of promise. Still, it is far from being a silver bullet, and much like REST APIs, developers need to adhere to best practices—some even more so than with REST APIs—to make sure the approach lives up to the hype.
For example, just because the data is provided to the front end is more streamlined doesn’t mean the retrieval of that data is more streamlined. If multiple resources and multiple fields need to be accessed, they’ll need to be accessed via REST API or GraphQL.
Additionally, due to the nature of GraphQL, it can become challenging to understand SaaS platform consumption, compared to RESTful applications measure resource requests. Consumers of SaaS application using GraphQL can unexpectedly hit their API rate limits, seeing their performance degrade or their costs increase.
Here’s another missing piece to the puzzle: how can you execute any business condition or logic that is unique to your business that isn’t found in the out-of-the-box commerce functionality of your eCommerce platform? With GraphQL, all of this logic will need to reside in the frontend application.
With multiple frontend applications, businesses will see an explosion of custom business logic either residing in the frontend application or a backend for frontend (BFF), both of which introduce maintenance complexity akin to that of a monolith.
Lastly, GraphQL struggles with caching, which can be troublesome for headless CMSs. Queries can be large and some display networks might not be capable of handling the request, or won’t scale as websites expand.
Much like its intentions at the time of inception, GraphQL is ideal for situations where developers are trying to minimize the amount of data being retrieved by their frontend application.
For example, if you are trying to make an experience available to users in very rural areas where their internet bandwidth is constrained, GraphQL will aid in reaching those customers. Additionally, GraphQL allows for each application to retrieve only the discrete data that it needs to perform its function, making each application lightweight.
GraphQL was developed to cope with the need for more flexibility and common inefficiencies of REST APIs, but is not always the best choice for teams looking to move quickly, especially if they don’t already have the right skill set. It can be the right move for ecommerce teams with complex queries, but for simple apps it would be an overkill.
For those who have already decided to or currently use GraphQL, Elastic Path recently released GraphQL Server for Elastic Path Commerce Cloud. This provides a GraphQL implementation of our core APIs to support ecommerce experiences, allowing developers already familiar and comfortable with GraphQL to continue using the query language to for development projects.
You can learn more about our new GraphQL server here.