Dynamic Plugin Ordering

Dynamic Plugin Ordering

The order in which plugins are executed in Kong Gateway is determined by their static priority. As the name suggests, this value is static and can’t be easily changed by the user.

You can override the priority for any Kong Gateway plugin using each plugin’s ordering field. This determines plugin ordering during the access phase, and lets you create dynamic dependencies between plugins.

Concepts

Dependency tokens

Use one of the following tokens to describe a dependency to a plugin:

before: The plugin will be executed before a specified plugin or list of plugins.
after: The plugin will be executed after a specified plugin or list of plugins.

Phases

When a request is processed by Kong Gateway, it goes through various phases, depending on the configured plugins. You can influence the order in which plugins are executed for each phase.

Currently, Kong Gateway supports dynamic plugin ordering in the access phase.

API

You can use the following API to express dependencies for plugins within a certain request phase (examples are in decK-formatted YAML):

ordering:
  $dependency_token:
    $supported_phase:
      - pluginA
      - ...

For example, if you want to express that PluginA’s access phase should run before PluginB’s access phase, you would write something like this:

PluginA:
  ordering:
    before:
      access:
        - PluginB

Known limitations

Consumer scoping

Consumer-scoped plugins don’t support dynamic ordering because consumer mapping also runs in the access phase. The order of the plugins must be determined after consumer mapping has happened. Kong Gateway can’t reliably change the order of the plugins in relation to consumer mapping.

Cascading deletes & updates

There is no support to detect if a plugin has a dependency to a deleted plugin, so handle your configuration with care.

Performance implications

Dynamic plugin ordering requires sorting plugins during a request. This naturally adds latency to the request. In some cases, this might be compensated for when you run rate limiting before an expensive authentication plugin.

Re-ordering any plugin in a workspace has performance implications to all other plugins within the same workspace. If possible, consider offloading plugin ordering to a separate workspace.

Validation

Validating dynamic plugin ordering is a non-trivial task and would require insight into the user’s business logic. Kong Gateway tries to catch basic mistakes but it can’t detect all potentially dangerous configurations.

If using dynamic ordering, manually test all configurations, and handle this feature with care.