Blog Posts French Process Management

Composable commerce — Legacy management and progressive migration

Blog: Smile - Le blog des consultants

Composable commerce — Legacy management and progressive migration

My last application and me.

Where you probably stand from

A spaghetti architecture with data everywhere, resources are tightly coupled, evolutions are limited due to your systems’ complexity, so your developer experience is terrible. Too much domain knowledge is required making the platform harder to maintain, but also, it’s getting hard for developers to onboard as a result of your velocity slowdown.

Why do we need BFF architecture?

A Back End for Frontend is a single-purpose edge service for UIs and 3rd party solutions

According to Sam Newman, author of Building Microservices

This approach is also an organizational change as we will rely on a clear separation of concern between teams.

The application is faster as it’s lighter

The developer experience is better

Legacy migration

Back to our spaghetti plate, it’s time for progressive change, and Backend For Frontend is one approach used for legacy migration, but how does it work?

We will have to re-architect the legacy system and switch from a legacy system to a new one more seamlessly with a Backend For Frontend pattern.

This logic is instrumental in moving the business logic away from the frontend and backend by manipulating resources from the source of truth, either with the legacy or the new application to connect with.

An approach could be to build a GraphQL endpoint to get information from various data providers and aggregate it for the consumer without over-fetching as the query is done by the frontend.

It allows complete flexibility in building new features and dealing with legacy systems.

Using GraphQL for API Aggregation
Composing schemas declaratively with federation

If you want to dig more into that approach, you can have a look at Netflix DGS.

Resource and developer experience

How do we break a monolithic enterprise application into smaller pieces to assign teams to them, and then how do we connect those pieces?

Adding an abstraction layer between backend systems and frontend allows to ease the developer experience and resource consumption:

As an user I want to see my customer informations

  1. Applications describe their requirements:
    User story: As a customer application, I want to fetch customer information.
    Key advantages: Decoupled frontend apps from our data by fetching discoverable data without over fetching, so you drastically reduce the codebase by removing the business logic.
  2. BFF — Graph functions as an auto described marketplace of data and services,
    User story: As a BFF, I fetch and aggregate data from various data sources (new or legacy)
    Key advantages: unifying the business logic across defined channels, flexible migration between two sources of truth, ease to integrate new components.
  3. Resources — Service describes their capabilities.
    User story: As a resource, I display a range of information with a defined TTL.
    Key advantages: Remove or keep data clean without specific per channel data or formalism

With the described architecture, you can split your development team into different layers: Frontend, BFF/Middleware, Resource.

This approach allows a progressive migration to break its functionality out one service at a time, enabling different teams to work on various products and features without interfering with one another even if the end resource is changing or not ready.

Also, splitting down an application with a domain-driven approach reduce the amount of technical & business knowledge to onboard new developers, so you increase your capacity and velocity.

Will this increase latency?

The latency induced by the BFF is negligible compared to a messy frontend.

Any other way to change to do it?

Orchestration vs. Choreography is an eternal question. I would say orchestration is easier to set up with legacy applications as it’s often close to the initial pattern in place, where Choreography represents a cultural change introducing an event notion.

BFF, as you guessed rely on the orchestration pattern.

Let’s dig a little more into Choreography.

Here you can see that producers and consumers have to manage events, so switching to that kind of approach is higher. Still, so is implementing a circuit breaker pattern to handle load and recovery with an orchestration pattern.

So good luck picking the right approach for your need!

🙋‍♂️ Since you’re here

Do you have headless commerce? Or maybe you want to jump on the train of CDN Application for your activity? Do you ask yourself :

‍💪 We are here to help you create the future of your headless commerce stack.

Previously :


Fabien Gasser — Head of innovation @ Smile
We explore, test, and recommend new technologies, creating new offers and value propositions for our clients.

Composable commerce — Legacy management and progressive migration was originally published in Smile Innovation on Medium, where people are continuing the conversation by highlighting and responding to this story.

Leave a Comment

Get the BPI Web Feed

Using the HTML code below, you can display this Business Process Incubator page content with the current filter and sorting inside your web site for FREE.

Copy/Paste this code in your website html code:

<iframe src="" frameborder="0" scrolling="auto" width="100%" height="700">

Customizing your BPI Web Feed

You can click on the Get the BPI Web Feed link on any of our page to create the best possible feed for your site. Here are a few tips to customize your BPI Web Feed.

Customizing the Content Filter
On any page, you can add filter criteria using the MORE FILTERS interface:

Customizing the Content Filter

Customizing the Content Sorting
Clicking on the sorting options will also change the way your BPI Web Feed will be ordered on your site:

Get the BPI Web Feed

Some integration examples