IMPORTANT: The primary content for this presentation is in the "Notes" tab below.
This was a presentation given to the DjangoPHX meetup group on Feb 16, 2017. It essentially amounted to a live FAQ about Django; what it is, what it can do, why to use it, etc.
It’s from the movie, right? Unchained? Well no, actually. This Django has been around a while longer; since around 2003, as a matter of fact! It got its name Django Reinhardt, who happened to be Adrian Holovaty’s favorite jazz guitarist. Adrian himself being one of the original primary authors of Django.
This leads us directly into the next question: where did Django come from? Well, as many great products, this framework rose out of actual need. It was started by Adrian Holovaty and Simon Willison when they were working at the Lawrence Journal-World newspaper. In its early infancy, it was actually just a CMS which was being used to break into web development using Python, but it’s evolved into so much more.
And what do you know, another convenient segue!
This is probably the most common question for people new to/unfamiliar with Django. And no, Django is absolutely not a CMS. In fact, out of the box, it will give you nothing but a very basic “It worked!” page, and it’s up to you to go build something. And a CMS, for those who aren’t familiar, is a “Content Management System”. You can think along the lines of WordPress. I prefer not to, but you can if you want.
Now this isn’t to say that you can’t BUILD a CMS with Django. In fact, it can be very well suited for that purpose. And there are already some very good CMSs out there built with Django, such as django-cms, mezzanine, and wagtail.
So is Django a CMS? No. Can you build a CMS with Django? Yes. But for the most part, why would you, when you’ve got such great mature options available to you already. As a matter of fact, I’m using wagtail myself to build the DjangoPHX website!
Django is “The web framework for perfectionists with deadlines.” Well, that’s the tagline anyhow.
So what does that actually mean? That means that Django is a giant opinionated toolbox. It gives you a set of tools to help you accomplish most of your web development goals, along with access to an entire ecosystem of 3rd party modules to get you the rest of the way. Out of the box, you get some very powerful tools built right in, such as url routing, multiple database connectors, a template engine, an internationalization and localization framework, multiple caching backends, and an authentication backend. You can use all of these or, honestly, none of these.
If you don’t want all of the tools, don’t use all of them! A Django application is not, inherently, complicated or bloated. You can actually write a very basic (and useless) Django application in a single file, with less than 20 lines of code. So while Django may not, in itself, be a micro-framework like Flask or Falcon, it can be used like one. You really only have to use the parts you want. But they do work much better, and more easily, if you use them all together.
Nope, not at all. You have to use NodeJS and MongoDB for that. Next question.
Just kidding! Actually, Django scales very well, as proven by some of the sites using it today: Some of the internet’s busiest sites, such as The Washington Post, National Geographic, Disqus, Instagram, Pinterest, and Facebook. If it works for their scale, I’m pretty sure it will work for yours. Yes, Facebook does use it. Not for their main website, but for some of their tools.
As to Python being slow, well… it did used to be. But recent versions have made MASSIVELY HUGE improvements in their speed. This is one of the many many reasons you should really be using Python 3. Which Django fully supports, by the way. Also, Python is just a language, with many different implementations. The one which everybody thinks of is CPython, which you download from python.org. If speed is that much of a concern, there are many other options available for different use cases which you can look into, including Jython, IronPython, Pyjion, Pyston, or my personal favorite, PyPy. That is a Python interpreter….written in Python! Pretty cool, huh? Anyhow, my point is, there are options available. They just take a bit of research. And for most people, you will never even need to go down that rabbit hole.
Which reminds me, this is another very common question. And the answer, 100% definitively, is Python 3. In fact, Django is currently in the process of removing support for Python 2. It’s old. It’s slow. It’s no longer supported. Don’t use it. Use Python 3. Your life will be better that way.
Another common question I run into is whether Django can do WebSockets. And in the same vein, people will also ask about HTTP/2.0. And the answer is absolutely yes! There are several libraries which allow a Django application to use these technologies, but until recently there was no easy to use, sanctioned method for this. Now, thanks for the amazing work of Andrew Godwin, who also brought us Django’s database migrations, and one of the very first grants from the Mozilla Open Source Support Foundation, we have Channels! To quote the README from the project, “Channels loads into Django as a pluggable app to bring WebSocket, long-poll HTTP, task offloading and other asynchrony support to your code, using familiar Django design patterns and a flexible underlying framework that lets you not only customize behaviours but also write support for your own protocols and needs.”
Moving along, a lot of people wonder what kind of database they will be stuck with when using Django. Well, the answer to that is: What kind of database do you want to use? Chances are, there’s an adapter available for it. Out of the box, Django supports PostgreSQL (my personal favorite), MySQL (boo, hiss), Oracle, and sqlite. There is a whole lot of work, sponsored by Microsoft, currently going into a SQL Server adapter, and it will eventually get included in Django core. For now though, it lives as a 3rd party application, as do many others. Yes, you can even use MongoDB if you really really really want to.
Django supports this too! By default, Django will create, alter, and fully manage all tables in your Django application. These are all considered by Django to be “managed” tables. But let’s say you want to interface with a legacy database with all kinds of tables set up already? Well that’s actually pretty easy! Just create all of the models reflecting those tables, with the “managed” flag set to False in their Meta class. And no, I don’t plan on going further into the Meta class right now; there’s a lot to that thing, so you’ll want to look that up on your own. Now, you may be saying, “Well I’ve got a legacy database with 532 tables. I don’t want to write out the models by hand for all of those!” Alright then, Django’s got you covered! Django has a concept of “management commands”, which are commands which can be run directly against your application, in its operating environment. This is actually how you do things like creating a superuser account, running the development server, and managing database migrations. But in this case, you would want to use the “inspectdb” command. Straight from the command’s help text, it “Introspects the database tables in the given database and outputs a Django model module.” Done!
Now, I’ve heard questions along this line many times: Can I use Django with X javascript framework? Most often, of late, they are of course asking about ReactJS. The simple answer is: yes. Yes you can. In fact, I have done exactly that on numerous occasions. These frameworks are frontend applications, which you can make speak to a backend Django application. In cases such as this, you would not be using Django’s built in templates, as you would not be outputting a website directly from Django. Instead, your Django application would operate as a REST API. Which leads us directly into our next question!
And the answer to this question is: Very easily. There is a package called, strangely enough, “django-rest-framework”. It has got nearly every feature imaginable for constructing a REST API, is well documented, and is very well supported. I, myself, have used it many times, and have even contributed some small bits to its development. I highly encourage its use, and have my fingers tightly crossed that it will some day be included in Django core, or at least hosted as an official project. That said, this is the defacto standard application to use for building a REST framework.
And that brings us handling to another question! This is a great question, and one often asked. Honestly, if you want to use one of those, go right ahead! It is entirely possible that it’s better suited to your needs. I recently built a Flask API for use at GoDaddy, because I needed something very basic stood up very quickly. I have used Falcon in the past for similar purposes. As a matter of fact, after building that API recently in Flask, I pondered going back and doing it over in Falcon. Falcon is kinda fun, and SUPER bare bones. And that is the point you should base your decision on. Do you want an absolutely basic bare-bones framework, where you have to find and hook in every bit of convenience, or do you want to have it already set up for you out of the box? Do you want to have to hook in a database layer, a templating engine, a method for handling configuration, and an authentication backend by yourself? I know that I usually don’t. Which is why I stick with Django most of the time.
And this brings me to my next question, which actually came up at our last meetup: Is Django’s authentication system limited? And depending on how you look at it, yes, it is. Out of the box, Django offers one single authentication mechanism: username and password. That’s it. You can’t even do email address and username out of the box, like most sites do nowadays. Sounds pretty useless, huh? Well, believe it or not, this is an example of where Django shines. The authentication system in Django is not just a single backend; it’s an entire framework, into which you can plug numerous backends. Want to do email and password? There’s a backend for that? Want to use Facebook login? There’s a backend. Github? Yup. Google? You bet. Twitter? Yeah, even that one. And countless more! Even better, these are all available through one single package, the appropriately named django-allauth. There is even 2-factor authentication available through django-two-factor-auth!
Finally, I’m sure some of you have been wondering this the through the whole presentation: What is with the pony??
Well, this little pony here is actually the official unofficial mascot of Django. After DjangoCon 2008, during which Cal Henderson talked about Django needing a mascot which was “awesome”, and “had magical powers”, Bryan Veloso published a blog post entitled “The Web Framework for Ponies”. In this post, he revealed this very pony, and things just kinda took off from there. Somebody even created djangopony.com, which still exists today. The power of the pony lives on!