The Language of Modern Commerce, Part 3: Key definitions to help you navigate your digital commerce future

Our ongoing glossary series offers definitions and explanations of the most relevant words and terms used to describe the innovations and experiences driving digital commerce. So far, our first blog explained APIs, the cloud and composable commerce, while the second blog clarified the meanings of digital experience composition (DXC), extensibility and frictionless as they apply to commerce technology.

This month we’re tackling frontend/backend, GraphQL and headless commerce. While you may be familiar with one or all three, our feeling is that so many new terms are emerging in the tech industry, which can get a bit confusing. As a business leader, you have enough on your plate, so hopefully, our comprehensive definitions can help ensure you’re well-equipped to make the daily decisions needed to drive your commerce future forward. 

The majority of today’s websites are comprised of two main components — a frontend and a backend. The frontend includes everything a user sees and interacts with on the site — from the copy and visuals to the navigation menus, buttons and even the pop-ups. Frontend developers use specific tools to establish the look and feel of the digital experience, also known as the UX/UI.

The backend is exactly the opposite: It’s everything that happens on a website behind the scenes. For eCommerce sites, it’s where log-in data is stored, along with product catalogs and processes like checkout and payments. All the infrastructure needed to keep the frontend running smoothly so that users enjoy seamless experiences is found in the backend. 

When websites were first introduced, brands either bought or built all-in-one, a.k.a. monolith platforms. Either way, the frontend and backend were tightly connected. The advent of MACH® architecture has made it possible for brands to implement and manage each separately while still facilitating the communication and processes necessary to enable commerce.

Example Usage

Adaptive Usage: Frontend-as-a-Service (FEaaS)

MACH gave birth to a new category of software vendors that offer Frontend-as-a-Service. Instead of a brand having to go through the long, difficult process of building a frontend solution from scratch, which involves writing and testing code for weeks, these provide brands with prepackaged software tools that make it easy to quickly set up an engaging frontend experience. commercetools Frontend is a FEaaS that delivers an API-based, headless customer-facing experience that works seamlessly with our backend commerce engine, commercetools Composable Commerce.

To learn more about how to choose the right frontend for your business, read our blog, “The top 5 things to look for in choosing a frontend solution.”

GraphQL is a query language for APIs. In addition to offering a way for developers to deliver understandable descriptions of data in an API, it delivers a runtime for fulfilling queries with that data.  Facebook created GraphQL and, in 2015, offered it as open source. Since then, its ease of use has made it the go-to approach to build client-server communication. 

As an API-first solution, commercetools was the first commerce vendor to market with GraphQL support, have the most coverage of any vendor in the space, co-organize GraphQL Conf (the world’s largest GraphQL conference), and one of our developers built Sangria, which powers Twitter and the New York Times. 

Example Usage

Analogy

Think of GraphQL as the librarian in a library full of millions of books. Instead of wandering around searching for the book you need, you have a knowledgeable librarian by your side who understands your specific requests and can retrieve exactly what you’re looking for.

The library is the server that holds all the data a user might need. Each book on the shelf represents a specific piece of data – like a customer’s name, age or address. Instead of having to request each piece separately, with GraphQL, you can put in one request or query and receive three pieces of data at the same time.

Avid readers love librarians that can not only locate and take them to the exact book they want but can also take a topic they’re interested in along with additional information they provide and make specific recommendations. This is the same reason developers love GraphQL, it simplifies the process of data retrieval, reduces network overhead, and provides a more efficient and streamlined approach to working with APIs.

To learn more about the benefits of GraphQL and how to leverage its benefits, download “GraphQL for Modern Commerce,” a booklet written by Kelly Goetsch, Chief Strategy Officer, commercetools.

In 2013, Dirk Hoerig, co-founder of commercetools, invented a technology architecture better support the digital commerce needs of brands and was looking for a term to describe it. Instead of building a platform with a tightly coupled frontend and backend, which was how vendors at the time provided commerce to brands, his new approach was to separate the two ends, so that they could function independently while still communicating with one another in the cloud. Since the frontend of a platform which included everything a website user sees, was known as the “head” and the product Dirk invented was solely backend technology, he kept using the word  “headless” to explain what it was. Eventually, his headless technology morphed into headless commerce, while  the traditional approach became known as monolithic architecture.

Today, headless commerce's flexibility and agility have made it the default architecture approach for enterprise business. Taking this approach enables developers to expose all data and functionality as APIs and then be consumed by multiple heads. It also makes it easier and faster for brands to adapt to change and innovate as developers can implement new features without disrupting the frontend customer-facing experience.

Example Usage

Analogy

Imagine you bought a vacation package to visit a foreign country. Your package includes everything — the vendor chose the airline and the hotel, created an itinerary for you to follow and even provided a personal tour guide to accompany you on your journey. The selling point is letting the experts handle everything, you’ll get the best experience possible. Travelers who buy these packages often discover that if they want to make any type of change, it becomes difficult and expensive. This is exactly what happens with tightly coupled platforms — just like the traveler — whenever a company wants to do something outside of exactly what the vendor provided, things get complicated.

In this analogy, headless commerce is the alternative to the package vacation. What headless does is provide you with the foundation – the plane ticket and the hotel – but allows you to be in charge of everything else. For the traveler, that means choosing how you want to find your way around, using a map, an app, or a virtual reality headset, plus what attractions to visit, where to eat and when the day begins and ends. 

Headless architecture gives brands the same kind of freedom and flexibility. It provides a strong commerce foundation on the backend while allowing you to choose and customize everything else on the frontend, so you can meet the needs of your business and exceed customer expectations.

To gain a greater understanding of how frontend, GraphQL and headless fit into the modern commerce equation, read our blog post, “Exploring the differences: Traditional CMS vs. headless CMS and the role of commercetools Frontend”