As the web progresses further toward more modern, decoupled architecture, headless commerce has established itself as the architecture model of choice for ecommerce.
But what is Headless Commerce exactly?
First, what is Headless Commerce?
The term "Headless Commerce" can be used to describe a development approach to ecommerce, whereby the ecommerce backend (i.e. Shopify, BigCommerce, Magento, WooCommerce) is separated from the touchpoints that users interact with.
Touchpoints are the various points of interaction that shoppers may interact with when engaging with your brand.
With Headless Commerce, the frontend touchpoints that users interact with (a website or ecommerce store, mobile application, Amazon shopping, etc) will typically be served from the same backend, but decoupled from the frontends via which users interact or purchase.
In its most commonly used, and simplest form, Headless Commerce is used to power headless frontends or storefronts which are built on JavaScript libraries. For instance, Shopify may act as a headless backend (where products are created), and Next.js may act as a frontend, sourcing data from Shopify, with the two applications communicating back-and-forth.
This approach allows the frontend to be essentially limitless in terms of design and development possibility, without the restraints of the backend technology itself.
For more established brands, Headless Commerce can act as a way to serve multiple touchpoints, such as Amazon. A headless commerce backend can stream product data to Amazon or other retail marketplaces, simplifying operations, reducing time-consuming work, and optimizing efficiency within the business.
The same headless backend may also be responsible for populating a mobile app with product data, so that shoppers can make purchases via their smartphone, rather than using the website.
Further to this, the business may choose to have multiple websites or ecommerce stores, targeted at different markets. With headless commerce, both websites can be served from the same backend, which again, optimizes workflows for the business and streamlines maintenance, development, and other issues that would be associated with servicing multiple backends.
A headless approach to ecommerce would also allow a brand to serve other devices, such as smart watches and televisions, and other IoT devices.
Most smaller to medium-sized businesses will utilize a headless approach to commerce in a more simpler way: as a means to achieve a high-quality frontend shopping experience that is not bound to the limits of the ecommerce backend, with potentially a few other integrations.
But for larger enterprises, headless commerce has quickly become the approach of choice, with its ability to serve an unlimited number of touchpoints, ease operational bottlenecks, and facilitate the use of more modern, agile technology on the frontend.
Headless vs Traditional: They meet different needs
Headless Commerce can be an effective gateway into the modern, progressive web for many digital retailers.
A headless approach has the potential to solve many real challenges faced by merchants, particularly in today's fast-moving, interconnected digital market.
However, the strength of this methodology doesn't necessarily mean that traditional all-in-one ecommerce solutions have seen their day.
Traditional commerce still has its place, and continues to serve the majority of ecommerce frontends. It's important to recognize that the two approaches solve very different needs.
Traditional ecommerce setups are significantly more accessible, particularly to smaller brands who may lack the complex requirements of a headless build. Headless brings with it several challenges for which smaller firms are unlikely to have the resources to satisfy.
For a start, headless commerce builds are expensive: the expense of initially developing and deploying a headless storefront from scratch will dwarf the costs of setting up an ecom-ready WordPress site. With traditional commerce, the barriers to entry are typically much lower than for headless storefronts, which may be a game-changer for smaller businesses, such as mom-and-pop stores.
The initial cost outlay for a headless commerce build will have to match the problems that it proposes to solve for a digital merchant, and for businesses which are less mature, this could be a challenge.
Currently, it isn't possible to deploy a headless ecommerce store without the input of a skilled development team, and it's unlikely it will ever be. The very nature of headless commerce as a development approach, is that it's capable of providing the custom functionalities, integration, and overall behavior that established and highly-trafficked online brands yearn for.
Headless commerce allows digital retailers total control over the entire stack, how touchpoints work together, and how the backend services its distribution.
By it's very nature, "headless" defies the traditional all-in-one approach, replacing it instead with a totally-controllable stack that is architected to meet the specific needs of an online retailer.
Due to this, headless commerce builds require a heavy investment in initial development outlay in order to realize the bespoke needs of a retailer. However, the results can be astounding when a build is architected and executed effectively, able to leverage automation from product management through to fulfillment, across a variety of channels, all at once.
In contrast, most traditional ecommerce software and platforms have been around for the best part of the last decade (nearly two!):
- Magento saw its first public release in March of 2008,
- For WooCommerce, its public debut occurred during 2011,
- PrestaShop was released officially in 2008,
- And OpenCart... 1999!
This isn't to say that these platforms haven't evolved, or that they're "too old" (there's no such thing) — most have adapted incredibly over the last couple of decades, and collectively still service the majority of online stores today.
However, with collective communities and active usage in the millions, the evolution of these (often Open Source) platforms has been significantly stunted due to an inability to change in an agile way.
These heavy, monolithic ecommerce softwares would understandably struggle to pivot toward more progressive technology, due in part to the sheer volume of usage (they're quick and easy to deploy), and the broad ecosystems that surround them.
In fact, several monolithic ecommerce management systems have introduced pre-packaged APIs within the core application. This doesn't, however, address all of their challenges, nor offer as attractive a proposition as a full technology pivot could achieve, leaving ambitious brands with copious amounts of potential technical debt due to their ongoing hosting, servicing and maintenance.
Traditional, monolithic approaches to ecommerce have the best potential to serve businesses whose requirements are fairly straightforward, are lower trafficked, and have less available resources to invest in development, technology and infrastructure.
On the contrary, our agency finds that the advantages of a Headless Commerce setup will often outweigh the initial investment once a business reaches a stage of growth or maturity, where operationally the challenges and restrictions of a monolithic approach become ever more apparent, presenting barriers to growth and ultimately impeding on customer experience.
Drawbacks of Traditional (Monolithic) Ecommerce
1) Security concerns
Traditional, monolithic ecommerce systems most often utilize the same application to deliver both the frontend and backend.
This means that the primary frontend touchpoint, which users interact with in order to browse and purchase products, maintains a direct connection to the backend database in order to retrieve products and content to display.
Typically, monolithic systems will also offer the ability for users to authenticate directly via the frontend, through login and registration forms.
Because the frontend makes direct queries to the database, it significantly raises the potential for security vulnerability through various means. The presence of forms, query parameters in URL, and various other areas of potential exploit require correct sanitization and maintenance.
With each plugin, theme, or extension installed within the ecommerce application, the greater the cumulative risk of exploit grows, simply due to the fact that additional points of potential exploitation are introduced into the application.
The presence of forms, query parameters in URLs, and any input field such as within-application search forms, have the potential to add to the overall security risk where the software is not properly maintained, or if an old version of PHP is being used.
PHP is perhaps the most common language utilized for by monolithic ecommerce systems, and quite arguably monolithic applications in general, at least in the context of content management systems.
PHP has amassed a reputation for being easily exploitable, but this is likely more due to its usage (lack of sanitization) rather than the language itself.
For PHP, the barrier to entry for development is low (it's incredibly easy to learn, at least compared to other backend programming languages), which has resulted in its widespread use over the last few decades.
As a consequence, many web applications, plugins, and extensions are built on PHP and execute code which is less secure than it should be.
In contrast, with a headless setup, the backend and frontend are maintained individually, often hosted in completely separate environments, and written using different programming languages.
In fact, it's quite common (especially with tools like Gatsby) that there is no direct connection with the backend database from the frontend, or at least minimally, in the form of predictable API endpoints.
This mitigates the risks associated with attack or exploit from a monolithic ecommerce frontend, which is most often directly interwoven with the backend of the application.
From another angle, traditional ecommerce architecture is more exposed to the vulnerability of DDoS attacks; a common trick used to flood a server with an endless number of simultaneous requests in order to bring the server to a halt (distributed denial of service attacks).
This can be challenging to mitigate against without the assistance of a seasoned developer or security professional.
The risk can be mitigated by the use of CDN delivery and an effective WAF, which can be configured to somewhat protect the origin server.
However, if an attacker is able to circumvent the protection, such as by accessing the server's IP address directly or targeting resources not routed through the CDN, the origin server can indeed be exposed to attack.
With headless, the risk is somewhat mitigated, depending on how the frontend works and its level of continuous dependency on the backend.
If the frontend does not connect to the origin server outside of the build cycle, the risk here is substantially mitigated against.
2) They're Slow
Monolithic ecommerce systems have a reputation for being slow.
This isn't necessarily a fault of the application itself, as an installation out-the-box will often provide for very acceptable response times even when a site is fairly high-trafficked—providing of course that the server resources and implementation is appropriate for the amount of usage.
The challenge with speed of monolithic ecommerce systems is complex, because there are so many potential areas that can be affected, with a host of potential solutions available to mitigate or improve response times.
For a start, monolithic ecommerce frontends maintain a direct connection to the database, making multiple queries (typically in MySQL or PostgreSQL) for each page that is loaded by an end-user, or each action the user performs (such as adding an item to their cart).
Where the database is not properly maintained, reindexed, or optimized for resource consumption and caching, cracks will eventually begin to show over time, as product and order data grows (for some sites, exponentially).
This of course has a knock-on effect on the speed of the rest of the application, and the server itself, with potential for 502 errors and slow response times which will directly impact user experience, and impede conversions.
The condition of the database is not the only potential culprit of slow-loading monolithic ecommerce applications.
Highly-trafficked ecommerce stores need to constantly monitor and tweak server resources overall as on-site usage and activity grows. This is due to the fact that increased usage of the frontend will result in increased strain on the backend, which is a result of the direct database connection.
As a result, queries take more time to execute, on-server resources take longer to download, and response times increase. This has a cumulative effect across the entire ecommerce system, where a monolithic application is being used.
The increased usage of the frontend directly affects the backend, and in many cases can even bring entire servers to a halt where inefficiently resourced or optimized.
Unlike headless commerce implementations, traditional ecommerce systems rely on a single server to serve all users of the platform, powered by a potentially infinite number of concurrent connections to the backend database.
With headless, because the frontend and backend are independent of each other, it's possible to achieve partial or complete isolation of the two, resulting in a much easier stack to service and maintain. This can provide significant relief in periods of high or unpredictable traffic, and greater mitigates against the need to increase backend server resources due to increased frontend activity.
3) They're Bloated
One of the lovable (depending on who you ask!) benefits to traditional monolithic ecommerce systems is their low barrier to entry.
Many of them are widely supported, utilized across many millions of websites, and boast diverse ecosystems of functional plugins, extensions, and ready-made themes.
Furthermore, because the most popular monolithic ecommerce applications are built on PHP, customizing themes and plugins can be achieved with relative ease, and makes for a low-cost way to build a reasonably attractive, functional ecommerce store.
For growing ecommerce stores, which may sell hundreds, or even thousands of individual SKUs or products with a high number of variants, optimization of the code and database queries within the application and any installed themes/plugins becomes ever-more important.
Where the codebase contains (even in small amounts) queries or code which is sub-par for from the perspective of performance optimization, a domino effect will be felt throughout the rest of the application.
With each additional theme, plugin, or extension installed into the application, the codebase grows larger and more bloated.
The same can be said for custom code that is developed and introduced into the application, particularly if in copious amounts and if not effectively optimized.
Oftentimes, in an effort to improve the resulting performance issues, administrators or naive development teams will install additional plugins which enable frontend performance improvements through various caching mechanisms.
Unfortunately, this doesn't solve the root cause of the problem, and will likely still result in performance issues—just in specific areas.
Most notably, where a direct connection to the database is required, or where a page load circumvents the caching plugin, such as an Order History page, Checkout page, or the actual backend administration dashboard itself.
We've even seen clients implement CDN caching with "Always Online" capabilities enabled, in order to mitigate against the unpredictable response times of the origin server, or where a page load is actually a cache miss and would potentially result in the server crashing due to extensive queries and severely impacted response times.
This would not be optimal for SEO, let alone user experience.
However, significant performance concerns are an unfortunate reality for many merchants who are operating severely bloated, monolithic codebases.
4) Design Constraints
As we've learnt, monolithic ecommerce systems most often service both the front-end and back-end within the same application.
For the majority of widely-used traditional ecommerce platforms, PHP is used to power the application, oftentimes both the frontend and the backend, (even if under-the-hood, such as through a Mustache or Twig templating engine—these are still fed and interpreted by PHP).
Though it's use is widespread, PHP is arguably one of the least effective languages for frontend development today.
In recent years, JavaScript has repositioned itself as the frontend language of choice, now popularized through the release of JavaScript-based frontend libraries and frameworks such as React, Next.js, Gatsby and Remix.
In 2023, the frontend experiences that highly-skilled developers can achieve with JavaScript effectively wipes out PHP as a modern language for the development of frontend experiences.
With frontends processed by PHP, although JavaScript can of course be incorporated into the frontend experience, it takes more of a backseat.
With today's frontend development tools afforded to developers from the leading JavaScript libraries and frameworks, PHP is most certainly obsolete in the eyes of brands that desire a slick, interactive, and disruptive frontend ecommerce experience.
With monolithic ecommerce applications, frontend developers are boxed within the inherited constraints of the all-in-one system, often having to develop complicated workarounds in order to achieve the design and UX they're striving for.
A headless approach does away with design constraints, affording absolute freedom to designers and frontend developers.
For progressive, disruptive brands, this makes headless commerce a winner in terms of development approach. With headless, not only is the slate completely blank, but the tools available today (think React, Vue, etc) are simply no comparison to yesteryear's rendering engines, packaged within the all-in-one ecommerce systems that have served so many.
5) Development Constraints
Just as with the design constraints felt by frontend developers working with monolithic ecommerce applications, backend development constraints are a real challenge for growing merchants who utilize a more traditional setup.
Changes or further development to the application's backend means that developers are locked-in to the programming language and architecture/coding structure of the backend application itself.
In most cases, it is not recommended to modify the core application itself, as this negates the ability to ensure smooth upgrades from a maintenance perspective. In order to circumvent this, developers are forced to develop additional plugins or patches to the platform, leading to potential bloat and performance difficulties over time, if not effectively optimized from the outset.
The greatest challenges, however, are felt by stores which require a large amount of custom functionality.
Monolithic e-commerce systems will often have to be bent in all manner of directions in order to achieve significantly complex customizations, something which undoubtably affects overall performance.
This is due in part to the fact that the backend technology for these systems is "fixed" (i.e. a PHP-based ecommerce system will require a LAMP stack (or some variation of) in order to run.
For ambitious ecommerce stores with large amounts of custom functionality, custom backend processes, and a host of integrations, such a stack eventually proves sub-optimal.
On the contrary, headless architectures provide an opportunity for greater control of the technology selection, and particularly with the rise of Composable Commerce, mitigate against such challenges by modularizing the stack in order to best-achieve specific needs.
6) They're often based on legacy technologies
Monolithic commerce systems are slow to change, and this is perhaps the crux of the problem for many progressive online retailers.
They're slow to change because:
- They're (relatively) old, compared to the newer and more progressive implementation models now available for ecommerce
- They're strongly adopted and widely used, often with vast ecosystems of out-the-box themes, templates, extensions and plugins which serve the wider community
- They're often Open Source (where self-hosted), meaning that they are financially limited in terms of continuous development resources, often relying either on volunteers, donations, or other funding strategies.
Due to their slowness to change, these ecommerce behemoths have experienced a general inability to evolve at the same rate as the rest of the web.
This has resulted in a significant disparity between today's web technologies and those utilized within these older ecommerce systems.
It's important to appreciate, however, that oldness in itself is not the problem, but rather the inherent slowness or inability to change that is common of widely used monolithic ecommerce platforms.
Unfortunately, this seems to go hand-in-hand with the age of such systems, which–perhaps unfairly–gives some of them a bad rap.
The rest of the web has moved onto bigger and better things, and this leaves the monoliths stuck in the past and struggling to keep up.
Regrettably, this is perhaps most notable in terms of the technology and architecture of such applications, and forces businesses to utilize legacy technologies and programming languages.
An example of this is asynchronous processing. For businesses who aim to apply complex logic and data transformation within their ecommerce build, a backend written in PHP may not be most suitable.
PHP does not natively support multi-thread processes and this can make it a challenge to implement code or functions where a lot of asynchronous processing is required on a frequent basis.
However, for a monolithic ecommerce system written in PHP, the options for growing businesses acts as a sobering reminder of the potential discrepancy between the technical strength and objectives at hand.
When developing or extending monolithic ecommerce applications, such as to incorporate complex custom functionalities, developers will need to utilize the programming language and backend architecture of the existing application, even if it is not the most suitable.
7) They're often abused through the installation of excessive or unnecessary plugins
As is often the case with traditional content management systems, traditional e-commerce systems frequently see abuse in the over-installation of plugins and extensions, aimed at enhancing functionality.
In general, it is recommended to avoid or uninstall unnecessary plugins as a principle.
However, it's still common practice and this has a direct impact on various aspects of the monolithic build.
The large and often vibrant ecosystems of traditional ecommerce management systems offer the attractive lure of one-and-done plugins to add new functionalities or enhance existing ones, both on the frontend and backend of the ecommerce store.
However, these are just some of the unintended consequences of over-installing extensions, particularly if not actively monitored or maintained by a dedicated development team:
- Excessive application bloat (unnecessarily inflated codebase)
- The presence of inefficient queries within the installed plugins or extensions
- Poorly or unoptimized code execution within potentially numerous plugins or extensions that may be installed, even if unused
- The potential for heightened security risk as a result of additional functions or queries being introduced into the codebase, even if unused. This is of particularly high risk where a multitude of plugins are installed, but not kept up-to-date, even if unused
- Potentially negative interactions between extensions, or failure to achieve cross-compatibility between multiple plugins
- A potential lack of consistent updates for poorly maintained extensions, or delayed updates/releases, which can have a knock-on effect on the upgrading of the core application or other dependent plugins
Whilst such plugins are able to achieve desired functionality quickly, cheaply and likely quite effectively, it's worth considering the risks associated with an over-reliance on them to form the custom functionalities required.
8) They're Fragile
With a traditional ecommerce architecture, all components of the ecommerce store and experience are tightly interwoven into a single core application.
Whilst this technique has its benefits, it has one significant drawback: If one thing goes down, the whole thing goes down.
If the application's hosting service experiences downtime, both the backend and the frontend become unanimously inaccessible.
The same can occur where even with non-hosting related problems, such as a misconfiguration in the server's architecture, or even within the application itself.
Any potential cause of downtime will affect the entire application, and this means that immediate input is required, or all operations will grind to a halt.
With a more modular approach, as celebrated with the progression toward Composable Commerce (of which headless plays a pivotal part), it's possible to engineer the backend in a way that it is entirely isolated from the frontend itself for routine operations.
Such an approach could potentially allow users to continue interacting with the ecommerce frontend, even in a reduced capacity, if the entire backend were to go offline unexpectedly.
Not only does this buy time, but it means that end-users are significantly less affected by unforeseen issues elsewhere in the application architecture. Crucially, from a front-end user's point of view, we can achieve "business as normal" when harnessing the component-based approach of headless architecture, mitigating against the risks associated with unexpected downtime.
Routine and scheduled maintenance also forms a large part of the development and operations commitments for ecommerce stores. In separating the frontend from the backend, this can occur without the need to take the entire frontend offline, further mitigating against lost sessions, sales, and fulfillments.
The beauty of Headless Commerce is that it can be implemented in such a way that minimizes or removes the need for a persistent connection to the backend database, allowing us to effectively service application backends without the drama of downtimes, unexpected errors, and traffic spikes.
The intra-dependent nature of monolithic ecommerce architecture means that unexpected challenges have a very real direct impact on end-user experience and sales, which is never fun.
Maintenance must be conducted at particular times of day, in contrast to a headless environment where, depending on the implementation, this could occur even during peak hours in the event that the backend is entirely isolated from the frontend.
This creates an overall fragility to traditional setups, which has the potential to act as a barrier to agile development and the pace of evolution for the ecommerce store: a real challenge for growing businesses.
9) Difficulties with an agile development process
Another unintended consequence of all-in-one ecommerce solutions and their single-application structure is that agile development can be slightly more challenging.
The frontend and backend can't undergo large-scale or rapid development changes without impacting the other.
Commits to git repositories from developers may include code changes to either the frontend or backend, or both, with no distinct way to tell the two apart without inspecting the code changes and commit details.
