Skip to main content
DjangoKit Log In

Caching

DjangoKit provides some hooks into the Django HTTP caching system in an attempt to simplify (and even encourage) basic caching, but caching strategies require careful consideration to avoid caching sensitive content, serving content to the wrong user (or the entire world), caching responses for too long, etc.

Take a look at the MDN caching article for more info on caching and the tradeoffs and potential issues involved.

Caching of Pages and Handlers

There are a few ways to cache page and handler responses:

  1. Set DJANGOKIT.cache_time to a positive value to cache all unauthenticated GET requests.
  2. Decorate a handler with the @handler decorator and specify the cache_time and other cache-related config.
  3. Combine 1 and 2. The cache config from the settings will apply to all pages and to all handlers that don't specify their own cache config.
  4. Additionally, a handler can be decorated with Django's @cache_page and/or use Django's other cache utilities. In this case, the handler must return a response object (e.g., a JsonReponse), just like a regular Django view.

Caching of Static Files

For static files, it's common to use manifest file storage in conjunction with far-future caching configured in Nginx, Apache, or whichever production web server you're using. DjangoKit doesn't do anything special with regard to caching of static files other than setting the default STATICFILES_STORAGE to ManifestStaticFilesStorage.

DjangoKit also provides an experimental manifest storage implementation that removes source files when running collectstatic so only the processed files with hashes in their names are included (see this Django forum post for some discussion about that).