Why Flask?
Every framework makes a bet about how much it should decide for you. Flask's bet is that it should decide as little as possible — hand you a small, dependable core and let every other choice be yours. Before writing a single line of Bookshelf, it's worth understanding exactly what that bet means in practice, because it shapes almost every decision we'll make for the rest of this track.
The Microframework Philosophy
Flask calls itself a microframework, and that word is often misread as "a
framework with fewer features" or "a framework for small projects." Neither is quite right. What
"micro" actually refers to is the size of Flask's core: routing (mapping a URL to a
Python function), request and response handling, and Jinja2 templating. That's essentially the
whole package when you pip install flask. There's no database layer bundled in, no
built-in login system, no admin panel, no forms library.
That doesn't mean Bookshelf will lack a database, user accounts, or forms — it means each of those capabilities arrives as a separate package you deliberately choose and wire in: Flask SQLAlchemy for the database layer, Flask-Login for authentication, Flask-WTF for forms. Flask's job is to be the small, stable foundation those pieces snap onto.
Why a Small Core Matters
The practical benefit of this design shows up the moment a project's needs diverge from what a "batteries-included" framework assumed. With Flask, you're never fighting a big framework's opinions about which ORM to use, how authentication should work, or how forms should be structured — because it doesn't hold opinions about those things at all. Want SQLAlchemy for Bookshelf's models but a teammate's other project prefers a different database toolkit entirely? Both are equally "correct" Flask usage, because Flask itself never took a position.
Flask vs Django: A Side-by-Side Comparison
Since Django is this site's other major Python web framework track, a direct comparison is the fastest way to make Flask's design concrete:
| Capability | Django | Flask |
|---|---|---|
| Database / ORM | Built in (Django ORM), no extra install | Not included — you add Flask-SQLAlchemy (or another ORM) yourself |
| Admin interface | Full auto-generated admin panel out of the box | Not included — you build any admin views you need, or add a third-party extension |
| Authentication | Built-in user model, login views, password hashing | Not included — you add Flask-Login and write your own registration/login views |
| Forms | Built-in forms and model-forms library | Not included — you add Flask-WTF for form handling and validation |
| Project layout | Enforced by startproject/startapp commands | Not enforced — a whole app can be one file, or a package you structure yourself |
| Learning curve | More to learn up front, but less to decide | Less to learn up front, but more decisions land on you as the project grows |
Neither color in that table is "wrong" — they're two different answers to the same question of who should make these decisions: the framework, or you.
Real Projects Built on Flask
Flask isn't a toy framework kept alive by tutorials — it has powered real production systems at meaningful scale. Pinterest's early backend infrastructure ran on Flask before the company's traffic grew large enough to need a more distributed architecture. Netflix has published details on using Flask for internal tools and operational dashboards, where a small, flexible framework was a better fit than a heavier one. LinkedIn has also used Flask for internal services. The common thread across all of these: teams that wanted precise control over a service's structure, rather than inheriting a large framework's full set of conventions.
When Flask Is a Great Fit
Based on that philosophy, a few kinds of projects tend to suit Flask especially well:
- Small-to-medium APIs — a backend that mostly returns JSON doesn't need an admin panel or a template engine it will barely touch
- Projects where you want full control over structure — if you already know how you want models, views, and configuration organized, Flask won't get in the way of that plan
- Prototypes that need to stay lean — a single
app.pywith a handful of routes can be a working proof-of-concept in minutes, with no scaffolding required - Services with unusual requirements — if a project needs a non-standard database, an unusual auth flow, or a specific combination of libraries, Flask's lack of built-in opinions means nothing has to be worked around
When Django's Batteries-Included Approach Wins
In the interest of an honest comparison rather than marketing for either side: some projects genuinely move faster on Django. A large, content-heavy site that needs a working admin panel on day one, built-in user management, and a conventional structure the whole team already recognizes will often reach production faster with Django, precisely because so many of those decisions come pre-made. Flask can absolutely build the same site — but you'd be assembling equivalents to several of Django's built-ins (an admin interface, a forms library, a user model) yourself, which is real, billable time.
How This Track Uses Flask for Bookshelf
Over the next 37 lessons we'll assemble Bookshelf's stack piece by piece, in the Flask spirit:
Flask-SQLAlchemy to model User, Shelf, Book, and
Tag and their relationships; Flask-WTF for the forms that create and edit them;
Flask-Login for authenticating users; and Flask's own routing and Jinja2 templating tying it all
into working pages. Nothing arrives pre-installed — every piece gets added deliberately, in
the lesson where it's actually needed.