Skip to main content

Edge Server 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 an edge server as facade to the whole system. The edge server becomes the single point of access to the system and routes the requests to the individual microservices.

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

The edge server can be a simple reverse proxy using routing policies. However, those routing policies should be configurable at runtime, so that internal changes in the system don't require a redeployment of the API facade component. It might offer a service discovery mechanism or rely on some external one.

An alternative to this technique is the more heavy-weight API Gateway Facade technique. It offers additional functionalities like protocol and data format transformations.

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.

L3:

  • (+) easier to change internal structure (minimize impact on end user)
  • (+) better monitoring
  • Tech: Zuul

L12:

  • Example system using edge server => routing point to external clients
  • Edge server = implementation of API gateway pattern
  • (+) reduce impact of internal changes on end-users
  • Tech: Zuul

L31:

  • Pattern description of edge server: dynamic rerouting
  • (+) easily introduction of new services
  • (+) easier rearchitecting
  • (+) changes are transparent to end users (they are not influenced by changes)**:
  • (+) Hide complex internal structure and evolution from clients
  • (+) Good place to monitor status and usage of a service
  • Pattern usage observed in case studies
  • (-) Single point of failure => replicate through load balancing mechanisms

LM43:

  • Context: SLR findings about microservices in DevOps
  • Table 10: lists the edge server pattern