Answer by Joseph Misiti:

Here are some things I have learned over the years that have helped me:

1. Try to setup your projects with the following directory structure

/myproject
   /apps
   /configs
   /settings
   /deploy
   /static
   /templates
   urls.py
   fabfile.py

apps – contains subfolders with specific functionality (static, accounts, etc)

configs – stores all configuration related scripts (gunicorn, nginx, celery, mongdb, redis, etc). It's useful because you can use fabric (put command) to copy these over to the correct locations on a server

deploy – contains all deploy scripts, set up in similar manner to this project[1]

A lot of examples you see online put everything into a single fabfile.py, but that gets really messy as a project gets larger. Having a deploy folder that is organized like django-fabtastic allows you to cut-and-paste it over into other projects if you are using the same technologies

settings – a folder (not a file like settings.py) that is setup based on this reference [2]

You could use local_settings.py, production_settings.py etc. but that yipit guys got it right and that is definitely the way to go

static – contains js, css, images, types/fonts

templates – all your html files

2. Use gunicorn[3] instead of apache. If for no other reason, a print statement in code wont crash the entire site. Gunicorn is less bloated and very easy to configure. And large sites like instagram are using it at web scale so dont let people tell you its not a good idea – it will make your job easier and you can leave the office and drink a lot more beer

3. Use celery for anything that can be made asynchronous (sending emails, uploading photos, etc). Dont make the user wait for the request to return, push it onto a queue and let celery do the work for you. Also, do not use rabbitmq as the celery backend, use redis. RabbitMQ is supposedly more stable and messages cant get lost, but it's also a pain to configure and 99% of people can afford to lose a message because a lost message really doesnt matter that much.

4. If you are going to use a SQL-based solution, then use South for migrations. I  have had a lot of success migrating away (completely) from Django's ORM[7] and sticking to PyMongo[5] + MongoEngine[5]. Development is way more fun if you're using MongoDB, if you do not believe me, try it out. Say goodbye to painful schema migrations. Ya, and I know, MongoDB doesn't scale, but guess what, it does.

5. If you need to make a REST API, then use Django-TastyPie[8]. Unfortunately, there is currently no good solution for constructing RESTful APIs if your backend is MongoDB. If I am wrong, provide a link please because no one on StackOverflow could[9]

6. Do not use test.py for unit tests, put them in a directory called tests/__init__.py and import them in that __init__.py file. Also, trying using
nose, it's really cool.[10]

7. Look and good open source project for reference. The most obviously is the Django project itself[11], but Newsblur[12] and Everyblock[13] are also great references:

That is it- that is 3 years worth of trail-and-error for free!

[1] https://github.com/duointeractive/django-fabtastic
[2] http://tech.yipit.com/2011/11/02/django-settings-what-to-do-about-settings-py/
[3] http://gunicorn.org/
[4] https://github.com/ask/django-celery
[5] https://github.com/mongodb/mongo-python-driver
[6] https://github.com/hmarr/mongoengine
[7] https://docs.djangoproject.com/en/dev/topics/db/queries/
[8] https://github.com/toastdriven/django-tastypie
[9] http://stackoverflow.com/questions/8333874/how-do-i-create-simple-rest-apis-in-django-with-a-mongoengine-backend
[10] http://readthedocs.org/docs/nose/en/latest/
[11] https://github.com/django/django
[12] https://github.com/samuelclay/NewsBlur
[13] https://github.com/dkukral/everyblock

What are some best practices for Django development?