How Commerce as Code Can Fix the Way Developers Build Commerce

Codifying your configuration ensures the “how” outlasts your dev team's tribal knowledge and provides a reliable blueprint for recovery. This is precisely what “as Code” services revolutionized in software development.

It all started with tools like Terraform, which let developers build and manage Infrastructure as Code. Rather than clicking on IaaS dashboards to configure services, configurations were stored as code, allowing for automation and version control. This was soon followed by all kinds of “as Code” services: from CMS as Code (think Contentful for all types of content) to Policy as Code (like Puppet for automating rules) and even Monitoring as Code (with tools like Checkly).

But why stop there? Why not apply the same idea to building commerce? That’s the inspiration for Commerce as Code.

The Power of SDLC Principles

CEO of Microsoft, Satya Nadella, says, “Every company is a software company.” Regardless of industry, a business needs to adopt a software-first mindset to stay competitive in the digital age. This means that it doesn’t matter if you sell groceries, shoes, or subscriptions – in the end, you are a software company. And as such, you should make sure the developers working on your commerce project are following the best practices.

Pioneers like Jez Humble, Dave Farley, Kief Morris, and Martin Fowler championed the Software Development Life Cycle (SDLC) principles. They introduced practices like version control, automation, and testing, making system management more consistent, traceable, and collaborative.

As Kief Morris, author of Infrastructure as Code, puts it:

Infrastructure as Code treats infrastructure the same way developers treat application code. It enables consistency, repeatability, and transparency.

Evolution of Commerce Platforms

You can break down the evolution of commerce platforms into four key generations. It all started with monolithic ecommerce systems and has brought us all the way to a composable era where digital commerce is composed of distinct services.

Monolithic Commerce

In the first generation, we had Monolithic Commerce platforms, where everything – front end, back end, and database – was packed into one big, all-in-one system. These platforms were the first to bring commerce to the web and introduced features you’re well familiar with today, like “add to cart” and “checkout.”

However, these systems were quite limiting for front-end developers and designers. They wanted more flexibility to build unique user experiences and use modern tools, but they were stuck with the rigid frameworks that came with the monolithic setup.

Headless Commerce

To overcome these limitations, the second generation, Headless Commerce, emerged. It introduced APIs that were able to read content, product information, order status, and place orders. By decoupling the front end from the back end, devs were given more flexibility in storefront development. However, the back end was still a monolith, and all the services like CRM and Search were bundled together in one big system. This made the overall commerce platform large and complex and prevented developers from using other, more specialized commerce systems for specific functions.

Composable Commerce

The third generation, Composable Commerce, further modularized the platforms’ backend. It introduced Admin APIs and Webhooks, which allowed different systems to talk with each other and communicate the relevant events and updates.
This means that developers were able to choose and integrate domain-specific services, like Commerce, Content, or CRM. While each domain service handles a specific aspect, it is still monolithic within its own domain. And even though the Composable approach is directionally correct, it lacks the service orchestration capabilities required to control commerce processes.

Orchestratable Commerce

The fourth generation, Orchestratable Commerce, introduces Service Orchestration. It gave platforms a new type of flexibility with features like API chaining, which delegates specific tasks to smaller, dedicated microservices. With Service Orchestration, developers can extend the commerce engine with their own code for specific functions like payments, promotions, or fulfillment. Moreover, each connected service can be further extended to fit the specific business needs.

Unlike fine-grained microservices, which focus on single responsibilities, service orchestration handles the complexity of combining services, thus enabling larger business workflows and functionality.

— Mark Richards, Microservices vs. service-oriented architecture

Digital commerce has become a critical capacity for most companies, requiring rapid development of complex business requirements and sophisticated, continuously evolving user experiences. We believe that service orchestration, paired with modern SDLC practices, will allow development teams to reach the next level in the evolution of commerce platforms – Commerce as Code, as presented on the Commerce Maturity Scale below.

The Foundations of Commerce as Code

Service Orchestration

Instead of each domain service being a monolith within its scope, service orchestration allows each part of the commerce function to offload certain tasks to specialized microservices. For instance, rather than having a complex payments engine built into the commerce platform, the system can delegate payment processing to a dedicated microservice. This app processes the checkout data requests with a custom shape of webhooks’ payload and returns the appropriate payment information, allowing for highly customizable queries.

Tools like synchronous webhooks facilitate this delegation by enabling real-time, bi-directional communication between services. The Commerce as Code vision enables chaining API calls in such a synchronous way to ensure that microservices can effectively handle delegated tasks and return responses in a timely manner.

Local Availability (SDLC practices)

Using a modern SDLC with production-like environments for development and testing gives developers the ability to run the commerce engine and associated services locally. Local availability empowers developers to use their own debugging tools, inspect logs, and test changes in a controlled setting.

When it comes to Continuous Integration and Continuous Deployment (CI/CD), it's important to create temporary test environments that are as close to production as possible. Running services locally or in isolated cloud environments ensures that automated tests are reliable and unaffected by other developers' activities.

While cloud-based solutions are ideal for production because of their scalability and infrastructure management, relying on them exclusively for development can introduce latency and dependency issues. Having local availability means developers can work efficiently without being slowed down by external factors. To make this work, it's essential to have access to the commerce platform's open-source Git repositories.

Provisioning APIs (SDLC practices)

Provisioning APIs allow developers to script the setup of new environments – such as sandboxes, staging, or pre-production systems – with consistent configuration. This automation ensures that each environment is set up the same way, reducing the chances of errors that come with manual setups.

Centralizing all environment automation operations in one place simplifies making decisions that affect the business, permitting a quick turnover of scalability investments and impact analysis and change execution when rearranging infrastructure resources to meet new business requirements.

— Rodrigo Gonzalez, Why environment provisioning is a key part of DevOps?

By treating environment configurations as code, development teams can version-control everything, track changes, and easily reproduce environments. Whether it's product types, configuration details, or warehouses, everything is defined in files that can be stored and managed in a version control system. This way, your commerce platform’s configuration is fully documented, easy to audit, and replicable.

So, how does it actually work?

We believe that commerce shouldn’t be tied to any specific programming language or framework. From day one, we’ve embraced freedom of choice and open source values, which are now the foundations of our Commerce as Code philosophy. Only by staying truly tech-agnostic can a commerce API engine support any tech stack a company chooses.

At the heart of Saleor is its GraphQL API with a non-opinionated extensibility model. This means our customers aren’t forced into strict architectural patterns. This architecture simplifies any integration, allowing developers to query exactly the data they need and how they need it.

Commerce as Code – who is it for?

Commerce as Code is perfect for businesses that view digital commerce as a core competency and are ready to invest in growing their digital capabilities. This includes companies undergoing digital transformation, aiming to maximize revenue from both online and in-store transactions and seeking to create seamless hybrid experiences for their customers.

It’s not as much about the size of the company as its mindset toward the software development lifecycle. Whether it's a small startup with a revolutionary product or a well-established global business, it’s all about the maturity of its development teams and processes.

We’ve seen companies on both sides of the scale embracing aspects of Commerce as Code. Some of the most prominent ones, like Breitling and Lush, had complex business processes and specific user experience requirements that off-the-shelf solutions simply couldn’t meet. With an ever-relevant replatform dilemma of build vs. buy, Commerce as Code allowed them to compose the exact solutions they needed.

At the same time, Saleor also powers smaller companies exploring complex models or uncharted territories in commerce that out-of-the-box platforms can’t handle. Think about businesses with unique payment systems, loyalty programs, or custom currencies (like in-game tokens).

In essence, any company that recognizes the limitations of one-size-fits-all solutions stands to gain from adopting Commerce as Code. So far, this new paradigm seems to have the best chance of giving companies the ability to go with the times and adopt new technologies and channels, ultimately ensuring their business continuity.