Django Caching, i18n en Authenticatie

Django bied geweldige tools voor caching eenvoudig maken. Het heeft naar mijn mening wel 2 grote beperkingen:

  • Het stuurt automatisch Cache-control headers, waardoor de client’s cache verhinderd dat de pagina goed herlaad als de taal gewijzigd word en er geen taal prefix in de url gebruikt word
  • Het cached niet per gebruiker, waardoor als we niet opletten er mogelijks private informatie gelekt kan worden.

Beide van deze beperkingen waren oorspronkelijk een probleem bij het herschrijven van Skyz. Het eerste probleem kon deels verholpen worden door taalprefixes toe te voeren aan de url’s, de andere problemen kon ik oplossen op de volgende manieren.

Lees verder

Notes on caching

In een vorige post heb ik toegelicht hoe je caching kan toevoegen aan Django (en in de toekomst zal ik een post maken hoe je ook kan cachen op de webserver). Ik heb wat geƫxperimenteerd met caching en ik heb enkele dingen geleerd.

there are two things hard in computer science: cache invalidation and naming things
— Phil Karlton

Wat te cachen

Statische assets (CSS, Javascript etc) kunnen eigenlijk permanent gecached worden (of toch een langere periode, zoals een maand of een jaar), idealiter ook op de client. Alle andere inhoud moeten we mee opletten.

De homepagina op een drukbezochte site heeft vaak wel baat bij volledig gecached te worden (ook door downstream caches zoals de webserver of een CDN), maar eigenlijk enkel als de site geregeld bezoekerspieken krijgt. Pagina’s die niet veel bezoek krijgen worden beter niet gecached, omdat de kans groot is dat de gecachede versie nooit gebruikt zal worden.

Dure databasequeries worden vaak best gecached, net als externe API calls. Deze worden best gecached in bijvoorbeeld memcached voor zolang het acceptabel is dat deze gegevens “out of date” zijn, bijvoorbeeld 5 tot 10 minuten.

Cachen om te cachen is vaak de moeite niet, als een gecachede pagina nooit cache hits krijgt word er enkel geheugen verspild. In zo’n geval word er beter gekeken naar het optimaliseren van de site/code.

Cache toevoegen aan Django

Een cache toevoegen kan een enorme performantieboost zijn voor een website. Django maakt het eenvoudig om een cache toe te voegen, het laat out of the box 3 manieren om te cachen toe:

  • Volledige site caching (elke pagina krijgt dezelfde behandeling)
  • Per view caching (Er kan per view bepaald worden of er gecached moet worden, en voor hoelang)
  • Low level caching (waar individuele objecten of databasequeries gecached kunnen worden.

Als ik bij een test applicatie per-view caching toevoeg als test, kan ik op een VM met 2 cores 600 requests/seconde verwerken in plaats van 200/seconde. In deze post zal ik toelichten hoe je per-view caching kan implementeren binnen Django

Lees verder

File uploads automatisch hernoemen in Django

Als we in Django een ImageField toevoegen aan een model gebruikt het de bestandsnaam van het originele bestand. Dit is niet ideaal voor applicaties waar gebruikers hun eigen foto’s kunnen uploaden. We kunnen dit oplossen door een functie te geven aan het argument “upload_to”. Het volgende voorbeeld vervangt de bestandsnaam door een automatisch gegenereerde bestandsnaam

import os
from uuid import uuid4
from django.utils.deconstruct import deconstructible

@deconstructible
class PathAndRename(object):

    def __init__(self, sub_path):
        self.path = sub_path

    def __call__(self, instance, filename):
        ext = filename.split('.')[-1]
        # set filename as random string
        filename = '{}.{}'.format(uuid4().hex, ext)
        # return the whole path to the file
        return os.path.join(self.path, filename)

# Then in your model
class Image(models.Model):
    #... other fields
    path_and_rename = PathAndRename('uploads/images/')
    image = models.ImageField(upload_to=path_and_rename)