Woman looking at her phone

Fast-track e-commerce experiences with Bridge

21 January 2019Mateusz Luczak

In order to deliver an exceptional e-commerce experience, you'll need to combine and surface multiple back-end services. Finding the right architecture is key to success. 

From a technical point of view, these services may be internal, like retrieving information from a centralised product information management system, or external, like an integration with payment providers. Combining these services allows customers to shop in the fastest and most convenient way. However, an e-commerce experience is not just about the purchase, the shopping experience requires content that builds engagement with the customer. So, from a technical point of view, an e-commerce solution is often integrated with a content management system.

An integration of this kind brings various technical challenges, such as the authoring of product pages, referencing product information on content pages, implementing the shopping experience, introducing a caching strategy or the personalisation of offers.

If the architecture is poorly designed, the performance of the experience will suffer. Integrating multiple services and systems increases the risk of reduced throughput or response times as the complex system is only as fast as its slowest link. Relying on the CMS for fast performance is not the smartest move. Here I'll explore the things you need to think about when planning an e-commerce (or other multi-service solution) integration if Adobe Experience Manager is your CMS of your choice.

The right architecture drives success

Performance related issues in a multiple services ecosystem are often related to solution architecture. Undermining the importance of solution design in the early stages of the platform implementation can lead to shortcomings during the in-life phase. Given that not all of the challenges you'll come across have out-of-the box solutions in Adobe Experience Manager, it's easy to miss the bigger picture during implementation. But a poorly designed architecture can have serious outcomes. Apart from maintenance and development issues, from a customer perspective, longer response times might mean aborting a decision to buy. Just over two seconds is all it takes for a customer to quit a   page and possibly never come back.

Architecture using AEM back-end as integration layer

With Adobe Experience Manager the recommended infrastructure is designed for performance. It provides horizontal scaling and dispatcher caching to serve a best in class user experience. Most of the recommendations depend upon the high cacheability of AEM pages. Requesting AEM to fully render pages should be avoided where possible. But this can be difficult when a page features dynamic data integrated from other systems. Things like recommended products or pricing may change frequently when they are coming from an external service.This will invalidate the cache and can impact performance. One way to maintain high cacheability with dynamic data is to move the integration point beyond AEM.

Use middleware to improve performance

Building integrations on the back-end of Adobe Experience Manager is probably the easiest solution for the developer but, as stated above, it brings various challenges. AEM scales well horizontally - by adding more instances - but this kind of infrastructure gets harder to maintain and application deployment can become a challenge in its own right. Additionally, horizontal scaling has its limits and is not reasonable if the scaled piece is an entire CMS instance instead of a particular feature or module that is a bottleneck. To break free from these limitations, integration points can be moved to a middleware layer; an additional solution in front of the content-serving back-end that collects data from services and combines them with content from a CMS. This way the AEM page remains static and can be fully cached when it leaves AEM, before that solution adds dynamic data on top of it. 

The addition of a middleware server to stitch together data and content can result in 100 - 1000x times higher throughput for rendering dynamic pages on a standard AEM infrastructure. This means a reduced load time in both low and high traffic scenarios. You should check out the Cognifide supported open source solution, Knot.x. This can be used as middleware to optimise the rendering pipeline even more. Data stitching on middleware is a great fit for e-commerce solutions which are often headless. It can also extend to other solutions where there is dynamic data present.

Boosting performance without compromise

No matter what architecture you use or what services need to be connected, there are concerns associated with integrations using a content management system other than just performance. Changing a technology stack to introduce middleware needs dedicated planning and design to make it 'play nicely' with Adobe Experience Manager. In an ideal world, the architecture driving the solution would be transparent for authors so they see no difference in page authoring and have the same WYSIWYG experience that they are used to.

Architecture using middleware as integration layer

It's easy for a business to focus on the experience performance and forget about the author or developer experience which does not directly impact revenue. However, if you are looking for an out-of-the-box solution that, with minor development effort, will give you everything:

  • high performance
  • connected AEM pages with dynamic data and services
  • an authoring experience that is visual and intuitive

then our product Bridge is something that you should look at.

Bridge to the rescue

You can read about Bridge as a concept in a previous blog post. But to briefly define it, Bridge allows external data  to come from any service inside AEM components without development effort (after some initial set up work). There is no need to 'teach' your component inventory how to consume data as it is treated in the same way as regular content, provided by authors, not by developers. Bridge offers exactly the same revolutionary authoring experience whatever architecture surfaces the data on AEM pages. The back-end is based on AEM, the middleware or, soon-to-be front-end, is supported out of the box. The default middleware implementation uses Knot.x, but could be easily customised if you would like to use different middleware.

Next time you are planning new (or redeveloping existing) architecture for your e-commerce based on AEM, or for other solutions combining multiple services, think about the benefits of extracting data from AEM to middleware. And, if you care about the author experience, consider Bridge. Feel free to email me for more information or to receive the Solution Brief document for the Bridge.

Author: Mateusz Luczak
Published: 21 January 2019
digital platformscustomer experienceCMSAEMContent Agility

Job Opportunities

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