Skip to main content

Middleware

Overview​

Sandbox middleware provides a way to intercept and process requests destined for a sandbox.

In general, middleware is capable of:

  • Modifying requests: Add headers, transform data, or inject parameters
  • Generating responses: Return mock data or error responses
  • Capturing data: Record requests and responses for analysis
  • Measuring performance: Collect metrics and timing information

How Middleware Works​

Requests destined for sandboxed workloads are routed to the traffic manager whenever there is middleware associated with the destination sandboxed workload.

The traffic manager then runs the middleware just as an HTTP server runs middleware: as a chain of functions which intercept the request and response.

Built-in Middleware​

Signadot provides the following built-in middleware that are automatically available when you install the Signadot Operator.

  • Traffic Record: Records HTTP requests and responses for analysis direct to your local machine.
  • Override: Dynammically override or pass through requests.

Configuration​

Sandbox-Level Configuration​

Middleware can be configured at the sandbox level allowing you to set up middleware functions for all requests targeting a particular service within a sandbox, or for all services in a sandbox. See sandbox spec for details.

Request-Level Configuration​

Individual requests can override sandbox configurations using the sd-traffic baggage key. The baggage key should contain a base64 URL encoded JSON list of specifications for middleware functions. The specifications are similar to the sandbox spec middleware field, but are in form which the in-cluster Signadot components understand.

Example​

[{"instance":{"middleware":"trafficwatch-client","args":[{"name":"options","value":"+trunc(0)/+trunc(0)"}]}}]

One can also specify a workload to restrict the middleware function to that workload:

[{"workload":{"kind":"Deployment","namespace":"hotrod","name":"location"}, instance":{"middleware":"trafficwatch-client","args":[{"name":"options","value":"+stream/+stream"}]}}]

And an example with curl.

export SDTRAFFIC=$(echo '[{"workload":{"kind":"Deployment","namespace":"hotrod-devmesh","name":"location"},"instance":{"middleware":"trafficwatch-client","args":[{"name":"options","value":"+trunc(0)/+trunc(0)"}]}}]' | base64)
curl -H "baggage: sd-routing-key=kvsfc8dstgvp6, sd-traffic=$SDTRAFFIC" location.hotrod-devmesh.svc:8081/locations

Considerations​

Request level middleware provides a great deal of granularity of control over requests but is harder to put in place. Request level middleware may be appropriate for certain applications but using the sandbox spec or the CLI is more convenient.