Cache about tyk

[lonelycode]

Not at the moment, though since Tyk acts as an upstream proxy there's nothing stopping you adding reverse proxy in front of it to cache requests once they are handled by Tyk.

The reasoning is that we don't want to re-invent tech that's already out there that handles caching very well, and caching around web applications is well established, so using varnish or memcached integrated into your own app would be more effective than having Tyk try and shoe horn it in.

Tyk records data on all requests for quota and rate limiting, so it does need to hit the database in order to fulfil its primary gate keeping functions

For speed Tyk uses Redis, which is meant to be used in high traffic environments and can hand many read/writes cleanly. It can also be load balanced and clustered, so it can scale quite easily.

Happy to hear thought s on what could be done to make cache integration easier though - there's many assumptions here that NginX is being used to plumb request routing.

Cheers,
Martin

On 18 Sep 2014, at 23:48, shopline [email protected] wrote:

Any support for cache?

Hitting the same request twice or more with a cache can really save resource/backend server load.

—
Reply to this email directly or view it on GitHub.

[shopline]

I agree that reinventing the wheel is not a good approach, but if it is possible to utilize for example varnish or maybe nginx for the caching it would be nice with some documentation on how to set that up.

We also need to utilize SSL for all API calls. I know that varnish doesn't support SSL, but I am not sure if that only applies when it is used at the frontend and not the backend?

A typical scenario (for us) would be something like:

Tyk > Cache > Resource API server > Database

I have not speed tested Tyk yet but I trust you have and that Tyks speed is not an issue. The cache would not be for speeding up Tyk but the main issue for us would be to offload the resource servers with duplicate API calls.

[lonelycode]

Well, it is actually recommended to run Tyk behind a web server as an upstream proxy, so the stack would look like:

NGinX > Tyk > (Cache) > Application -> DB

This should take care of the SSL issue as you could terminate the SSL connection at the NGinX end and then handle unencrypted traffic upstream afterwards, this would simplify things massively, exposing a cache to a DMZ might not be a good idea.

I'm not overly familiar with Varnish, but looking at some configuration examples configuring it as a reverse proxy is relatively simple (at least that's what these templates imply: https://github.com/mattiasgeniar/varnish-3.0-configuration-templates), caching only methods and paths that are needed, since SSL is no longer a problem (as it is dealt with by the web server, where it should be handled), you can pipe traffic via Tyk through Varnish which is reverse proxying your web app.

[lonelycode]

Added a naive cache (redis) middleware feature in latest merge.