DXO | What's in a Name?

In the immortal words of Shakespeare:

What's in a name? that which we call a rose?

By any other name would smell as sweet;?

As beautiful as this sounds, when it comes to explaining technology concepts, terminology makes all the difference.? The devil is always in the details and you may end up with a fake rose if you are not careful.

In many mature enterprise architectures, your engineering team will end up building a layer in between the frontend and the backend, to cater to the unique requirements of each type of client, such as mobile, web, or desktop.? At a high level, this layer acts as a gateway, aggregating data from various backend services and transforming it into the optimal format for the client.?

Depending on who you talk to, you may hear the following terms that describe this layer:

• API Middleware
• Experience API
• Orchestration layer
• Abstraction layer
• Gateway
• Backend-for-Frontend (BFF)
• Service Facade

For the purpose of this article, we'll use the term BFF. Here are some of the primary functions of a BFF:

1. Data Aggregation: A BFF gathers data from various services, combines it, and then sends only the relevant information to the client. This helps reduce the amount of unnecessary data being sent and allows for a more efficient experience.

2. Request Translation: It translates the frontend requests into corresponding backend service calls. It acts as an interpreter between client-specific requirements and the standard APIs of the backend.

3. Response Transformation: The BFF transforms the responses from the backend services into the exact format the frontend needs. This is highly beneficial when there are different clients with unique requirements.

4. API Orchestration: The BFF integrates multiple services, combines data and functionality from multiple backend services, allowing the client to obtain all the information it needs through a single request.? It manages the order and dependencies of different API calls, ensuring that they are executed in the correct sequence and that any dependencies between calls are respected.

5. Authentication and Authorization: BFFs can handle security-related aspects like user authentication and authorization, ensuring that the users have proper permission to access the necessary data or perform certain actions.

6. Error Handling: By acting as an intermediary between the frontend and backend, the BFF can handle errors in a more centralized manner. It can translate backend error codes into user-friendly messages or handle retries for temporary failures.

7. Performance Optimization: Tailoring the responses for specific clients allows for optimized performance. For example, a mobile client may require less data or different data formats than a web client, and the BFF can accommodate those needs.

8. Decoupling Frontend from Backend: BFF allows frontend developers to have more control over the backend logic that is specifically tied to the UI. They can iterate quickly on the frontend without being tightly coupled to the core backend services. This concept is also referred to as ‘abstraction’.

The Challenges with Building Your Own BFF

Time, Money and Resources

Handling these key functions of an application is quite a big responsibility and having to build this layer for each frontend is an onerous task.? BFF is essentially just another application that is traditionally written in code, is deployed on your own infrastructure and is your responsibility as a brand to maintain for each of your frontends.? Whether you use GraphQL to develop this application, buy proprietary software such as Mulesoft or embed the logic into your frontend code, you’re writing tons of code and spending a lot of time and resources.

BFFs are Opinionated

A Backend for Frontend (BFF) pattern serves as a unique gateway for each user experience. It allows the client-side user experience (the frontend) to communicate with a tailored backend that serves its specific needs.? BFFs by definition are highly opinionated and hence are tailored and customized to support the specific requirements, functions, and features of a particular frontend application.

For this reason, it’s not a one-size-fits-all solution; instead, it expresses strong preferences in terms of how it communicates with the backend, the data it expects, and how it structures the data to serve the frontend. This means that you need to build a brand new BFF for every digital product. Also, if you want to modify the backend data sources or the logic required to send data to the frontend, significant code changes may need to be required to the BFF.?

You have to manage and deploy BFFs

While BFFs provide the agility to tailor backend services to specific frontend needs, they also introduce additional overhead in terms of deployment, management, monitoring, and continuous improvement.? For instance, ensuring that a BFF can adapt to increasing loads and demands without losing performance is a critical aspect of its design and deployment.?

What if you could get all of the capability of a BFF, but without the hassle of building it from scratch?? What if instead of building your BFF for every frontend, you could configure it with atomic logical blocks that have the capabilities that end up coding over and over again every time.? How much faster could you innovate if you could cut your time to value to a fraction of what it would take to build your own BFF.?

A DXO is a BFF on Steroids

Digital Experience Orchestration (DXO) offers all of the capabilities I’ve mentioned above, but goes a few miles further:

• Real-time decisioning based on business rules and logic configured by marketing and business teams.? This means that you can incorporate personalization and A/B testing right into your composable stack.? Traditional BFFs (Backend for Frontends) are built for and managed by developers and have no provision for marketing teams to have operational control over what content is fetched for what customer from what backend systems.
• Facilitate connections to any backend API using a universal API connector, eliminating the need to write or construct code.
• Enhance the performance of your user experiences with a caching layer and a globally distributed edge network.
• Observability and monitoring of backend APIs and services

So, this is why I call this middle layer of the composable stack ‘DXO’ - as you can see, the existing terms simply don’t do it justice - after all, the brain of the composable stack deserves a label of its own!