Static Files & S3

There are somethings that Django never handled, static files being one of them and over the years there have been many ways to attack the problem. Up until recently my chosen weapon of choice had always been using S3 to serve static assets. Configuring Django to do so wasn’t rocket science, but neither is trivial when you consider you have to create IAM users, set up buckets etc etc (which is fine if you have the time to write a full automation suite, but such a mission is not a wise choice on smaller projects). It worked though, and if you were so inclined towards performance and speed over the wire, you could set up your static files via cloudfront and enjoy the many benefits of a CDN. In general though the pain of setup vs payoff of performance and stability balance always worked out for me. Until …

WhiteNoise

I was mearly looking to see if the general consensus of Heroku and Django Static Assets had changed, and it had. The documentation was now referring to a project called White Noise which I have to say, was a breeze to set up. Much nicer than all the AWS jiggery-pokery. The above link has all the setup information, so I’ll not repeat here except to say that I had to add this line into my settings, which isn’t mentioned on the readme or Heroku article, but is mentioned in the Using whitenoise with Django documentation.

django.core.exceptions.ImproperlyConfigured: Both STATIC_URL and STATIC_ROOT settings must be configured to use DjangoWhiteNoise

What about performance?

The White Noise readme mentions this and so I’ll not repeat that information, but it gives me the impression that if you’re not doing more than 5 requests per second, you’ll be good.
Right now though, my use case is an internal app that isn’t going to see more than 10 requests a second, so it’s not a huge concern. I’ll report back on this. Maybe. If someone asks nicely.