Backends for Frontends (BFF)

A diagram for Services with Backends for Frontends, in abstractness-subdomain-sharding coordinates.

Hire a local guide. Dedicate a service for every kind of client.

Known as: Backends for Frontends (BFF), Layered Microservice Architecture.

Structure: A layer of integration services over a shared layer of core services.

Type: Extension component, derived from Orchestrator and/or Proxy.

Benefits	Drawbacks
Clients become independent in protocols, workflows, and, to an extent, forces	No single place for cross-cutting concerns
A specialized team and technology per client may be employed	More work for the DevOps team
The multiple Orchestrators are smaller and more cohesive than the original universal one

References: The original article, a smaller one from Microsoft and an excerpt from [MP]. Here are reference diagrams from WSO2 (notice multiple Microgateway + Integration Microservice pairs).

If some aspect(s) of serving our system’s clients strongly vary by client type (e.g. OLAP vs OLTP, user vs admin, buyer vs seller vs customer support), it makes sense to use a dedicated component (the titular Backend for Frontend or BFF) per client type to encapsulate the variation. Protocol variations call for multiple Proxies, workflow variations – for several Orchestrators, both coming together – for API Gateways or Proxy + Orchestrator pairs. It is even possible to vary the BFF’s programming language on a per client basis. The drawback is that once the clients get their dedicated BFFs it becomes hard to share a common functionality between them, unless you are willing to add yet another new utility service or layer that can be used by each of them (and that will strongly smell of SOA).

Performance#

As the multiple Orchestrators of BFF don’t intercommunicate, the pattern’s performance is identical to that of an Orchestrator: it also slows down request processing in the general case but allows for several specific optimizations, including direct communication channels between orchestrated services.

Dependencies#

Each BFF depends on all the services it uses (usually every service in the system). The services themselves are likely to be independent, as is common in orchestrated systems.

Each Backend for Frontend depends on every service which it calls.

Applicability#

Backends for Frontends are good for:

Multiple client protocols. Deploying a Gateway per protocol hides the variation from the underlying system.
Multiple UIs. When you have one team per UI, each of them may want to have an API which they feel comfortable with.
Drastically different workflows. Let each client-facing development team own a component and choose the best fitting technologies and practices.

Backends for Frontends should be avoided when:

The clients are mostly similar. It is hard to share code and functionality between BFFs. If the clients have much in common, the shared aspects either find their place in a shared monolithic layer (e.g. multiple client protocols call for multiple Gateways but a shared Orchestrator) or are duplicated. BFF may not be the best choice – use OOD (conditions, factories, strategies, inheritance) instead to handle the clients’ differences within a single codebase.

Relations#

Backends for Frontends:

Extends Services or rarely Monolith, Layers, or Shards.
Is derived from a client-facing extension metapattern: Gateway, Orchestrator, API Gateway, or Event Mediator.

Variants#

Backends for Frontends vary in the kind of component that gets dedicated to each client:

A Proxy per client when clients differ in protocols.
An Orchestrator or Event Mediator per client for different client roles and use cases.
A Proxy + Orchestrator pair or an API Gateway when clients differ in both protocol and role.

Proxies #

Each gateway in the Backends for Frontends layer adapts its client's protocol and calls the services of the domain layer.

Dedicating a Gateway per client is useful when the clients differ in the mode of access to the system (protocols / encryption / authorization) but not in workflows.

Orchestrators #

Each orchestrator in the Backends for Frontends layer calls the services of the domain layer.

An Orchestrator per client makes sense if the clients use the system in completely unrelated ways, e.g. a shop’s customers have little to share with its administrators.

Proxy + Orchestrator pairs#

In each pair in the Backends for Frontends layer the gateway adapts its client's protocol while the orchestrator calls the services of the domain layer.

Clients vary in both access mode (protocol) and workflow. Orchestrators or Proxies may be reused if some kinds of clients share only protocol or application logic.

API Gateways #

Each API Gateway in the Backends for Frontends layer both adapts its client's protocol and orchestrates the services of the domain layer.

Clients vary in access mode (protocol) and workflow and there is a third-party API Gateway framework which seems to fit your requirements off the shelf.

Multiple API Gateways match the literal meaning of Backends for Frontends – each UI team (backend, mobile, desktop; or end-device-specific teams) gets some code on the backend side to adapt the system’s API and protocols to its needs by building a new, probably higher-level specialized API with a convenient transport.

Event Mediators #

Each event mediator in the Backends for Frontends layer orchestrates the services of the domain layer.

[FSA] mentions that multiple Event Mediators may be deployed in Event-Driven Architecture to split the codebase and improve stability.

Evolutions#

BFF-specific evolutions aim at sharing logic between the BFFs:

The BFFs can be merged into a single Orchestrator if their functionality becomes mostly identical.
A shared orchestration layer with common functionality may be added for use by the BFFs.
A layer of Integration Services under the BFFs simplifies them by providing shared high-level APIs for the resulting Cells.
Sidecars (of Service Mesh) are a way to share libraries among the BFFs.

Backends for Frontends can be merged into an Orchestrator, can share code via sidecars, or put shared functionality into a dedicated orchestration layer or into Cell gateways.

Summary#

Backends for Frontends assigns a Proxy and/or an Orchestrator per each kind of a system’s client to encapsulate client-specific use cases and protocols. The drawback is that there is no decent way for sharing functionality between the BFFs.