4 ms·
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 s
by jaytaylor 14y ago
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?
- rdpfeffer 14y agoWe 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.
- jaytaylor 14y agoIn the article you referenced CloudFront, but now you're saying CloudFlare.. so which is it?
- rdpfeffer 14y agoThe article has been modified to clarify which service we are using as a reverse proxy and why.
- ashray 14y agoHang 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
- cdoxsey 14y agoBoth CloudFlare and CloudFront can do this. http://aws.typepad.com/aws/2010/11/amazon-cloudfront-support-for-custom-origins.html http://aws.typepad.com/aws/2010/11/amazon-cloudfront-support...
- ashray 14y agoActually, on looking deeper it appears that cloudfront does NOT support dynamic gzipping. So unfortunately, cloudflare would be your only option. Also, google's pagespeed service (in beta) is also an option. Also free, so that's good :D EDIT: Okay, wrong again. Appears that cloudfront will serve dynamically gzipped content if your origin server responds with gzipped content to the Accept-Encoding header. So origin server = S3 is not a good idea, but origin through your own web server should work fine.
- cdoxsey 14y agoYou 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.
- wahnfrieden 14y agoA little off topic, but a fault with django-compressor is that if you ever want to use jinja2, it only supports generating the compressed versions on the fly rather than via manage.py - I made a nasty hack that lets us do that but it wasn't easy. An even worse problem is that you won't be able to transition to using async dependency loading for your JavaScript since there's no way to get the filenames of each compressed bundle that you'll need to pass to whatever lib you're using. These problems don't apply much when you're just prototyping something, but it turned out to be an awful hole we dug ourselves into when we ran into severe performance bottlenecks with Django's template rendering and serving all our JS on page load.