There are 5 different places in the API lifecycle you can inject custom plugins. There are performance advantages to picking the correct phase, and of course that depends on your use case and what functionality you need.
All Plugin Languages can:
- Make Layer 4 (TCP) or Layer 7 (HTTP/REST/SOAP) calls
- Open Persistent Connections
- Modify the request in-flight
- Can Stop the Request 3
- Be served using Bundles 4 or by files on the file system, except gRPC of course which by definition is served by some webserver in the language of your choosing
What Language do I want to write my middleware in and can I use it in this phase?
|gRPC 2 (Rich) 1||✅||✅||✅||✅||✅|
|Python (Rich) 1||✅||✅||✅||✅||✅|
|Lua (Rich) 1||✅||✅||✅||✅||❌|
What are the limitations to using this programming Language?
|Runs in Gateway process||✅
Built-In JSVM Interpreter
Tyk talks with Python interpreter
All Gateway Functionality
(DBs, Redis, etc)
Very Limited 5
Custom Plugin Table
We have put together a GitHub repo with a table of custom plugins in various languages that you can experiment with. If you would like to submit one that you have developed, feel free to open an issue in the repo.
Differences between Rich Plugins and JSVM middleware
- Performance: JSVM is performant, but is not easy to optimise and is dependent on the otto interpreter - this is not ideal. The JSVM also requires a copy of the interpreter object for each request to be made, which can increase memory footprint.
- Extensibility: JSVM is a limited interpreter, although it can use some NPM modules, it isn’t NodeJS so writing interoperable code (especially with other DBs) is difficult.
- TCP Access: The JSVM has no socket access so working with DB drivers and directly with Redis is not possible.
Rich Plugins can provide replacements for existing middleware functions (as opposed to augmentation) and are designed to be full-blown, optimised, highly capable services. They enable a full customised architecture to be built that integrates with a user’s infrastructure.
Rich Plugins bring about the following improvements:
- Performance: Run on STDIN (unix pipes), which are extremely fast and run in their own memory space, and so can be optimised for performance way beyond what the JSVM could offer.
- Extensibility: By allowing any language to be used so long as GRPC is supported, the extensibility of a CPH is completely open.
- TCP Access: Because a plugin is a separate process, it can have it’s own low-level TCP connections opens to databases and services.
 Rich Plugins - Plugin Languages with extensive capability
 gRPC - Using gRPC, you can write plugins in Java, .NET, C++ / C#, PHP, and all other supported languages
 ReturnOverrides - Can be used to stop the request and return a response / error