Why A Custom Front-end Might Not Deliver the Benefits of Going Headless

While a headless architecture can provide many benefits, it’s not a magic bullet and must still be executed correctly to maximize success. If you’re considering custom building a decoupled front-end then it’s important to ensure that you’re effectively planning for the longer term. Retailers and brands that prioritize getting the quickest, cheapest build often hurt themselves as their sites that become difficult, slow, and expensive to maintain. 

Retailers and brands are navigating the path to a headless because of the agility it affords. It provides the freedom to experiment often and make changes quickly, adopt new functionality easily, and add new touchpoints to keep up with customers. Let’s first explore how this compares to a monolithic  architecture.

Agile vs. Monolith

In a typical previous generation technology stack for ecommerce, a retailer would use a single technology to deliver commerce functionality (order processing, stock management, account management, promotions, etc), some CMS functionality, and possibly personalisation. The functionality would be delivered already wrapped into an HTML presentation layer so that the two were bound together in a single monolithic system. 

While this monolithic architecture can have some benefits, problems soon arise. 

  • Adding functionality via 3rd party tags that’s not supplied by the original technology usually breaks the architecture.
  • The user experience code often requires more frequent changes than elsewhere in the system but the whole system needs to be rolled out every time which takes a lot longer.  
  • To get new features requires an upgrade to the next version of the monolithic technology and these major upgrades are often lengthy and expensive. 

In an agile system the various layers of the technology stack are decoupled. This means that each individual layer can be modified significantly without impacting the other areas of the system. In this way we can break up a complex system into areas such as commerce, content, UX, search, etc. There are numerous advantages to this approach.

  • Frequent updates to the UX layer are possible without requiring changes to the backend system. 
  • The UX team only need front-end skills and don’t need to work with the backend technologies
  • Conversely, backend functionality can be replaced while maintaining a consistent UX layer. 
  • Individual components of the system are able to be easily swapped out, allowing a retailer to use ‘best-of-breed’ for each area of functionality.
  • The system is designed to constantly develop and evolve, removing the need for lengthy, expensive major upgrades.

The Role of APIs in Building a Decoupled Front-end

We’ve discussed the benefits of decoupling, but how is this achieved in a modular technology stack? Ideally we need to minimize the dependencies between the individual modules. The typical approach to doing this is by creating a contract which defines that depency. In programming this is called an Application Programming Interface or API. 

An API defines the commands that a module supports. It defines the names of the commands, what data they expect, and what data they will return. Importantly it does not define any details of how these commands are implemented. The inner workings of the module are abstracted away and said to be encapsulated. This is important because the module, like most software, will probably change over time, but as long as the commands are still supported, these changes will not break the rest of the system. A module can also be swapped out for another module which provides the same services. 

To give a perhaps more tangible example, the idea of modularity and abstraction happens all the time in the real world. Landline phone systems changed over from analogue to digital without us having to change the handsets or the way we use the phone. Car systems introduced traction control and ABS (anti-lock braking system) without us having to replace the steering wheel or brake pedals. 

How to Avoid the Pitfalls When Building a Custom Front-end

Even the most elegantly architected projects are subject to external pressures, not least of all time. Ensuring your custom front-end is truly decoupled from your backend typically takes more time and more code in the initial build. For expediency’s sake shortcuts are taken. In the short-term this is often a simple fix, but it breaks the modular pattern by using some internal aspect of a module. Maybe this is done with the idea of fixing this in the next release, but then further time pressures mount and more functionality is needed and so on. This is how elegant modular architectures can slowly evolve into highly interdependent monoliths. If the UX code is reliant on commerce details specific to a vendor, then that modular aspect is lost and you have a tightly coupled project. 

Furthermore, the site often grows in unexpected ways, and as a result, a lot of ‘point solutions’ become prevalent in the code. Again, these undermine the central architecture and increase the complexity and interdepencies within the code. 

Once this project becomes tightly coupled, a lot of the benefits of headless disappear. 

  • High levels of interdependent code mean that small functionality changes ‘ripple out’ and require lots of code to be changed. This slows down deployment frequency.
  • Interdepencies between modules mean they are intrinsically tied to each other and it becomes difficult and expensive to replace individual modules.

When considering custom code, it is far more important to consider the long-term maintenance overhead rather than simply the initial build costs and times. 

Front-end Platform as a Service

Mobify’s Front-end Platform as a Service has been designed specifically to support and promote modular development of a modular architecture. Specifically, it provides programming interfaces that allow the user experience code to make calls to the commerce engine, content system, or other backend applications without requiring details of the implementation. This ensures your architecture is decoupled and you can easily swap out modules as needed. 

If you’re interested in learning more Mobify’s Front-end Platform as a Service, contact us and we’d be happy to answer any questions. 

Leave a Reply

avatar
  Subscribe  
Notify of
Resource ad

Subscribe to the Mobify Insights Blog

Stay in the know on the latest in mobile commerce so you can effectively engage your customers and drive revenue.

Related Articles