Introduction

A decade of Python

I’ve been building Python software for a decade now. It is without a doubt my go-to language of choice when I want to get something done with minimal thinking and effort. While I’m undoubtedly going to continue to use Python for various things in the future—I love using it for automation tasks, one-off scripts, and various other things here and there—I’m pretty set on moving forward with Elixir on future projects. Because of this, I wanted to take some time to reflect on a decade’s worth of building web applications of varying complexity with Python.

Django

The first half of my Python decade was pretty firmly centered on Django. It grabbed my attention early with its promise of being the web framework for perfectionists with deadlines. I certainly consider myself to be a perfectionist. And deadlines are inevitable when building anything but personal projects. However, after nearly 5 years of Django, it began wearing out its welcome. Not that it wasn’t capable of doing what I needed. It just kept getting in the way at the time.

Note: I won’t spend any time bashing Django here. Django is great. It was the foundation of my career. I wouldn’t be where I am now without it.

When I spent a fairly significant amount of time wrestling to organize a project the way I wanted—and not the way Django wanted—I knew it was time to look at something else I could fully control. I’d recently been playing a bit with Sinatra at the time, and was really feeling the need for something that was as simple and lightweight as possible, used Python, and had a fairly decent developer community around it.

Flask

After a bit of looking around for something that would meet my needs, I settled on Flask. Flask—on the off chance a reader doesn’t know—is a Python microframework for web apps. And it’s a pretty good one. It has some rough edges, of course, but there are many places where it shines and is a great pleasure to use.

I started using Flask nearly 6 years ago. And it just so happens that it’s easier to more accurately recall the last 5-ish years of building software with Flask than it is to remember the roughly 5 years of Django before that.

About this series

The last 5+ years of microframeworking with Flask has been a very interesting ride. There are some things that have been pure joy. There are other things that have been immensely frustrating. There are still other things that leave me scratching my head, wondering what an author of a library/extension was thinking. I’d like to talk about a lot of these things.

This series isn’t focused on being a series of articles on how to use Flask, or how you should use Flask. For that, I can only recommend you check out the many detailed, impressive, and foundational articles on Flask that have been published over the years by Miguel Grinberg. Miguel’s Flask Mega-Tutorial was my first introduction to using Flask outside the official docs, and it was an invaluable resource for getting started.

This series is going to offer some pretty wide coverage of using Flask professionally for a variety of projects. Again, it’s not a tutorial. I hope you’ll learn some things, of course. But I’m not trying to help you go from zero to Flask app/site. I will cover Flask, but I’m also going to dive into how I use Flask—which will likely mean covering extensions, libraries, organization, testing, and a variety of other things. I’ll cover things like:

• a standard create_app approach I use in nearly all projects
• automating discovery and loading of models and views
• using view classes for more than GET, POST, PUT, etc.
• the weird state of testing Flask apps
• the odd expectation that a request is always present
• avoiding fat models
• writing code to be testable and provable
• treating MVC as a thin foundation layer
• building Flask apps with domain-driven design concepts in mind
• organizing code by domain
• and more

Up next

I think that’s enough of an introduction. Let’s get started with Organizing Flask apps with a mix of MVC + domain-driven design.