Remedy Plugins Chaining

Remedy chaining refers to the process of combining the effects of multiple remedies on a single request or response. Lunar allows users to define multiple remedies for a single endpoint. In such cases, it will prioritize the remedies based on the type of action they take and combine their effects in a specific order.

The Power of Remedy Chaining in Lunar

Remedy chaining in Lunar Proxy allowing users to combine multiple remedies in a specific order to achieve desired outcomes, optimize resource usage, and enhance the overall behavior of Lunar.

• Enhanced Flexibility: By allowing the combination of multiple remedies, Lunar provides users with greater flexibility in customizing the behavior of requests and responses. Different remedies can be applied to different endpoints, and their effects can be combined to achieve desired outcomes.

• Efficient Request Processing: Remedies are applied based on their priority and order defined in the configuration file. This ensures that the most critical and immediate actions are taken first, such as generating an immediate response or modifying requests/responses. By prioritizing remedies, Lunar optimizes the processing of requests and responses, reducing latency and improving overall performance.

• Customizable Behavior: The ability to define and chain remedies allows users to tailor the behavior of Lunar according to their specific use cases and requirements. They can mix and match different remedies to create unique combinations that align with their desired outcome, whether it's optimizing performance, enforcing security measures, or implementing custom business logic.

How it Works

When the Lunar Proxy processes a request or a response, it identifies all applicable remedies based on the globally defined and per-endpoint policies. If more than one remedy policy applies, the remedies are chained: The Lunar Proxy applies the remedies according to the order defined in the configuration file. After each remedy runs it produces an action. The actions of the relevant remedies are prioritized by action type and combined to produce the final action. The final action is then applied to the request or response.

Priority of Remedies

The priority of remedies is determined by the type of action they take. There are three types of actions that a remedy can take: generate a response, modify a request/response or do nothing. The priority order is as follows:

• Generating Responses: Remedies that result in Lunar Proxy producing a response immediately take the highest priority. These remedies trigger an immediate response, eliminating the need to forward the request to the original API provider

• Modifying Requests/Responses: Remedies that modify the original request or response are next in line. If multiple remedies aim to modify the same request or response, they are combined in a way that the later ones take precedence in case of any conflicts.

• No Operation: Remedies that do not induce any changes to the request or response are given the lowest priority.

Examples

Caching & Strategy-Based Throttling

/etc/lunar-proxy/policies.yaml

endpoints:
  - url: "api.com/api/v1/users/{id}"
    method: "GET"
    remedies:
      - name: "Caching"
        enabled: true
        config:
          caching:
            request_keys: "header.Authorization"
            ttl_seconds: 3600
            max_bytes: 1000000
      - name: "StrategyBasedThrottling"
        enabled: true
        config:
          strategy_based_throttling:
            allowed_request_count: 10
            window_size_in_seconds: 60
            response_status_code: 429

In this configuration Lunar Proxy applies two remedies on the endpoint GET api.com/api/v1/users/{id}:

• Caching: It checks if there's a cached response for the current Authorization header that is less than an hour old and within the allowed cache size. If it exists, Lunar Proxy immediately serves this cached response, skipping the subsequent remedies.

• If there's no valid cached response, Strategy-Based Throttling comes into play. It enforces a rate limit of 10 requests per 60-second window. If this limit is exceeded, Lunar Proxy generates a response with a 429 status code, indicating throttling. If the rate limit is not exceeded, the request is forwarded to the original API provider.

Note that the order of the remedies is important. If the order was reversed, the rate limit would be applied to the cached responses as well.

API Account Orchestration & Caching

/etc/lunar-proxy/policies.yaml

endpoints:
  - url: "api.com/api/v1/users/{id}"
    method: "GET"
    remedies:
      - name: "AccountOrchestration"
        enabled: true
        config:
          account_orchestration:
            round_robin:
              - "account1"
              - "account2"
      - name: "Caching"
        enabled: true
        config:
          caching:
            request_keys: "header.Authorization"
            ttl_seconds: 3600
            max_bytes: 1000000
accounts:
  account1:
    tokens:
      - header:
          name: "Authorization"
          value: "Bearer token1"
  account2:
    tokens:
      - header:
          name: "Authorization"
          value: "Bearer token2"

In this example, Lunar Proxy applies two remedies:

• AccountOrchestration: It modifies the request by adding or overwriting the Authorization header with a token from the list of tokens defined for the account in a round-robin manner. If the request already contains an Authorization header, it is overwritten. If the request does not contain an Authorization header, it is added. The next remedy in the chain will see the modified request.

• Caching: It checks if there's a cached response for the current Authorization header that is less than an hour old and within the allowed cache size. If it exists, Lunar Proxy immediately serves this cached response, skipping the subsequent remedies. If there's no valid cached response, the request is forwarded to the original API provider. Note that the Authorization header is affected by the previous remedy, so the cache key will be different for each account.

API Account Orchestration & Cache & Strategy-Based Throttling

/etc/lunar-proxy/policies.yaml

endpoints:
  - url: "api.com/api/v1/users/{id}"
    method: "GET"
    remedies:
      - name: "AccountOrchestration"
        enabled: true
        config:
          account_orchestration:
            round_robin:
              - "account1"
              - "account2"
      - name: "Caching"
        enabled: true
        config:
          caching:
            request_keys: "header.Authorization"
            ttl_seconds: 3600
            max_bytes: 1000000
      - name: "StrategyBasedThrottling"
        enabled: true
        config:
          strategy_based_throttling:
            allowed_request_count: 10
            window_size_in_seconds: 60
            response_status_code: 429

accounts:
  account1:
    tokens:
      - header:
          name: "Authorization"
          value: "Bearer token1"
  account2:
    tokens:
      - header:
          name: "Authorization"
          value: "Bearer token2"

In this example, the Lunar Proxy applies three remedies:

• Account Orchestration: It modifies the request by adding or overwriting the Authorization header with a token from the list of tokens defined for the account in a round-robin manner. The next remedy in the chain will see the modified request.

• Caching: It checks if there's a cached response for the current Authorization header that is less than an hour old and within the allowed cache size. If it exists, Lunar Proxy immediately serves this cached response, skipping the subsequent remedies. If there's no valid cached response, the request is forwarded to the original API provider. Note that the Authorization header is affected by the previous remedy, so the cache key will be different for each account.

• Finally, if there is no cached response, Strategy-Based Throttling enforces a rate limit of 10 requests per 60-second window. If this limit is exceeded, the Lunar Proxy generates a response with a 429 status code, indicating throttling. If the rate limit is not exceeded, the request is forwarded to the original API provider.