With the rise of headless systems, during therecent years, traditional CMS and traditional e-commerce vendors extended their existing products with (mostly) RESTful API endpoints to able to connect different head applications. This article will show an example of how a CMS andan e-commerce system can be connected, to solve the limited content editingoptions in an e-commerce system.
‍

The problem

Our main driver was to solve the lack of content editing in the e-commerce environment. E-commerce solutions usually provide only limited functionality for content editing; therefore, the client must involve the development team to make changes on the site if content editing limitations are reached. Part of the problem is the rigidity of page structure editing, for example reordering the components on a product detail page is problematic, because the structure of the product details page is hardcoded and defined by the implementation and not changeable by editors. Our goal was to solve the content editing limitation problem, using a CMS as a composer to enable flexible page editing.

Let us take a deeper look on how nopCommerce with Umbraco CMS can solve this problem.
‍

Umbraco Content Delivery API

In the beginning of this summer, Umbraco officially released the Content Delivery API, which is a collection of RESTful API endpoints to retrieve content, which can be deployed to Umbraco Cloud or on-premise. Although, Umbraco already has a headless product in the market for years,called Umbraco Heartcore, but this service is only available as a SaaS (Software as a Service) product, which is not an option unfortunately for all clients. I also would like to mention a community extension, which we explored before Umbraco released the Content Delivery API.  This library was a great starter for us at Allwin to explore the possibilies with Umbraco headless, although I would not recommend usingthis library since Umbraco has the official free Content Delivery APIavailable.
‍

NopSuite Frontend nopCommerce Web API

nopCommerce has an official headless plugin, but there are other available headless plugins, such as NopSuiteFront-end API for nopCommerce which is available for free. The plugin contains a Postman collection and a swagger documentation page which helps to explore the API endpoints – it contains more than 200 endpoints.
‍

The wedding 💍

Our plan was to grab the two systems and make a stable long-living marriage by complementing each other. Just like in and old-fashioned marriage we defined the roles for both systems.
‍

Umbraco – responsible for presentation:
‍

• Page structure – sitemap and navigation
• Layout – which components toshow on a page
• Non-commerce related content – e.g.,marketing content
  ‍

nopCommerce – responsible exclusively fore-commerce functions:
‍

• User authentication
• Product catalog
• Product search
• Order management
• Payment
• Cart management
• Checkout
  ‍

Based on the responsibilities above, it’s obvious that the e-commerce solution has a dependency on the CMS because CMS provides the base of a website. Let’s look at an example of how a page gets composed in the background using the two systems.

In this case, the Next.js component is our head application which processes the RESTful API responses and render it in the browser. So, let us define the responsibility of the Next.js application:
‍

In this simplified example above, we have 3 components on the page. The Header and Footer are pure CMS components, meaning there is no connection to nopCommerce, all the shown data is stored and provided by Umbraco. The Product Catalog component has a connection to nopCommerce to retrieve product data, and has a minimal connection to Umbraco, because the component itself should exist in Umbraco. The main concept here is that components are self-defined, meaning that the CMS does not need to know what the components are doing. The CMS needs to only know that there is a component called Product Catalog but actual implementation of the component isin the Next.js head application.

Depending on the requirements, the last point of the Next.js head application roles (“Connecting the responses of the CMS and the e-commerce”) can be extracted to another API layer if there are multiple heads, for example mobile applications.

‍

Drawbacks

Because of the nature of headless, the page editing experience is dependent on the vendor’s solution. In theory, the headless CMS does not know anything about the head application, therefore the WYSWYG editor is not available for most of the headless Content Management Systems. Although, preview functionality is provided by most of the vendors where editors can review their changes on a page before publishing.

‍

Conclusion

A CMS driven e-commerce solution can solve the content and page editing problem for an e-commerce system and the head application can be based on a selected technology independently from the CMS or e-commerce framework. The shown example is not the only way to solve the mentioned problem, but this is a good example how headless solutions can be beneficial for even a simple a web shop.