Why you shouldn’t build business logic into your frontend

When we started building Zocalo, our MACH-based eCommerce enablement tool, we brought our decades of experience as digital commerce consultants to the design process. We looked at where eCommerce platforms were 5, 10, and 15 years ago, thought back to all of the poorly built system architectures we’d been brought in to shore up or overhaul, and asked “how could those problems have been avoided?”

There are a lot of answers to that question. We knew that MACH architectures were already solving many of them, so we decided to focus on some of the inefficiencies we were seeing in the burgeoning headless space. One key culprit stood out, and became a foundational goal for what we set out to build. No more business logic in the front end.

We wanted to write a quick blog post explaining the reasons behind this motivation, both to help you understand how Zocalo is able to provide more flexibility and better scalability than other similar tools, and as a warning to future architects and developers of past mistakes.

What is business logic, and why do companies build it into the front end?

Here’s a quick summary, for those on the business side. If you can already answer the question above, feel free to skip ahead.

Business logic refers to the set of rules, procedures, and calculations that govern how a website operates. It is the backbone of any commercial application, and includes core functionality such as processing credit cards, search and browse, and field validation. In a traditional eCommerce build, this code is all in the platform backend

But in a MACH architecture, many core business functions are not built into the platform, and for those that are, any required customizations must occur outside the platform. As a result, many headless front-end accelerators build this functionality directly into their front-end codebases, making it easier to integrate the front end with the service. The idea is that this turns a two-step process (build service, integrate service with front end) into a single-step process (build front end with service). While building business logic into the front end can be a quick and easy solution for many companies, it also comes with its own set of significant downsides.

The problem with front-end business logic

While front-end business logic may seem fast and easy up front, it is not sound architecturally, which leads to inefficiencies and additional effort down the line.

Take a business with an omni-channel experience, for example. It’s almost certain that a large percentage of functionality will be common across applications—payment, merchandising, cart, etc. When you have a common function, multiple applications, and front-end business logic, you have to build the same functionality in every application. If you are processing credit cards on your website, mobile app, and in-store kiosk, you will need to build the service in all three places.

This leads to a few easily predictable problems:

• Additional effort to fix bugs or make enhancements. If an issue occurs in one place, you will have to repeat your fix in each of your applications.

• Resource limitations. he more fixes you have to implement, the more teams and developers you have to get involved.

Because the front end is inherently insecure, for any services that require submission (such as payment, forms, and more), building business logic into the front end requires additional server-side validation to ensure that the data accepted is valid and safe. This introduces a potentially redundant development effort, as validation is likely occurring on the client-side prior to submission as well.

Finally, and less significantly, building business logic into the front end restricts your coding language choices. Though we love JavaScript, it’s not the most common language to build certain functionalities in, which may create issues depending on the makeup and experience of your development team.

An alternative approach: middle layer business logic

A better approach, and the one that forms the foundation of Zocalo, is to build business logic into your system’s middle layer (aka API experience layer). This allows all systems to call a central service for functionality, and provides the following benefits:

1. One-time Build. You only need to build the service or functionality once, and all systems can make use of it.

2. Easier to Maintain. A central service allows fixes and enhancements to be rolled out to all systems simultaneously, reducing development effort and avoiding inconsistencies.

3. More Flexibility. Your front-end can integrate with whatever tools are preferred, adding flexibility and ensuring that each system can focus on what it does best.

4. Infinite Scalability. The central service can handle any number of requests, enabling easy addition of future applications or use cases.

From a technical perspective, building business logic into the middle layer also provides several benefits, such as better performance, security, and reliability. The middle layer can cache frequently accessed data, reducing the number of requests to the backend system. It can also perform security checks and enforce data validation rules. In addition, the middle layer can provide fault tolerance and high availability, ensuring that the system remains operational even if one or more components fail.

As we hope this post has made clear, an abundance of thought and care has gone into the development of Zocalo. We built Zocalo upon these principles because we quality and intelligent design is our first concern. The fastest and easiest way to launch an eCommerce site is to kick the can down the road, and pay no heed to the long-term stability and efficiency of your technical architecture. Zocalo doesn’t just make it faster and easier to build an eCommerce experience, it makes it faster and easier to build an eCommerce experience right. Contact us for a demo, or to learn more about how our platform can help you build scalable and flexible eCommerce solutions.