woman online shopping in a cafe

Pamper customers and content authors with the SPA experience

05 June 2019David Friar

Some exciting results from our work on AEM and Magento, including a brief and almost true history of CMS and eCommerce integration.

The story so far, dot, dot, dot

In the past, we lived a simpler life. Perhaps you wanted to sell stuff online, and you also wanted to publish some inspirational content. You wanted product listings and product details and shopping baskets, and you also wanted to spin the backstory of your brand and drive traffic towards your product pages. So you bought an eCommerce engine and you bought a Content Management System. Somehow you bolted them together so that to your users they appeared more or less like a single site.

The eCommerce engine managed the transactional stuff, handling orders and shopping baskets and so on. It probably also came bundled with some kind of 'shopfront' web application which handled displaying your product catalog pages as well, allowing your customers to browse and search and filter and then leading them through the checkout process. Your content management system allowed business users to create some great content for the other pages on your site. Your "integration" between the two systems probably just amounted to having a few links between pages served by one system and pages served by the other (and hopefully you managed to make the pages served by each system look more or less the same).

 

There may be trouble ahead

The trouble was that your marketing people started to see some real benefits from the content management system, and everyone started to use phrases like "marketing agility" and "content velocity". Making changes to content-driven pages was easy, took a matter of minutes and didn't need the help of a development team. People started to question why, if they could change the content and layout and images on a content page so easily, they couldn't do the same with the product listing and product detail pages. Perhaps they also asked why it was that the article they wrote in the CMS about the product was still showing last month's price, which didn't match up with the product detail page.

And so began the quest for integration...

Your eCommerce engine loses its head

To cut a long story short, one of the most successful approaches to solving this is what has become known as "headless eCommerce". The idea is that you dump the 'shopfront' site that comes with your eCommerce engine and make the content management system solely responsible for serving all of the pages on your site. The eCommerce engine becomes a pure provider of data, typically by exposing a RESTful API that provides product and transactional data, often in JSON format.

Adobe AEM SPA Overview

This is nice from an enterprise architecture point of view because in this API-driven approach your product catalog and the associated commerce functionality is no longer confined to its own little silo. Your architecture is open to extension. You can add new channels like a mobile app or a talking fridge magnet without reworking everything else.

Getting this right technically can be challenging. In particular, if you do all of the integration between your headless commerce system and your CMS on the server side you run the risk of hitting performance and scalability issues, especially if your product catalog is large. Moving some or all of your integration to the client side, via 'Ajax' calls directly from the browser to the commerce system, is one way forward.

But the huge win here is that now you can use your CMS to edit your shopping pages in the same way as you do for your editorial content pages. You can rapidly tweak and improve the customer experience of the core shopping journey. And that, as they say, is where the money is.

So a headless eCommerce architecture gives you the agility to rapidly evolve the experience you offer to your customers. But when it comes to your customers' experience, what exactly are you trying to achieve?

I don't know what I want, but I want it NOW!

It's not the whole story, but when it comes to web experiences, client-side performance is really, really, really important. Milliseconds matter, and if you offer a web experience that feels smooth and slick, people tend to buy more stuff. It's as simple as that.

Part of the problem here is the way that the web typically works. When you click on a link on a web page, your browser will send a request for the next page. This typically involves a number of network calls and a whole lot of work to be done by the browser in order to render the page when the results come back. In computer terms, this takes ages. In human terms it's also a pretty significant amount of time. We make mental allowances for this. We tell ourselves, "It's a website, not an app". We lower our expectations, we swallow our pain and frustration, and after a while we forget that it doesn't have to be this way.

Adobe AEM SPA Overview

But now we see the evolution of a new class of web experiences, the Single Page Application or "SPA". We build our application so that it runs entirely within the browser, typically with a modern JavaScript framework like React or Angular. We run both our CMS and our eCommerce engine as "headless" services, providing pure data to our app. We can load as much content data as we like when the user first loads our app and we never need to request and render an html page again. Navigating around our app, when we already have the "pages" loaded, is blazingly fast. Our users can browse faster, find our products faster, give us their money faster. Everyone is happy.

Adobe AEM SPA overview

You can't have your cake and eat it

As they say in Italy, “you can’t have a full bottle and a drunken wife”. SPAs can offer an excellent customer experience, but there is a tradeoff, and possibly not quite everyone involved is truly happy. There's often a distinct downside, when it comes to "authoring experience". Typically, in an SPA scenario, your CMS will be running as a 'headless' system, delivering content as JSON data to your client side application. Often, this will not provide authors with a view of how the content they are creating will actually look when it's rendered by the application. What's more, the ability to make changes to the way the content is rendered will most likely be compromised, as changing the client-side application will likely be a developer task.

Correction: there's plenty of cake

Actually there is a way to square this particular circle, and it's one of the coolest new features in Adobe Experience Manager. The AEM SPA Editor framework, launched in AEM 6.5 (and available in a service pack for 6.4) allows AEM to deliver sites as single page applications whilst still maintaining the superbly intuitive drag and drop editing capabilities for which AEM is well known. Just as with an ordinary site, authors create pages by dragging components onto pages and editing them. The components in this case have both a backend part and a part that runs on the client side, implemented either in React or Angular, two of the most popular front end frameworks. Page content is served as JSON data, and some very clever plumbing in a client library provided by Adobe uses your front end components to render the page. As with 'normal' AEM, the view that your author sees is very similar to the view that the customer sees, enhanced with tools that allow the page to be edited.

This has the potential to be a game-changer. Not only does this give us the potential to deliver an excellent experience for both customers and site authors, it also makes integrating with other services (such as our eCommerce engine) straightforward and easy to deliver in a scalable and performant way. So we asked ourselves the question that we always ask about cool new features in AEM... does this actually work and can we use it for a real project today?

Show me the working software

It's all very well to talk about this stuff but at Cognifide we believe that a working application is worth a thousand words, so, along with our colleague at Wunderman Thompson Commerce, we built our own example shop as a proof of concept. We took the Magento eCommerce engine and configured it to expose a RESTful API. We used the new AEM editor capabilities in AEM to build a set of components using React, the front end framework of choice for many web developers these days. Finally, we threw in a little Cognifide magic of our own for good measure, a thing we call Bridge, which adds even more "authorability" to data driven AEM sites.

It turned out rather well. We're impressed with the Adobe SPA editing framework and we see this as an architecture which can bring significant benefits to our clients. (We're also quite impressed with ourselves for pulling this off on such a tight timescale with such a small team).

content pages

We'll be following up very soon with a more technical blog post with details of how this works under the hood (spoiler alert: we really like this technology).

In the meantime we'll be showing off the fruits of our labour at our XChange event later this month. To read more about XChange and register to attend click here.

To download a paper from our Wunderman Thompson Commerce colleagues on Headless Ecommerce with Adobe AEM SPA Editor click here.



 


Hero image by Brooke Cagle



Author: David Friar
Published: 05 June 2019
Tags:
Adobemarketing technologyretailtechnologyuser experience
 

People in or team love to share their experience. Explore our blog

Job Opportunities

We're always looking for new faces to join the Cognifide family. Take a look at our available jobs.