Skip to main content

API Gateway 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
  • Communication with clients uses protocols or data formats that are not compatible with or optimal for the microservice APIs

Solution​

Introduce an API gateway as facade to the whole system. The API gateway becomes the single point of access to the system and manages the interaction with the individual microservices.

This technique is a lightweight specialization of the API Facade technique.

API gateway components offer advanced facade functionlity like fanning out client requests to multiple microservices and aggregating the results and transforming protocols or data formats depending on the used internal and external communication technologies. These advanced functionalities allow moving non-trivial logic into the infrastructure component. As this introduced component can become arbitrarily inflated, you should avoid putting business logic into infrastructure components.

An alternative to this technique is the more light-weight Edge Server Facade technique. It offers only simple functionalities like forwarding requests based on a routing mechanism.

Maturity​

Proposed, requires evaluation.

Sources of Evidence​

Note: As this technique is a specialization of the API Facade techniques, we also used their sources to formulate this technique.

L5:

  • configure to report availability and discovery

L6:

  • Example in IoT system
  • => high-level API for different kinds of consumers
  • Don't differentiate between consumers => allows scaling gateway by one gateway per client type

L7:

  • Simliarities to SOA patterns (ESB, Remote Facade)

L15:

  • Testing lambda frameworks, use AWS API gateway for routing
  • Tech: AWS API Gateway; imposes 30 second limit to sync requests

L20:

  • (+) Simplifies firewalling
  • (+) Decouples clients from internals

L24:

  • is a well-known pattern

L25:

  • Proposes API gateway pattern
  • no support for publishing, promoting, or administering services
  • generation of customized APIs for client types + optimize communication
  • encapsulate microservice details
  • Can serve as aggregation mechanism
  • Shared logic, e.g. authentication, rate limiting
  • Can be point of monitoring, static response handling, load balancing
  • (+) allows evolving without influencing clients
  • (+) easier migration if in orchestration layer (no need to refactor second time)
  • (+) extension easiness
  • (+) easily modify services based on market needs without modifying the whole system
  • (+) backward compatibility
  • (-) potential bottleneck if not designed correctly
  • (-) development complexity => multiple interfaces for each service
  • (-) scalability
  • (-) Complexity of API reuse (keep track which client types use same API)
  • (-) filtering or interface translation might not expose original API
  • Can be replaced by message bus
  • Difference to load balancing
    • load balancing: direct communication between client and microservice
    • interpretation API gateway does not only forward

L34:

  • API gateway categorized under the category communication/integration challenge

L53:

  • API Gateway applied in automotive microservice context to aggregate APIs of different microservices
  • API Gateway can be used between microservices and client-facing
  • Resolves stored microservice handle to location and protocol
  • Gateway per vehicle => used between parts of the system (cloud vs. edge) => between "hierarchy levels
  • single point of access control (SSO, OAuth) => hides microservices
  • (+) independent protocol evolution of microservices
  • (+) simplifies deploy microservices differently
  • (+) add local management of event streams to edge cloud node/smartphones
  • (+) Can be used to aggregate (monitoring) data sent to further components => lower traffic when aggregated
  • Challenge: API gateway should not be single point of failure / scalability bottleneck
  • Name resolution for integrating different versions or load balancing
  • QoS policies help to protect system from DoS attacks => or as circuit breaker

L55:

  • Example architecture using API gateway for dynamic and secure API routing
  • Tech: Ribbon
  • offers circuit breaker and load balancing capabilities

L61

  • API gateway in Netflix
    • = API orchestration service
    • exposes coarse-grained APIs, routs requests to specific target microservices
    • implements logic to route, sequence, parallelize incoming calls
  • API gateway the most recurring design patterns in microservices
    • spike in quality metrics maintainability and performance

LN41

  • mentions lightweight API gateway for managing services instead of ESB

LN44

  • User authenticationat the gateway in context of principal propagation via security tokens

LN48

  • Figure 3 shows an API-Gateway + loac balancer in front of backend system
  • In benchmark experiment their system has an API gateway as entrypoint to the system

LM43:

  • Context: SLR findings about microservices in DevOps
  • Table 10: lists the gateway pattern
  • API gateway as example for communication/monitoring/service discovery pattern
  • S12 + S33: external API pattern, eg API gateway

LM45:

  • Context: interviews and insights from multiple cases on technologies and sw quality in MSA
  • API gateway as mitigation to tackle challenge increased attack surface

Interview B:

  • How to access the overall system? gateway or allow direct access to service?
    • Consider security aspects as throttling (against brute-force attacks)
      • Monitor how many requests per seconds/minute
      • API keys with quota
  • Are the following things part of the gateway?
    • Service registry / discovery
    • Resilience patterns
    • Load balancing (e.g. round robin)
    • Alternatives to handle these aspects: Kubernetes cluster, service mesh
      • => what aspects are part of what to which degree?
      • Rule of thumb: IF FAIL FAST => GATEWAY
      • Coarse grained security into gateway, fine grained in mesh or services
  • API gateways is a macro (global) decision
  • Security: security concept in each service vs. SSO via API gateway
    • often forgotten: services behind gateway, like batch jobs => might open a side-channel next to gateway
    • Might take token information and put them into header
  • Resilience patterns
    • Take alternative after time x
    • Static content if no response
  • The netflix example
    • Without gateway: UI directly communicate with services
      • On failure: static content as fallback
      • => many calls over slow internet connection
    • Gateway: less but more coarse grained calls
      • Gateway delegated, collects and combines responses
      • 70-80% performance gains
      • Much more target-oriented fallback content on failure
  • Microfrontends
    • shared CSS added in gateway? => complex
    • Netflix: different API gateways for different use-cases: admin, user , etc.
      • Extend gateway by an adapter

Interview D:

  • Mentions possibility of having API gateway as additional hop in call chain