by Gary Worthington, More Than Monkeys

At some point, you’re going to outgrow Flask. Maybe you’ve duct-taped enough decorators to last a lifetime or maybe you’re tired of rolling your own validation, auth, and pagination. Either way, the next serious decision for API development in Python usually comes down to one of either FastAPI or Django with DRF (Django Rest Framework).

Both are excellent; Both are production-ready; But they serve different architectural worldviews, and if you pick the wrong one, you’ll either be fighting the framework or building stuff it could’ve handled for you.

This article is not about which one is “better.” It’s about helping you make the right choice, based on:

• your team’s maturity
• your product’s lifecycle
• and the constraints you actually care about (like performance, testing, developer experience, and maintainability)

We’ll walk through code examples, unit tests, team considerations, AWS hosting strategies, and long-term trade-offs. If you’ve ever cursed a leaky abstraction at 3am, this one’s for you.

TL;DR

FastAPI is:

• async-native and type-driven
• excellent for microservices, APIs, and async workloads
• extremely fast, modular, and developer-friendly
• a bit more ‘barebones’ (no admin, ORM, or built-in features)

Django + DRF is:

• a monolithic framework with batteries included
• perfect for CRUD-heavy apps, admin dashboards, and business logic
• slower under load, but easier to scaffold
• great for mixed teams and rapid internal tools

1. Project Philosophy: Monolith vs Microservice

Django + DRF assumes you’re building a full-stack monolith. It provides everything out of the box: ORM, admin interface, form handling, auth, and templating. You can get a working API with an admin UI in minutes.

FastAPI, on the other hand, assumes you’re building lightweight services. It gives you routing, validation, and OpenAPI docs, but leaves everything else up to you. Perfect for when you want flexibility and control.

2. Developer Experience

FastAPI Example

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class Widget(BaseModel):
    name: str
    stock: int

@app.post("/widgets/")
async def create_widget(widget: Widget):
    return {"created": widget}

You get Pydantic validation, OpenAPI docs, and full type safety. All from just from using Python type hints.

Django + DRF Example

from rest_framework import serializers, viewsets
from rest_framework.decorators import api_view
from rest_framework.response import Response
from .serializers import WidgetSerializer
from .models import Widget

class WidgetSerializer(serializers.ModelSerializer):
    class Meta:
        model = Widget
        fields = ['name', 'stock']

@api_view(['POST'])
def create_widget(request):
    serializer = WidgetSerializer(data=request.data)
    serializer.is_valid(raise_exception=True)
    return Response({"created": serializer.validated_data})

DRF is more verbose, but it comes with baked-in functionality: permissions, authentication, browsable APIs, and ORM integration. Ideal for teams who want a lot for free.

3. Performance: Async or Bust?

If you need concurrency (eg. handling lots of simultaneous I/O like third-party APIs or WebSockets) FastAPI will outperform DRF. It’s async by default, and built on Starlette.

That said, for basic CRUD operations or low-traffic admin tools, Django’s performance is perfectly fine.

Use FastAPI when:

• You need async views and event loops
• You’re calling third-party APIs frequently
• You’re deploying into resource-constrained environments

Use Django + DRF when:

• You care more about developer speed than raw throughput
• You’re building complex relational logic with rich admin requirements
• You’re not dealing with async at all

4. Testing APIs

Both frameworks offer excellent testing support.

FastAPI

from fastapi.testclient import TestClient
from main import app

client = TestClient(app)

def test_create_widget():
    response = client.post("/widgets/", json={"name": "Spanner", "stock": 20})
    assert response.status_code == 200
    assert response.json()["created"]["name"] == "Spanner"

Django + DRF

from rest_framework.test import APIClient
import pytest

client = APIClient()

@pytest.mark.django_db
def test_create_widget():
    response = client.post("/widgets/", {"name": "Spanner", "stock": 20}, format="json")
    assert response.status_code == 201
    assert response.data["name"] == "Spanner"

DRF gives you richer test support for fixtures, transactions, and user auth.

FastAPI gives you leaner, faster tests that are ideal for service isolation.

5. Databases and ORM

Django ORM is a joy to use. Migrations, relationships, admin integration — it’s all built-in. It’s one of Django’s greatest strengths.

FastAPI doesn’t come with an ORM. You’ll likely reach for:

• SQLAlchemy (sync or async, but steep learning curve)
• Tortoise ORM (async, Django-like, but less mature)

You’ll need to manage migrations and DB sessions yourself.

Use Django if you want built-in migrations and a consistent ORM. Use FastAPI if you want more control and flexibility, and don’t mind stitching things together.

6. Team & Product Fit

Choose Django + DRF if:

• You need to build fast with fewer decisions
• Your team includes full-stack or junior developers
• You need a web UI or admin interface
• Business logic is tied closely to models

Choose FastAPI if:

• You’re building backend APIs only
• You want full async support out of the box
• You prefer clean, typed Python
• You’re composing a microservices architecture

7. Hosting FastAPI vs Django in AWS

Hosting FastAPI in AWS

FastAPI works beautifully in containerised setups:

• Compute: ECS Fargate or EC2 with Uvicorn + Gunicorn
• Load Balancer: ALB (Application Load Balancer)
• Storage: S3 for static files and media, RDS or DynamoDB for databases
• CI/CD: GitHub Actions or AWS CodePipeline pushing Docker images to ECR
• Monitoring: CloudWatch, optionally X-Ray or Datadog

A typical setup involves spinning up FastAPI as a Docker container and wiring it up to ECS or EKS.

Hosting Django + DRF in AWS

You can host Django in multiple ways:

• Simplest: Elastic Beanstalk (easy deployment, handles scaling)
• Advanced: ECS or EC2 with Gunicorn/Daphne
• Static/media files: S3 with WhiteNoise or CloudFront
• Database: RDS Postgres or MySQL
• CI/CD: GitHub Actions or EB CLI with environment configs

Elastic Beanstalk is a great starting point. It handles deployments, load balancing, and scaling with minimal setup. When you need more control, ECS or EC2 gives you deeper customisation.

8. My Take: How We Choose at More Than Monkeys

We use FastAPI when:

• We need high throughput or async support
• We’re building APIs, not full-stack apps
• The service will live in a container or be part of a microservice setup

We use Django + DRF when:

• The project has a lot of business rules, users, roles, or internal UIs
• We want to spin up an admin interface fast
• The client needs features like authentication, permissions, and RBAC out of the box

Sometimes we use both:

• FastAPI for the public-facing API gateway
• Django for internal admin and complex model logic
• Shared database (RDS), separate deployment pipelines

9. Can You Use Django and FastAPI Together?

Absolutely. In fact, it’s a pattern we’ve used more than once, especially when we want to:

• Leverage Django’s ORM and admin for internal tools and dashboards
• Expose a modern, async FastAPI interface to the outside world
• Avoid duplicating business logic or data access layers across stacks

This hybrid approach gives you the best of both worlds. But it comes with trade-offs, especially around database sessions and execution context.

How It Works in Practice

We structure the project like this:

/my_project/
├── django_app/
│   ├── manage.py
│   ├── settings.py
│   └── app/
│       ├── models.py
│       ├── admin.py
│       ├── views.py
├── fastapi_app/
│   ├── main.py
│   ├── routes/
│   └── depends_on_django.py

The Django app runs as usual: ORM models, migrations, admin UI, etc. The FastAPI app acts as a thin async API layer that queries the same database via Django’s ORM , without reimplementing models or business logic.

Example: Using Django Models Inside FastAPI

Let’s say you’ve got this model in Django:

# django_app/app/models.py
from django.db import models

class Widget(models.Model):
    name = models.CharField(max_length=100)
    stock = models.IntegerField()

You can then use this model directly inside a FastAPI endpoint:

# fastapi_app/routes/widgets.py
from fastapi import APIRouter
from django_app.app.models import Widget
from fastapi.responses import JSONResponse

router = APIRouter()

@router.get("/widgets/")
def list_widgets():
    widgets = Widget.objects.all().values("id", "name", "stock")
    return JSONResponse(list(widgets))

This works because Django has already initialised its ORM; you just need to ensure the FastAPI app runs in a context where Django is bootstrapped.

Initialising Django Inside FastAPI

Before you import any Django models, make sure Django is set up:

# fastapi_app/depends_on_django.py
import os
import django

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "django_app.settings")
django.setup()

You import and run this early inside your FastAPI main.py, before touching any Django models.

The ORM Gotchas

Django’s ORM is sync-only. This matters in FastAPI because you’ll often be working inside async def endpoints.

What happens if you call Widget.objects.all() in an async endpoint?

You block the event loop.

Workaround #1 — Thread executor:

Wrap sync ORM calls using run_in_threadpool:

from starlette.concurrency import run_in_threadpool

@router.get("/widgets/")
async def list_widgets():
    widgets = await run_in_threadpool(lambda: list(Widget.objects.values()))
    return widgets

Workaround #2 — Use sync views in FastAPI:

Just use def instead of async def. FastAPI will handle them safely:

@router.get("/widgets/")
def list_widgets():
    return list(Widget.objects.values())

For read-heavy APIs, this is often enough. For write-heavy or high-throughput services, consider separating concerns further.

When to Split the Stack

This hybrid approach is great during MVP and early scale phases. But eventually you might want to consider:

• Migrating your public-facing API fully to FastAPI + SQLAlchemy for better async performance
• Keep Django purely for internal admin and dashboards

You don’t have to decide up front. We’ve launched products using both stacks, then gradually separated them out as needs changed.

Summary

Yes, you can use Django and FastAPI together safely, cleanly, and without duplicating logic. You get:

✅ Django’s battle-tested ORM and admin
✅ FastAPI’s async performance and OpenAPI support
✅ A shared data model and business layer

It’s not the easiest setup, but it’s a pragmatic one, especially when you want to iterate fast without compromising long-term flexibility. I’m noty advising for against it, just providing some info to help you decide.

Final Word

FastAPI is fast (c’mon, its in the name!), async-native, and beautifully typed. Django with DRF is full-featured, time-tested, and comes with a lot out of the box.

There’s no right answer, just trade-offs. Choose the one that suits your team, your product, and the direction you’re heading.

Need Help?

We’ve built platforms using both stacks - FastAPI for async-heavy APIs, Django for rich business apps. If you’re not sure which to pick or want help designing a future-proof architecture, drop us a line.