Developing Plugins

Plugins can be used to customize and enhance the capabilities of your APIs through integration with external services and databases to perform operations such as data transformation, custom authentication, logging and monitoring etc.

When Tyk receives an API request, it works through a chain of processing middleware that is configured using the API definition. There are a large number of built-in middleware in the processing chain that are dedicated to performing client authentication, request transformation, caching and many other processes before proxying the request to the upstream.

Tyk’s custom plugin facility provides a powerful and flexible way to extend the middleware chain. It allows API developers to write custom middleware, in various programming languages, that can perform additional processing of requests and responses.

For example, a custom authentication scheme can be implemented and executed on API requests, custom plugins can be used to provide integration with external services and databases, or additional processing can be performed on the response returned from the upstream.

There are several different stages of the API request lifecycle where custom plugins can be attached (or hooked) into the middleware chain allowing significant customization to meet your specific requirements.

Custom plugins are usually referred to by the location where they can be hooked into the middleware processing chain as follows:

1. Pre (Request)
2. Authentication
3. Post-Auth (Request)
4. Post (Request)
5. Response
6. Analytics (Response)

Supported Languages

A variety of languages are supported for plugin development:

• Go plugins are classed as native plugins, since they are implemented in the same language as Tyk Gateway.
• gRPC plugins are executed remotely on a gRPC server. Tyk Gateway supports plugin development for any gRPC supported language.
• Javascript JVSM plugins are executed within a JavaScript Virtual Machine (JSVM) that is ECMAScript5 compatible.
• Python plugins are embedded within the same process as Tyk Gateway.

Check the supported-languages page for further details.

How It Works

The diagram below illustrates a high level architectural overview for how Tyk Gateway interacts with plugins.

From the above illustration it can be seen that:

• The client sends a request to an API served by Tyk Gateway.
• Tyk processes the request and forwards it to one or more plugins implemented and configured for that API.
• A plugin performs operations (e.g., custom authentication, data transformation).
• The processed request is then returned to Tyk Gateway, which forwards it upstream.
• Finally, the upstream response is sent back to the client.

Plugin Deployment

There are a variety of scenarios relating to the deployment of plugins for an API, concerning the location of the plugin source code and its associated configuration.

Local Plugins

The plugin source code and associated configuration are co-located with Tyk Gateway in the same file system. The configuration is located within the API Definition. For further details please consult API configuration.

Plugin Bundles (Remote)

The plugin source code and associated configuration are bundled into a zip file and uploaded to a remote webserver. Multiple plugins can be stored in a single plugin bundle. Tyk Gateway will download the plugin bundle from the remote webserver and then extract, cache and execute plugins for each of the configured phases of the API request / response lifecycle. For further details on plugin bundles and how to configure them, please refer to the plugin bundles page.

gRPC Plugins (Remote)

Custom plugins can be hosted on a remote server and executed from the Tyk Gateway middleware chain via gRPC. These plugins can be written in any language you prefer, as they are executed on the gRPC server. You’ll configure your API definition so that Tyk Gateway will send requests to your gRPC server at the appropriate points in the API request / response lifecycle. For further details please consult our gRPC documentation.

Tyk Gateway Configuration

Coprocess Plugins

In the context of Tyk, coprocess plugins refer to external plugins that run alongside the main Tyk Gateway process. These plugins allow for custom logic to be executed within the API lifecycle without modifying the core gateway. Essentially, coprocess plugins act as independent services that communicate with Tyk via APIs, enabling the integration of custom functionality written in various languages such as Python, or any other supported gRPC language.

To enable these coprocess plugins, Tyk Gateway needs to be configured accordingly. This is done in the tyk.conf file under the coprocess_options section, where the option enable_coprocess must be set to true:

{
    "coprocess_options": {
        "enable_coprocess": true
    }
}

Plugin Bundles

If you’re using plugin bundles you’ll need to configure Tyk Gateway with the URL of the webserver from which it should download the plugin bundles.

Javascript and gRPC Plugins

Please consult the supporting documentation for further details on configuring Tyk Gateway when using Javascript or gRPC plugins.

Plugin Caveats

• Tyk Gateway manages plugins for each API within the same process.
• For gRPC plugins, Tyk Gateway can only be configured to integrate with one gRPC server.
• Javascript plugins only allow Pre and Post Request hooks of the API Request Lifecycle.

Supporting Resources

• Get started with developing first Go plugin using our tutorial.
• Browse our supported languages section for language specific tutorials.
• Browse our plugins hub for resources that showcase how to develop plugins.