Skip to main content

API Facade per Client Type

Context​

The system is split into multiple microservices with corresponding APIs. There are multiple client types with different requirements towards the API of the system.

Problem​

  • Client types have different API needs due to the nature of the device (e.g. bandwidth on mobile devices) or the nature of there use cases (e.g. need combination of APIs)
  • A high volume of network traffic is required since the frontend needs to speak with several microservices, leading to poorly performing clients

Solution​

Introduce an aggregated API per client type that becomes the single point of access for each of the client types. This technique simplifies the creation of new client types and leads to a more efficient communication between clients and the microservice-based backend.

This technique is an extension of the API Facade technique and is also known as the Backends for Frontends pattern.

There are two different kinds of possible implementations:

  • logical backend per client type: an API gateway can dynamically register logical APIs that are specific to a client, fan out the required requests, and aggregate the results.
  • physical backend per client type: an backend component solely responsible for one client type. An advantage is that the client type specific API component can clearly allocated to the corresponding client team, avoiding shared ownership of a component. Technologically, this can be implemented via an API gateway component per client type.

Maturity​

Proposed, requires evaluation.

Sources of Evidence​

L6:

  • Implement gateway functionality in a single service or as set of independent services
    • depending on if there are different clients with different generated load
  • single service: e.g., HTTP content negotiation to differentiate between consumers
  • independent services: more flexible scalability (z-axis scaling) by consumer-specific deployment

L25:

  • API gateway to introduce custom API for each client
  • can inhibit shared logic as auth and rate limiters
  • can route requests, transform protocols
  • (+) simplifies creation of end-user applications
  • (+) features / complexity the client does not need is not exposed

L43:

  • architecture diagram showing different API applications in the "frontend" area (one serves browser clients, one mobile clients), even in front of discovery => should be backend for frontend pattern

L46:

  • Service model for two speed architecture
    • Backend for frontend service
      • provision a particular frontend requirement
      • composed service using business, entity, technical services
      • may be regarded as specialized form of business service built for a particular frontend purpose

LM45:

  • Context: interviews and insights from multiple cases on technologies and sw quality in MSA
  • C6-S10
    • SCS paradigm, 20 coarse-grained and vertically cut services including their own UI
    • GraphQL middleware to avoid low performance from SPA frontend to multiple services
      • backends for frontends pattern
  • some saw SPA-based UIs be problematic with microservices
    • multiple requests per page to multiple services => large amount of business logic for data integration on client-side and low performance
    • favored dynamic server-side rendering
      • Server Side Includes (SSI)
      • Edge Side Includes (ESI)
      • others employ the backend for frontends pattern

Interview B:

  • UI can be very important to product depending if internal or external customers
  • Netflix: different API gateways for different use-cases
    • admin, user, etc.
    • different client types, down to brands (e.g. Samsung TV, Playstation, ...)
    • dedicated UI teams writing adapters on the API gateway and the adapter on client site
    • => focus on importance of UI
      • e.g., different fallback mechanisms on failure
      • Netflix feels good on all devices
      • Sky is the same everywhere, but worse on every device

Interview E:

  • UI has different requirements on microservice backend system
  • UI wants to speak with exactly one backend, usually a backend-for-frontend
    • discussable who is responsible for that component (backend or frontend)
    • if know-how is there => frontend team
    • avoids speaking with several backends and coupling to all of them
  • Backend-for-frontend pattern
    • if good vertical service cut => not necessary because speaking with one microservice nevertheless
    • otherwise: strong appeal to use the pattern
      • no unnecessary coupling, dependencies, and performance reduction
    • deploy complete vertical cut or frontend + its backend-for-frontend to make sure frontend matches with backend
      • if sure no breaking changes => also okay to deploy independently