Backends for Frontends (BFF) #

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

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

Aspects:

• Proxy,
• Orchestrator.

Variants:

Applicable to:

• Proxies,
• Orchestrators,
• Proxy + Orchestrator pairs,
• API Gateways,
• Event Mediators.

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

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

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.

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:

Proxies #

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.

Multiple Adapters 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 to its needs by building a new, probably more high-level specialized API on top of it.

Orchestrators #

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 #

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 #

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.

Event Mediators #

[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 [DDS] (of Service Mesh) are a way to share libraries among the BFFs.

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.