In software, the term headless refers to software without a graphical user interface. Within a headless environment, requests are made via an API in order to submit or retrieve raw data. Once the raw data has been returned, it may be used in any number of ways. For example, the data could be aggregated into a report, archived for later use (cached), presented to the user within a unique GUI, or populated into another system. The possibilities are truly endless!
Because headless websites are defined by the ability to submit and retrieve raw data via an API, any platform with a robust API can support headless commerce; both Magento and Shopify offer extensive API access to essential eCommerce services.
In a “headless” environment, there is almost always physical separation (via discrete infrastructure) between the environment serving the content (the frontend) and the environment that provides access to the data/API (the backend). In a headless commerce configuration, the eCommerce platform serves as the data source—housing products, customers, carts, order history, wish lists, etc.—but it is not used to directly present information to the customer. Instead, an external system ( a static web page, or a mobile app) utilizes the platform’s API to retrieve data and then present this data to the user. A common approach for headless websites uses JavaScript to make AJAX requests to the platform’s API. In the most simplified examples, a static HTML page with no backend CMS could use this technique to integrate with a headless backend system, powered by Magento or Shopify.
Let’s explore how a cart might work in headless commerce (pseudo code below). A cart object would be created when a user adds a product to the cart (perhaps from the product detail page):
API Endpoint: /api/cart/add
Request Data: { product: 'Sneakers', price: '$20' }
Response Data: { status: 'success', cart_id: '123456789' }
Here you can see that we’ve successfully added Sneakers to the cart. We’ll have to store the cart ID, so we can fetch the cart later:
API Endpoint: /api/cart/get
Request Data: { cart_id: '123456789' }
Response Data: { status: 'success', cart: { products: {'Sneakers', price: '$20' }, tax: '$1', total: '$21' }
Here you can see that the API has stored and processed the data, and helpfully returned the cart object including line items in addition to tax and a cart total. We can now present this information to the customer however we like, perhaps as a list of line items on the cart page, within a mini cart flyout in the header, or by using a portion of the data (e.g. cart total) to display a unique promotion to the user elsewhere on the site.
By applying this approach to a broader set of features, we can build a fully-functional headless eCommerce experience—provided that the data for all of the desired functionality is available via the platform’s API. Each page, template, or feature of the headless site must be integrated with the API to push and pull data from the platform. Moreover, the frontend layer must include logic, track sessions, perform data validation, and handle errors, in addition to the stylistic design components.
Why headless?
The primary benefit of headless websites is the flexibility it provides by separating the frontend interface from the data. In the web community, the term “frontend” is often used to refer to the GUI of a website. While a web GUI is one manifestation of a frontend, it is not the only type of frontend. In a general sense, the “frontend” refers to anyway in which a user interfaces with a system. “Frontend” may refer to a website, a mobile app, a digital watch face, a TV app, or even a voice interface. The frontend does not need to be visual, it just needs to provide a user with a way to access data and execute commands within a system.
As technology continues to evolve, the ways in which users interface with systems will change-in-kind. A loosely coupled “headless” system allows businesses to offer any number of frontend interfaces to the underlying data, centralizing data storage and processing, while distributing data presentation. This allows frontend interfaces to be built independent of the backend system, perhaps by different teams, in different programming languages, and delivered in different environments. For example, one team could develop an iOS app using Swift, another team focuses on an Android app using Java, a third team focuses on building a single page PWA using React, and a fourth focuses on building a voice-powered Alexa skill; all of these teams would utilize a single, centralized data source, provided by the API. This allows teams to specialize in a particular area/frontend technology without needing to understand the inner-workings of the backend system.
Theoretically, because a headless frontend is independent of the backend, the backend may be replaced without requiring the frontend code to be rewritten—provided that the replacement backend system’s API can accept requests and provide responses in the exact same format as the original implementation. While this approach works in theory, the reality is that different platforms are unlikely to have interchangeable APIs.
Again, the most important element of a successful headless implementation is the availability of an API, which provides access to all of the data required to run any features/functionality desired within any application. If a feature is desired for which an API doesn’t already exist, that API will need to be created before the feature can be added to any frontend interface. While it is possible to leverage the APIs of multiple different backend providers (e.g. to add a one-off feature), care must be taken to ensure interoperability. Be cautious and plan well when integrating multiple backend data sources (“bodies”) into a single frontend (“head”), as this approach may ultimately lead to a fragmented system that is difficult to manage and maintain.
Headless Performance
Another often touted benefit of headless websites is that they are more performant compared to their “monolithic” counterparts. When measuring performance, it is important to understand the metrics being used and understand where bottlenecks exist.
While headless websites utilizing a frontend JavaScript framework (e.g. React) may perform better when measuring Time-To-First-Byte (because static content is highly-cacheable) when compared to a non-headless site, it may be slower when measuring Time-To-Interact (because dynamic content must still be loaded from the server, requiring additional requests). Time-To-Interact may be viewed as more significant to the user experience than Time-To-First-Byte, and the API requests (which must connect to the backend platform) may be viewed as an unavoidable bottleneck that is required for both headless and non-headless implementations.
For these reasons, headless websites are not inherently faster than non-headless websites. It is possible to build a poor-performing headless website, and it is possible to build a well-performing non-headless website. Performance should be a consideration of any implementation, and if planned well, the performance of either approach will be comparable.
Head-Optional Platforms
Magento and Shopify can both be viewed as “head-optional” platforms because they both provide rich APIs that may be used to create external headless experiences, and they also include built-in templating frameworks that may be used to expedite development by leveraging the template logic that is already built into the system.
Using the native platform for the primary website often makes financial sense, as under the headless model, standard eCommerce features which exist within the native platform out-of-box must be rebuilt. The native platform may also integrate multiple features together to provide an even more powerful out-of-box experience at a much lower cost. Additionally, infrastructure and integrations are consolidated, which usually decreases cost. Finally, not all features are accessible via API, this is doubly true for platform add-ons (i.e. extensions/apps)—not utilizing the out-of-box templating engine prevents merchants from using publicly available apps which can also greatly reduce development time and cost.
By using a platform with both a built-in theme engine and a powerful API, you’re able to make the most of native capabilities for your primary eCommerce website, while having the peace-of-mind that your business can scale and expand into different channels in the future.
Not Sure if Headless is for You?
We would be happy to discuss your challenges to determine if headless is a good choice for you. Reach out and one of our experts can be your guide.
Our friends over at SubscribePro have put together a great resource if you’re looking for inspiration/examples of headless eCommerce sites.
