all news

Headless Approach. The next necessary step in ecommerce?

September 18, 2020
Headless Approach. The next necessary step in ecommerce?
Stanislav Publika
Technical Director at Astound Commerce UK

To meet the needs of our clients, we as a company have always employed cutting-edge technologies. We are using Progressive Web Applications — a set of development approaches allowing us to create a single page application directly on the web, are considering a new role of a Site Reliability Engineer, and are planning on implementing DevSecOps as a practice.

That is why it shouldn’t come as a surprise that Astound Commerce is looking forward to welcoming the Headless approach.

Acquisition of Mobify by Salesforce is another indication of rapid development and step in the direction of Headless ecosystem. The approach described below is based on our research of the recent months and will continue to evolve depending on marketplace dynamics.

How is Headless different from traditional architecture?

First off, let’s figure out what traditional, or monolithic architecture is. You’ve got one platform that takes care of lots of things at the same time.

The traditional architecture includes your ecommerce engine, promotional engine, storefront and your CMS — it’s an all-in-one solution — a silver bullet for the entire ecommerce world.

However, the trend for microservice architecture and the concerns in traditional architecture has brought us to new thought — that every part of the solution needs to have its API. And, each component can be either used or replaced with something else which would implement the same functionality, but in a better manner.

Enter, Headless.

It’s a set of microservice architecture concepts which would delegate to every single API its role. In ecommerce, those APIs would be the product, catalogue, basket, inventory, pricing, and so on.

And, when we are saying that there is a Headless third party, we mean that just APIs are available to us and we have the freedom to define the rendering of information provided by those APIs. The place where all of this rendering takes place is the head, and the Head in ecommerce would be an actual frontend application which implements storefront by using those headless APIs and render them in the way business would expect.

So, to bring it all together,

Headless is the architecture concept which comes to solve the problem of traditional architecture being too monolithic by separating the APIs and storefront deployment.

Can backend and frontend developers work independently in Headless environment?

Technically, your backend is some third-party platform handling the “heavy lifting” — the logic which introduces business value to the end customer. And, your frontend, responsible for what the end customer will see on the site, is located in the head.

These parts can be customised independently.

There is a pitfall, however.

Typically, to build the storefront head, there should be some backend which would support the client-to-server kind of calls to another backend. And not in all cases the respective Headless platform provides the backend.

For example, Commerce Cloud supports only server-to-server communication with their API, and no calls can be performed from the client’s side to the Commerce Cloud directly.

That’s why we need to introduce some layer in the middle.

Backend for frontend architecture pattern ensuring clean separation of the concepts as well as providing flexibility and unification on the backend integration. We are introducing the API gateway between our Headless platform and storefront head, and that gateway becomes our actual backend. BFF is represented by a separate application enabling frontend developers that are developing the storefront head to work independently from the backend developers who are handling BFF application.

Would we need two separate places to deploy the frontend and backend?

There are several ways available to deploy headless architecture. Two approaches generally classify them as deployment as a managed service and cloud-native “vanilla” deployment.

Deploying Headless as a managed frontend service

Managed frontend service is an alternative deployment option, where a 3rd-party company manages responsibility for deployment, scalability, availability and other infrastructure-related concerns. That leaves us with a more explicit focus on the delivery of the features and enables a more rapid approach in delivery.

Vanilla Headless deployment

In this case, we’re left with a set of APIs and a storefront that needs to be deployed somewhere. Most likely, it will be a distributed deployment where we would get two parts — backend for frontend and the actual storefront head part.

To help with the distribution of deployments and the number of non-functional requirements, we would be using Kubernetes & Docker for proper orchestration and deployment within that environment logic. One of the pitfalls of this is whenever you foresee the change on some of the other systems that have to be deployed, then the deployment itself needs to be well-coordinated. For example, suppose you’ve got deployment on your ecommerce platform, and you have a dependency on your storefront. In that case, that may require coordination and management of a few teams, which leads to additional risks and operational overhead.

How would we perform integrations in case of Headless?

At the moment there’s a lot of various opinions going around in the Headless world on where a payment system should be integrated, for example. Here they are:

1) 3rd-party services should be integrated directly with the ecommerce platform

Ecommerce in this architecture is supposed to do the most “heavy lifting”. And, payment providers wouldn’t be the easiest ones to integrate and managed within the storefront head.

2) 3rd-party services should be integrated directly with Storefront Head

This would bring all the storefront integrations into one place so an ecommerce platform would be less of a concern or dependency for integration.

This approach may open up new opportunities and flexibility in future. Let’s say the customer has decided to change the ecommerce platform. In that case, we’re just changing the ecommerce platform, and all of the integrations that have been done on the Storefront Head side will remain untouched. And this is to the benefit of the client because they don’t need to change much in the integration logic on the storefront.

3) Integration should be distributed between the ecommerce platform and Storefront Head

Integrations like tax providers or authorisation verification need to be presented as an option within the ecommerce platform as it’s the best place for the “heavy lifting”, but there also should be a different place for handling the extensibility layers itself.

For example, you’ve got your payment service provider, and it usually would be separated and consist of two parts.

One part — the actual backend logic to perform let’s say authorisation calls, and it would seat into the ecommerce part.

The other part — the logic for the client-side encryption, for example, and the javascript trigger of the payment process would sit in the storefront head. This solves the “heavy lifting” problem but doesn’t solve the problem of distributed deployment.

So, this is the grey area at the moment for most of the headless ecommerce solutions as there are no defined global integration strategies.

When updating partner apps, if compared to traditional architecture, how easy would it be to make these changes?

There are two parts to the whole Headless story — one would be the backend for frontend, and the other – storefront head itself.

Most of the time, in the Headless architecture, you would be integrating directly with Headless platforms.

And as there are already APIs available, probably there’s not much change that needs to happen on the storefront head or even on the backend for frontend side of things.

However, if it’s required, you’re either upgrading the backend for frontend or storefront head or upgrading them together which still lives in the same bucket of changes within the single deployment. And we are performing it as part of the release management process.

In the case of the traditional architecture where you upgrade some part that is relevant to the integration of one particular channel, we would have to redeploy the entire thing which would mean we would have more risks during the releasing that code to the live environment and more dangers for regression.

Headless architecture, in general, is created to distribute and mitigate all of the risks related to the regression of the app itself, so it enables you to update only the particular required piece of the code that will be responsible for the specific integration.

SOAP and REST are protocols used to communicate between different applications. What would Headless use for integration?

In reality, both REST and SOAP can be used in Headless architecture.

On top of that, the Headless world is considered super modern, so it would try using the latest available protocols for communication — GraphQL, for example, which is also based on the REST.

That’s the main flexibility point. We will be able to integrate with any system with any communication interface, as long as our infrastructure does support it.

So we are not limiting ourselves to only REST and SOAP as well as to GraphQL, and that opens up the Pandora box for us, on the one hand, because we might venture out on some new integration method we’ve never tried before, and that involves risks. On the other, it provides us with the maximum possible flexibility when performing the integration as we get control of what our infrastructure will be.

Is Headless secure when we compare it to traditional architecture?

In traditional commerce, all the known vulnerabilities would be already studied, while in the custom deployments like Headless they may be a bit invisible to us.

However, a lot of security risks are mitigated by design.

Normally, when we are talking storefront head, it shouldn’t contain any storage in it — it should be kind of a proxy between the end customer and the Headless API that’s been provided to us. And under such conditions, it’s making it harder to mess up with the security but doesn’t mean it removes all the risks.

So, with Headless architecture, there is a bigger liability shift in the ownership of the security concerns, especially for the storefront head. And, to mitigate it, most of the time we would be doing a lot of the black box and penetration testing before the release. While in traditional commerce, we will know the specific places where exactly to test. However, since the scope is still limited by the fact that we are not storing anything other than probably the caches, that part is minimised.

At the same time, all of the Headless platforms that we might be leveraging will be responsible for their security insight. Most of them are also using somewhat of a SaaS model, and they have managed API services, so they have a direct responsibility on the way they are providing and delivering those APIs.

What kind of Merchants can choose the Headless approach?

At the moment, there are two different thoughts on the market.

One is — that Headless is for everyone and the other one — that Headless is for everyone ready for Headless.

To run Headless architecture, you need a proper IT infrastructure built within your organisation as a merchant.

This is attributed to the following:

  • there are a lot more dependencies on the deployment,
  • a lot more liability on the security,
  • a lot more control of how the system will perform overall.

Meanwhile, the SaaS ecommerce cloud will be doing everything for you. However, it might be a matter of time, and it all depends on how the Headless market will mature itself.

At the moment, the best-case scenario is when the organisation that wants to run the Headless architecture, will have those IT capabilities within the organisation.

However, in the not yet predictable future, more and more companies might be able to supply the Headless architecture as a managed service as well. So, for example, a company like Astound will provide that managed services on the performance, scalability, resilience, and so on, and it will be fully managed within one single point of contact for the end client.

What architecture to choose — really depends on:

  • the constraints of the architecture;
  • how outdated the merchant’s current systems are;
  • how ready the organisation is for the change.

Headless is not only the distributed way of building things, but it’s also the way to organise the company into different departments.

For example, naturally, if you’ve got the ecommerce department, that will be in charge of merchandising and marketing campaigns, you would need to have a separate CMS — content management division, that would be looking after your content. Not all organisations are ready for that because it brings some additional problems like operational overhead since people need to work in different systems.

But what needs to happen on the organisational level, those concerns need to separate from each other and organically grow as separate departments, as well as the IT department which is quite central to managing the deployment of thе storefront head itself.

What are the other platforms approaching Headless architecture?

There are plenty of traditional commerce providers that are moving towards the Headless world like SAP Hybris and Shopify Plus, which are also well presented as the Headless backend provider. As for the non-ecommerce providers, there is, for example, Amplience, who provides a digital asset management solution for our clients — they are also going to move to the Headless architecture because it’s so trendy at the moment.

Do you want to become part of our team?

Check our open vacancies
Share via:

By continuing to use this website, you consent to the use of cookies in accordance with our Cookie Policy.