3 ms·

Impressively long way around to avoid relying on Nginx or Apache. How does it perform in comparison?

senko 13y ago
That's an excellent question (and an idea for a follow-up blog post). In most cases I'd go with Django+Gunicorn+Nginx setup (as described here http://goodcode.io/blog/django-nginx-gunicorn/ http://goodcode.io/blog/django-nginx-gunicorn/), with Nginx (or Apache) just being the reverse proxies and serving the static assets. Django is still needed here if you want to have form processing (unless you use 3rd party service), and useful if you want to have templating (unless you want to use Jekyll, Hyde, or similar static-generator tools). So, while Nginx/Apache would definitely speed up things, they're not enough. On the other hand, you can build a reasonably[0] fast "almost" static site with Django, and have it deployed on either your Linux server, or Heroku, or another PaaS. [0] What's "reasonably fast"? my hunch tells me that the simple setup outlined here could take quite a beating (unless intentionally attacked with slowloris or similar attacks, or serving heavy static assets). It'll be fun to test it.
- raverbashing 13y ago
  It's much easier (deployment/maintenance) using Gunicorn/uwsgi feeding into Nginx/Apache than using a module within Nginx/Apache Especially with virtualenvs and such.
- sliverstorm 13y ago
  What's "reasonably fast"? I wish more people thought of http://forum.dlang.org/ http://forum.dlang.org/ as a reference example when they asked that question.
- mbell 13y ago
  You can also setup a CloudFront deployment and point it to your app server as the origin. Fast and cheap way to serve static files without having to configure nginx/apache. Well...cheap as long as you don't need SSL.
falcolas 13y ago
One nice thing with Django is that you can separate out truly static files into your apps static folder, and configure nginx to serve the /static/ URL. Configure a `STATIC_ROOT` for your app, run: ./manage.py collectstatic and you have nginx serving the truly static files while still allowing Django to manage your non-static assets. This is how I run my site, and it works pretty darned well. Let nginx do the caching of static files, compression, and SSL management, letting Django just worry about its small domain of non-static files. The one downside is that nginx will not necessairly detect when a static file has changed, requiring a bit of effort to ensure that new versions of a static file are puled, either through filename versioning, or `?1` on the end of your static URLs.
- bpicolo 13y ago
  That's not unique to Django. You can always send static assets through the web server.
  - falcolas 13y ago
    Absolutely. But, this being an article on Django, serving a combination of static and semi-static assets, commenting on this Django feature seemed appropriate.
- StavrosK 13y ago
  IIRC, django-compressor will do that automatically.

senko 13y ago

That's an excellent question (and an idea for a follow-up blog post). In most cases I'd go with Django+Gunicorn+Nginx setup (as described here http://goodcode.io/blog/django-nginx-gunicorn/ http://goodcode.io/blog/django-nginx-gunicorn/), with Nginx (or Apache) just being the reverse proxies and serving the static assets. Django is still needed here if you want to have form processing (unless you use 3rd party service), and useful if you want to have templating (unless you want to use Jekyll, Hyde, or similar static-generator tools). So, while Nginx/Apache would definitely speed up things, they're not enough. On the other hand, you can build a reasonably[0] fast "almost" static site with Django, and have it deployed on either your Linux server, or Heroku, or another PaaS. [0] What's "reasonably fast"? my hunch tells me that the simple setup outlined here could take quite a beating (unless intentionally attacked with slowloris or similar attacks, or serving heavy static assets). It'll be fun to test it.

raverbashing 13y ago
It's much easier (deployment/maintenance) using Gunicorn/uwsgi feeding into Nginx/Apache than using a module within Nginx/Apache Especially with virtualenvs and such.
sliverstorm 13y ago
What's "reasonably fast"? I wish more people thought of http://forum.dlang.org/ http://forum.dlang.org/ as a reference example when they asked that question.
mbell 13y ago
You can also setup a CloudFront deployment and point it to your app server as the origin. Fast and cheap way to serve static files without having to configure nginx/apache. Well...cheap as long as you don't need SSL.

falcolas 13y ago

One nice thing with Django is that you can separate out truly static files into your apps static folder, and configure nginx to serve the /static/ URL. Configure a `STATIC_ROOT` for your app, run: ./manage.py collectstatic and you have nginx serving the truly static files while still allowing Django to manage your non-static assets. This is how I run my site, and it works pretty darned well. Let nginx do the caching of static files, compression, and SSL management, letting Django just worry about its small domain of non-static files. The one downside is that nginx will not necessairly detect when a static file has changed, requiring a bit of effort to ensure that new versions of a static file are puled, either through filename versioning, or `?1` on the end of your static URLs.

bpicolo 13y ago
That's not unique to Django. You can always send static assets through the web server.
- falcolas 13y ago
  Absolutely. But, this being an article on Django, serving a combination of static and semi-static assets, commenting on this Django feature seemed appropriate.
StavrosK 13y ago
IIRC, django-compressor will do that automatically.