Recently I gave Python’s Django a try. Django is a free and open source web framework that allows for the quick creation of any kind of website, ranging from blogs to stores to Git server front-end. Django is extensible and has thousands of modules or “packages”. One of the best things about this project is the abundance of high quality documentation and learning resources. So much so that I decided to create a post to share what worked the best for me. In this post, I will highlight the best resources I came across and the order you should ingest them in.
Starting Out / guides and things worth considering
First things first, if there is great documentation available from the developers themselves, use it! Their tutorial should be the starting point for most users trying out Django for the first time, and I highly recommend you follow it closely even if you don’t want to create a silly polls app. The tutorial is clear, concise, and gives you a good picture of how Django serves pages to clients. If you blow through the tutorial and found it easy (if not, see next paragraph), then maybe try git cloning Cookiecutter-Django and reading Two Scoops of Django as a companion guide for more in depth information. Cookiecutter is nice because it bundles together basic functionality like user authentication, emailing, security features, support for deployment with Docker or Heroku, caching with Redis and many more nice things (Bootstrap!). I strongly suggest you set up your project in a virtualenv or Docker container, that way you don’t have to worry about version conflicts on your machine. Setting things up this way with Cookiecutter makes it easy to keep track of your dependencies and versions. You should try to decide on how you are going to deploy before you start building things.
It’s about this point where all these new things might start to blur together for someone just getting started, which reminds me of a great introductory post to Django and the ecosystem around it. Clouds, containers, webapps – the author finds a fun and memorable way of explaining all these new concepts.
If you stumbled a little bit on the official Django tutorial, try the Django Girls tutorial. This tutorial does not make any assumptions about the background knowledge of the reader and progresses to completing a Django app relatively quickly and deploying.
Whichever route you take, you’ll need to set up a database before you can really begin. The Django documentation doesn’t really steer you in any particular direction as far as which database you should choose and why, so I’ll pick a side: you should go with PostgreSQL to save yourself from future headaches. It is used more frequently, interfaces better with most Django packages, and is overall a nice object-relational database management system. If you are on Linux, you’ll need to know how to create users/tables in the PostgreSQL shell (Digital Ocean does a fine job explaining). Once you have installed a database and created a login for it, all you need to do is add those credentials to your settings.py and Django will create the tables it needs and update them through models and the admin web UI (and the Python/Django shell, which is nice when you just want to make a small change).
Things to do next / write your own tests.
Once you have your site up and running with a few pages and an app or two, you’ll probably want to do some house keeping. Creating maintainable and reusable code will be your best friend if you decide to move forward with Django. So do yourself a favor and write some good functional tests. “Obey the testing goat” is a free online book that delves deep into creating test cases for your site. By taking a relatively small amount of time now to code up some tests, you’ll potentially save yourself tens of, even hundreds of hours of debugging over the coming months/years. Sure you can write code well enough most of the time, and can catch errors in your development environment, but what is going to tell you that your syntactically correct but semantically incorrect code is about to drop an entire table from your database, or send receipt information to the wrong user? There may be some built in safety nets in Django (see Autoescaping and CSRF) , but most other unintended behavior, test cases are the best defense.
Make it look nice / we all need to learn web languages sometime or another
Ok, so at some point you’re going to want all your hard work to look nice. Web design is an industry, but thankfully with Django you don’t have to be an expert. Just take some pages from the Bootstrap library and adjust it to your liking. Somewhere within the bootstrap zip are HTML templates, .css, and .js files you can simply plug into your /static directory and have a nice responsive page ready to go. The templates that come with the Cookiecutter installation of Django will have references to the .css and .js files hosted on other domains. So your templates will work and look nice out of the box. But it’s probably best to have those resources stored locally. If you’re not comfortable with web stuff, head on over to w3schools – it’s probably one of the most impressive free learning resources I’ve come across over the years. The Bootstrap website also has some good examples you can pretty much just start copying/pasting to suit your own needs.
Deployment / fire it up and go live
The Cookiecutter repo I linked to earlier is nice because it makes deploying your app with Heroku or Docker much more convenient. When you install with Cookiecutter, you will be asked a series of questions about integrations you can include. You should say yes to at least one, if not both, so you can have your .yml or procfile generated for you, should you decide to deploy with Docker or Heroku. This will also change how some of your project is structured, by splitting settings.py into “base.py” and “local.py” to make testing/debugging your apps locally possible without much hassle. Continuing the theme of free, Heroku has a free plan for “deployment in a limited sandbox” where you get 512mb of RAM and 1 worker. Note that if you have an app with any bulk at all to it, you may have to look at a paid plan or setting up a CDN because the Heroku free plan might not have enough space (10,000 rows on PostgreSQL will go quickly). If your needs to manage documents and media files, then it might be worth it to think ahead about how you will host these files and what you will do when you want to change hosts. Link to relevant documentation. If you set things up right, switching CDNs should be pain free.
To summarize how the two deployment systems are different concisely: Heroku is a service (a platform as a service or PaaS) that takes care of a lot of the sys admin details that might slow you down. Docker is a software (with a free community edition and an enterprise version) that, for lack of a more detailed description, creates bare bones virtualization containers on a per app basis. Docker takes a build recipe “from this distro, install and update these packages, and change these settings…”, also known as the Dockerfile, and then a .yml configuration file that tells it exactly how to install the app and hook up necessary parts like the web server and database. These Docker containers are much lighter than a normal virtual machine which may take a gig or two of space – I’ve seen containers ranging from just over 100mb to 500-600mb. This makes spinning up a website from scratch extremely fast and efficient. If you decide to go the Docker route, I highly recommend following this resource as it uses cookiecutter too: Development and Deployment of Cookiecutter-Django via Docker.
Optional Packages and Third Party Services / to be done
WhiteNoise – Allows your Django app to serve static files itself, when normally a CDN is used. Viable for small to medium sized projects and very convenient.
Celery – Async task queue, very handy.
Well, you made it to the end. That means you’re probably at least a little interested in using Django. I would encourage you to do so, it was certainly a positive experience for me. You might also be debating between Django and another well known Python web framework – Flask. While I have not tried Flask, what I can say is this: Django is the “batteries included” solution, and takes care of things like user authentication that necessitates robust implementations. Flask leaves more up to the developer, which can be both good and bad. They are different tools for different use cases certainly, but overall I’d say Django is a better choice for beginners. Hopefully this post helps anyone planning to start a project soon, and please do comment about any other free resources that helped you learn Django.