Django and FastAPI: What Comes After Flask?

Three frameworks, and how to pick one

Advanced 9 min

In this lesson

You built with Flask because it is small and gets out of the way. It is not the only option, and for some projects it is not the best one. This lesson is a map, not a tutorial: what Django and FastAPI each bring, what an ORM and an admin site actually save you, and how to choose without agonising.

Explain it like I’m 5

Frameworks are toolboxes. Flask is a small one you fill yourself, Django is a fitted workshop, and FastAPI is a light bench built for serving data quickly.

Why more than one framework exists

Every framework trades how much it decides for you against how much you can decide yourself. Nothing here is better or worse in the abstract; they sit at different points on that trade-off, which is why all three are widely used.

  • Flask is minimal. Routes and templates, and you choose everything else. Perfect for small apps and for learning, because nothing is hidden.
  • Django is batteries included. Database layer, admin site, authentication, forms, and security defaults arrive together. More to learn up front, far less to assemble.
  • FastAPI is API-focused. Built for JSON services, uses type hints to validate requests automatically, generates interactive documentation, and supports async naturally.

Two ideas worth knowing: the ORM and the admin

Django’s two biggest labor-savers are worth understanding even before you use them.

An ORM (object-relational mapper) lets you work with database rows as Python objects instead of writing SQL. You define a class; the framework creates the table and turns method calls into queries. Unit 8 covers what it is doing underneath and when writing SQL yourself is the better call.

The admin interface is a complete web UI for viewing and editing your data, generated from those same class definitions. For anything with content someone has to maintain, it removes an entire build.

Example 
# Django: describe the data as a class...
class Book(models.Model):
    title = models.CharField(max_length=200)
    year = models.IntegerField()

# ...then query it as Python, no SQL written by you.
recent = Book.objects.filter(year__gte=2000).order_by("title")
The class defines the table; the queries read as Python.

Choosing, without agonising

A rough guide that will serve you well:

  • Small tool, few pages, you want to understand every moving part → Flask.
  • Real database, users and logins, someone needs to edit content → Django.
  • A JSON API with no pages, especially a fast or async one → FastAPI.

And the most useful thing to know: the concepts transfer. Routes, requests, responses, templates, and status codes mean the same in all three. Learning a second framework is mostly learning where it keeps things.

Encode the guidance as a function. Return "Django" when the project needs an admin and a database, "FastAPI" when it is API-only, and "Flask" otherwise.

def choose(project):
    return "Flask"  # TODO: handle the Django and FastAPI cases first

projects = [
    {"name": "Blog with admin", "needs_admin": True, "has_database": True, "api_only": False},
    {"name": "Weather JSON service", "needs_admin": False, "has_database": False, "api_only": True},
    {"name": "Tiny personal tool", "needs_admin": False, "has_database": False, "api_only": False},
]

for project in projects:
    print(project["name"], "->", choose(project))

Common mistake: Choosing the biggest framework for the smallest job

Why it happens:

More features sounds like more capability, so Django looks like the safe default.

How to fix it:

Match the tool to the job. A two-route script does not need migrations, an admin site, and a settings module. Flask will be finished before Django is configured.

Common mistake: Assuming an ORM means you never need SQL

Why it happens:

It hides queries so completely that they stop feeling real.

How to fix it:

Learn what it generates. When something is slow or a query gets complicated, you need to see the SQL underneath, which is exactly what Unit 8 covers.

Common mistake: Rewriting a working app to switch framework

Why it happens:

A new framework looks like it would have made things tidier.

How to fix it:

Switch when you hit a real limitation, not out of curiosity. A working Flask app is worth more than a half-finished Django rewrite.

What does Django give you that Flask does not, out of the box?

Which framework is aimed squarely at building JSON APIs?

What does an ORM do?

Mini exercise (medium)

Write recommend(project) taking a dict with api_only, needs_admin, has_database, and page_count. Return a (framework, reason) tuple: FastAPI for API-only projects, Django when it needs an admin or has a database with more than five pages, and Flask otherwise, each with a one-line reason.

Practice here. Fill in the missing piece and click Run to try your answer in place.

def recommend(project):
    return ("Flask", "small and simple")  # TODO: handle FastAPI and Django first

print(recommend({"api_only": True, "needs_admin": False, "has_database": False, "page_count": 0}))
print(recommend({"api_only": False, "needs_admin": True, "has_database": True, "page_count": 12}))
print(recommend({"api_only": False, "needs_admin": False, "has_database": False, "page_count": 2}))

What to learn next

You mapped the landscape: Flask stays minimal and shows you everything, Django arrives with an ORM, an admin interface, and authentication already assembled, and FastAPI is built for JSON services with type-hint validation and native async. The concepts (routes, requests, responses, status codes) carry across all three.

That completes Unit 7. You can now pull data off the web and serve it back out. The obvious next question is where all that data lives once the script ends, which is exactly what Unit 8 answers with SQLite and regular expressions.