Skip to main content

API Facade

Context​

The system is split into multiple microservices with corresponding APIs. There is at least one client type (e.g. browser app, native app, ...) that wants to use the APIs of the system.

Problem​

  • API usage by clients is hampered by the required knowledge over the complex internal structure of the system
  • Clients are using the API but break frequently due to internal changes on the system structure

Solution​

Introduce a facade to the whole system that becomes the single point of access to the system and routes the requests to the individual microservices.

This rather abstract techniques has two more concrete implementations:

  • The Edge Server Facade technique: a simple reverse proxy as facade using routing policies.
  • The API Gateway Facade technique: facade component that additionally allows to define client type specific APIs that fan out client requests and aggregate the results and transform protocols and data formats.

This central point of access can be used for different further jobs:

  • monitoring the microservices,
  • load balancing the incoming client requests,
  • protecting the system from attacks by firewalling or other security mechanisms,
  • act as proxy circuit breaker that prevents the system from overload and gives fast feedback to the clients,
  • user authentication and authorization.

As this introduced component can become arbitrarily inflated, you should avoid putting business logic into infrastructure components.

Maturity​

Proposed, requires evaluation.

Sources of Evidence​

Note: As this technique is an abstraction of the Edge Server and the API Gateway techniques, we also used their sources to formulate this technique.

L43:

  • Example illustration for API proxy part of "front-end" (backend-for-frontends)

L46:

  • API proxy as layer to control access (decouples)
  • Enables different SLAs, security requirements, access levels, etc. for organizations with different APIs (internal consumers, partners, public, ...)
  • API proxy as pendant to ESB in SOA
  • Can wrap old versions => compatibility
  • Point of monitoring

L59:

  • frontend-proxy server and load balancer to organize horizontal scaling to multiple servers

Interview C:

  • Place where security is implemented: facade, service, central token service