Live data from Hacker News

How to serve Django Statics (and not go insane)

blog.sendhub.com

1–10 of 34 posts

Re: How to serve Django Statics (and not go insane)

#2
Nice post, tons of great advice. However, I have to say that the title is wrong. There's nothing django specific about any of those approaches.

I've tried django-compress and it was a nightmare, the old style synccompress was actually easier to setup and get working for some reason.. Was hoping for a better rolled solution.

Also, the part about cloudfront isn't written very clearly. I had to stop for a moment and think about what it meant. Great idea nonetheless. S3's gzip support sucks. For some odd reason (I don't support IE6..) the gzip from S3 was breaking on IE9. Worked fine on 8 and 10. Broke on 9. =/

Re: How to serve Django Statics (and not go insane)

#3
post #2

Nice post, tons of great advice. However, I have to say that the title is wrong. There's nothing django specific about any of those approaches. I've tried django-compress and it was a nightmare, the old style synccompress was actually easier to setup and get working for some reason.. Was hoping for a better rolled solution. Also, the part about cloudfront isn't written very clearly. I had to stop for a moment and thi…

You're right, most of this stuff is not django specific. But since we're using it, we thought we'd let everyone know since its likely the most popular python web framework.

Re: How to serve Django Statics (and not go insane)

#4
post #2

Nice post, tons of great advice. However, I have to say that the title is wrong. There's nothing django specific about any of those approaches. I've tried django-compress and it was a nightmare, the old style synccompress was actually easier to setup and get working for some reason.. Was hoping for a better rolled solution. Also, the part about cloudfront isn't written very clearly. I had to stop for a moment and thi…

Also, I can't tell you how much I hate that "cloudflare" sounds so much like "cloudfront". I've been in at least 6 convos where people were mixing one for the other. Esp, since they solve some of the same problems.

Re: How to serve Django Statics (and not go insane)

#6

You know, I've always found django-compressor to be adequate for my django statics needs. Was there a real need to reinvent the wheel in this case? Were you simply unable to configure django-compressor (or any other pre-existing django statics library) properly?

We got it working but there we're a TON of drawbacks that made it not worth the effort. Here are the top three.

1. The config was overly complex and not flexible enough for our needs.

2. It added extra, and unnecessary deploy steps which slowed down our deployments.

3. Configuring GZIP on S3 and Cloudfront is prohibitively complex.

CloudFlare on the other hand, solves many of these problems for us.

Re: How to serve Django Statics (and not go insane)

#7
post #2

Nice post, tons of great advice. However, I have to say that the title is wrong. There's nothing django specific about any of those approaches. I've tried django-compress and it was a nightmare, the old style synccompress was actually easier to setup and get working for some reason.. Was hoping for a better rolled solution. Also, the part about cloudfront isn't written very clearly. I had to stop for a moment and thi…

Also, I can't tell you how much I hate that "cloudflare" sounds so much like "cloudfront". I've been in at least 6 convos where people were mixing one for the other. Esp, since they solve some of the same problems.

Actually that's exactly what happened to me! :P I thought oh so cloudflare can fix this, eh. I should just reverse proxy my stuff through cloudflare.

Then I realized, oh they said cloudfront. So you could still technically keep your stuff in your S3 bucket, though you'd end up paying more for S3 originating transfer as well. In this case, cloudFRONT (the non amazon one!!) may be the better choice.

Hate that they sound the same. I even get my OWN THOUGHTS mixed up sometimes :(

Re: How to serve Django Statics (and not go insane)

#8

You know, I've always found django-compressor to be adequate for my django statics needs. Was there a real need to reinvent the wheel in this case? Were you simply unable to configure django-compressor (or any other pre-existing django statics library) properly?

You make a fair point. I didn't really spend a lot of time trying to get django compressor to work. At some point you have to make a decision about whether or not its worth your time to continue trying to make a library work, or just getting rid of it.

In this case the 2 hours I spent implementing my own solution means it works exactly how I want it to and going forward it will be way easier to maintain.

Re: How to serve Django Statics (and not go insane)

#9

You know, I've always found django-compressor to be adequate for my django statics needs. Was there a real need to reinvent the wheel in this case? Were you simply unable to configure django-compressor (or any other pre-existing django statics library) properly?

We got it working but there we're a TON of drawbacks that made it not worth the effort. Here are the top three. 1. The config was overly complex and not flexible enough for our needs. 2. It added extra, and unnecessary deploy steps which slowed down our deployments. 3. Configuring GZIP on S3 and Cloudfront is prohibitively complex. CloudFlare on the other hand, solves many of these problems for us.

In the article you referenced CloudFront, but now you're saying CloudFlare.. so which is it?

Re: How to serve Django Statics (and not go insane)

#10

You know, I've always found django-compressor to be adequate for my django statics needs. Was there a real need to reinvent the wheel in this case? Were you simply unable to configure django-compressor (or any other pre-existing django statics library) properly?

We got it working but there we're a TON of drawbacks that made it not worth the effort. Here are the top three. 1. The config was overly complex and not flexible enough for our needs. 2. It added extra, and unnecessary deploy steps which slowed down our deployments. 3. Configuring GZIP on S3 and Cloudfront is prohibitively complex. CloudFlare on the other hand, solves many of these problems for us.

Hang on! So your article says "CDN to cache them (which CloudFront supports)" but you're actually using CloudFLARE ? :O We're all so confused by this! Haha :D
Post reply on HN