Plugin/middleware to transform response

Product Feature Requests & Feedback
1

I’ve seen a few various questions on the forum inquiring about a rich plugin/middleware that allows for transforming/modifying the response from an API prior to sending it to the client. Has this been added for support in the product, and if so, is there any example that demonstrates it?

Thanks!

2

Hi, there are two options:

  1. Use the built-in response transformation middleware functionality: Response Body Transform, Response Header Injection and Response Header Deletion. You will find more details here.

  2. We don’t support custom response middleware directly but you can use a feature called ReturnOverrides which enables the usage of your own implementation to hit the upstream endpoint, the steps are:

  • Create a custom middleware.
  • Send the request to upstream using your middleware implementation (typically using a HTTP module in the language you’re using).
  • Set the ReturnOverrides field on the request object.

More details on this field here. This approach is available on rich plugins, gRPC or Python based, I suggest starting here.

3

Thanks for the response, @matiasb.

I’m not sure if the Response Body Transform will suffice as we’re wanting to do more complex transform based on specific details of the response (presence of headers and/or pattern in response body), but do you have any more detail or examples of response transform templates?

Regarding the ReturnsOverride approach, what drawbacks should be considered if starting to do all HTTP requests through the plugin as opposed to having the gateway perform them? A few concerns that jump to mind include:

  • Wouldn’t the plugin need to duplicate configuration/logic for enforcing timeouts?
  • How does concurrency in a plugin work? I assume the gateway has much logic for multiple requests executing concurrently and performing appropriate request pooling for proxying the request to the backend server.
  • How would the plugin know which backend to send requests to if in a load balanced scenario?

The ReturnOverrides seems like a poor man’s way of accomplishing this as it would need to handle all logic to proxy the request to the backend server. Do you know if full support for response processing is on the roadmap for the Tyk? We’d expect to be able to process the response of APIs (before sending back to client) in the same way we’re able to process the request (before it is sent to backend).

Our scenario is that we’re wanting to be able to modify the Tyk user session based on some response scenarios. As an example, if a user has access to the endpoint CREATE /api/blogs and uses it to create a “blog” item, we would want to have the plugin detect this scenario so that the user can be granted access to that API (e.g. GET /api/blogs/123). Doing this at the gateway is desired as the individual APIs can be kept purely focused on the service and not need to concern with any authentication/authorization.

Thanks!

4
  • I need to check the timeout scenario that you’re mentioning.
  • If you’re using a Python plugin, the interpreter runs as part of the same process and your main bottleneck is the Python Global Interpreter Lock. If you use a gRPC plugin, you have to deploy your plugin as a gRPC server and all the dispatched requests use their own goroutines. In this scenario you might expect better performance, it will depend on your hardware, your plugin’s implementation and also the type of socket you use for this communication. It’s possible to use a TCP socket or an UNIX socket with gRPC.
  • In that case I see two options: a) set a LB before your upstream API and let it deal with that logic b) Implement LB logic on your plugin

We had feature requests related to response processing and it’s something we would like to implement in the future, we’re currently working on new plugin features.

Regards.

5

For those coming here in the future, details of this being worked on can be found at Support response middleware when using rich plugins by matiasinsaurralde · Pull Request #2321 · TykTechnologies/tyk · GitHub.