Currently, the `ttl_cache` decorator from [[ http://pythonhosted.org/cachetools/ | cachetools ]] is used to cache responses from the MW and WDQS APIs. The experience is acceptable for most users, but it could be improved. For example, instances of `Element`, `Nuclide` and `TableCell` get created from API responses upon each request.
[[ http://werkzeug.pocoo.org | Werkzeug ]] (a dependency of Flask) includes [[ http://werkzeug.pocoo.org/docs/0.11/contrib/cache/ | caching utilities ]].
`RedisCache` or `FileSystemCache` should suit Tool Labs well, while `NullCache` or `SimpleCache` should suffice for local development.
As per [[ https://github.com/pallets/werkzeug/issues/4 | issue ]], but it might not be the most suitable storage.`werkzeug.contrib.cache` is expected to be factored out in the future but the [[ https://github.com/pallets/werkzeug-cache | repository ]] is still empty.
== Libraries ==
* Keep using `cachetools`
** Pro: support for different replacement algorithms
* Switch to `werkzeug.contrib.cache`
** Pro: support for different storage backends
@yuvipanda should know if Redis is the way to go.** Pro: less external dependencies
As a plus, evaluate whether it's better to cache the computed data (downstream) instead of the raw responses.== Strategies ==
* Cache rendered templates
** Pro: readiness
** Con: bad scalability due to high amount of languages
* Cache `Element` and `Nuclide` instances
* Cache `TableCell` instances
== See also ==
* [[ http://flask.pocoo.org/docs/0.12/patterns/caching/ | Caching ]] pattern from Flask documentation