Backend for Frontend vs. API Orchestration

As digital teams transition to composable and headless architectures, many rely on a pattern known as Backend for Frontend (BFF) to manage the unique data needs of different user interfaces. But while BFFs solve real problems—like shaping data for specific channels—they can quickly become unscalable in a composable stack. In this article, we’ll explore how the BFF pattern works, where it breaks down, and why a centralized Orchestration Engine and Experience API are better suited to composable architectures.

The Backend for Frontend (BFF) pattern emerged to solve a common challenge in frontend development: different user interfaces often need different data structures and behaviors. A web app might need rich product information, interactive filters, and high-resolution images. A mobile app, by contrast, might prioritize compact payloads, offline caching, and minimal API calls. Voice assistants need structured commands, not UI content. Rather than force all frontends to deal with raw backend APIs—which are often overly granular or inconsistent—the BFF pattern introduces a layer in between.

A BFF is a custom API server that sits between the frontend and the backend systems. It acts as a translator, transformer, and proxy. Each frontend team (web, mobile, voice, kiosk, etc.) often builds its own BFF to tailor responses to its unique UI and user needs.

How Backend for Frontend (BFF) Is Typically Built

BFFs are usually lightweight microservices, built using web frameworks like:

• Node.js / Express

• Python / Flask or FastAPI

• Java / Spring Boot

• .NET / ASP.NET Core

• Go / Gin

A typical BFF is deployed alongside a frontend team’s codebase or within its CI/CD pipeline. It may:

• Aggregate data from multiple backend systems (CMS, PIM, commerce, ERP)

• Perform schema transformations to flatten or reshape complex payloads

• Implement business logic, validation rules, or conditional logic

• Handle channel-specific concerns like pagination, localization, or formatting

• Cache data or batch requests to optimize performance for a specific device

In short: the BFF is where a lot of the “presentation logic” ends up living when it doesn’t belong in the frontend, and doesn’t fit into the backend.

🚨 The Problem with BFFs in a Composable Stack

In theory, each channel gets its own optimized backend. In reality, here’s what happens:

At first glance, the Backend-for-Frontend (BFF) pattern seems like a natural fit for composable architecture. After all, it provides a way to shape data per channel and abstract complexity away from the frontend. But in practice, BFFs introduce major friction in exactly the areas where composability is supposed to shine.

The core value of composable architecture is interchangeability—the ability to plug and play best-of-breed services, swap vendors, or evolve your stack over time without having to rewire your entire frontend. This is something, Sana Remekie, our CEO, refers to as “compostability”: the ability to not just compose systems, but decompose and replace them as your needs change.

BFFs, when overused or poorly abstracted, violate this principle.

Because they’re typically custom-coded per frontend, BFFs embed logic that is tightly coupled to the APIs and data contracts of specific backend services. If you change your CMS, commerce engine, or promotions system, you often have to rewrite major parts of the BFF. That creates a fragile dependency between your presentation layer and your implementation choices—and undermines the modularity that composable architecture is supposed to provide.

Worse still, as your organization scales, each new channel or region might get its own BFF, leading to:

• Logic duplication across web, mobile, kiosk, and agent interfaces

• Inconsistent business rules applied in different parts of the stack

• Complex DevOps pipelines for managing and monitoring multiple services

• Siloed teams reinventing the same orchestration flows in parallel

• Fragmented customer experience across channels

Instead of enabling agility, BFFs can become mini-monoliths—difficult to change, impossible to reuse, and costly to maintain.  You end up with N frontends × N backends worth of integration logic. And every product or feature team has to build and maintain orchestration code just to make things work across channels.  This completely undermines the promise of composability.

🧠 The Orchestration Layer: A Smarter Alternative

In a truly composable architecture, the last thing you want is to reinvent the wheel for every channel. Yet that's exactly what happens when teams lean on the BFF pattern as the default. Each team ends up building and maintaining its own backend service to connect to the same systems, apply the same business rules, and deliver the same transformations—just slightly tailored to their interface.

What composable stacks actually need is a central orchestration layer—a unified, intelligent layer that abstracts backend complexity and delivers clean, consistent, and contextual responses to any consuming interface, whether it’s a web app, a mobile app, a voice assistant, or an AI agent.

That’s exactly the role that Conscia’s Orchestration Engine is designed to play.

Instead of scattering orchestration logic across dozens of microservices and BFFs, Orchestration Engine provides a declarative, scalable environment where developers and architects can define how experiences are composed, governed, and delivered.

Here’s how it works:

🔁 Composable Orchestration Flows

At the heart of Orchestration Engine are orchestration flows—configurable pipelines that define how data is fetched from various systems, transformed, filtered, enriched, and merged in real-time. These flows are not bound to any one channel or frontend. Instead, they live independently as modular building blocks that can be reused, extended, and adapted as business needs evolve.

Need to pull product data from a PIM, availability from an ERP, and pricing from a commerce platform? You define that logic once—and it can serve all your channels.

🌍 Context-Aware Experience Logic

Orchestration isn’t just about data—it’s about decisions. With the Orchestration Engine, you can define rules that adapt responses based on context: user role, location, device type, language, even the state of the session or customer segment. This allows for hyper-personalized responses without having to duplicate logic across UIs.

For example, the same Experience API could return different product listings for a first-time mobile shopper in Germany versus a logged-in loyalty member browsing from a desktop in Canada.

📦 Unified Experience API

Rather than exposing a different BFF per frontend, Orchestration Engine provides a single, centralized Experience API that acts as the interface layer for all channels. This API is tailored dynamically through orchestration flows and rules—meaning you can support channel-specific needs without building and maintaining channel-specific infrastructure.

Each frontend, chatbot, or agent simply queries the Experience API and receives a shaped, decisioned response—no glue code, no duplication, and no channel silos.

🔄 Versioned and Reusable Components

Every component in the Orchestration Engine is version-controlled and reusable. That means changes—whether it's swapping a data source, adding a fallback rule, or updating a promotion engine integration—can be made centrally and safely, without impacting live flows unexpectedly. You get the agility of composable development with the governance of enterprise-grade architecture.

🔍 Granular Observability

A major downside of custom BFFs and distributed orchestration logic is the lack of unified observability. Debugging failures across multiple services, tracing slow API responses, or auditing decision logic can become time-consuming and opaque.

DX Engine addresses this with built-in, granular observability. Every orchestration flow is traceable. You can inspect each component’s execution time, input/output payloads, error states, and decision paths in real-time. Whether you’re debugging a failed checkout experience or analyzing how an agent interpreted a product query, the visibility is complete and centralized.

By adopting an orchestration-first approach, your teams no longer need to build and maintain isolated BFFs. Instead, they share a common foundation that’s flexible, governed, and designed for scale. Logic is applied centrally, abstracted from backend dependencies, and delivered consistently to every channel or agent.

With Conscia, orchestration becomes a platform capability—not a one-off project—freeing your teams to focus on building experiences, not stitching together systems.

🛒 Let’s Take Checkout as an Example

Imagine a checkout experience for an eCommerce brand running on a composable stack. To render and validate the checkout, you need to:

• Fetch cart data from your commerce platform

• Apply coupons and offers from a promotions engine

• Validate inventory from an inventory microservice

• Calculate shipping and taxes

• Handle payment integrations (e.g., Adyen, Stripe)

In a BFF pattern, each channel would code this logic themselves. The mobile team might hit different APIs than the web team. Error handling might be inconsistent. Promotion logic might live in three different places.

With Conscia’s orchestration engine, you define a Checkout Experience API once. It handles all the orchestration—combining logic, injecting context, applying fallback rules—and returns a tailored response to each frontend.

🪢 The Role of the Experience API

The Experience API is the final product of orchestration. It’s not a data API. It’s a decisioned, shaped, context-enriched response that is:\n

• Tuned for human interfaces or AI agents

• Free of backend-specific implementation detail

• Governed by centralized logic, not duplicated glue code

Think of it as the successor to the BFF. But instead of writing and deploying new microservices, you configure and manage reusable components in the Orchestration Engine.

🔁 From BFF to Experience-Driven Orchestration

Traditional BFF Pattern	Orchestrated Experience API
One-off backend per frontend	Reusable orchestration flows for all channels
Experience Logic duplicated across teams	Experience Logic managed centrally
Tightly coupled to backend	Abstracted, flexible integration
Custom code everywhere	Declarative, configurable orchestration
Costly to scale	Built to scale and evolve with your evolving needs.

🧩 Final Thoughts

The BFF pattern made sense in the early days of APIs and single-page apps. But in the era of composable architecture, omnichannel delivery, and agentic interfaces, it’s no longer sufficient.

Instead of building a BFF for every new touchpoint, modern teams should centralize experience logic through a dedicated Orchestration Layer—and expose it through a unified Experience API that’s clean, contextual, and built to scale.

Conscia gives you that foundation—so your stack can grow without growing brittle.