Django - freeCodeCamp.org

How to Build a Scoped Note-Taking API with Django Rest Framework and SimpleJWT

Prabodh Tuladhar — Tue, 05 May 2026 19:23:01 +0000

If you've built a Django API and you're wondering how to add authentication so that each user can only access their own data, you're in the right place.

Most Django tutorials teach you session-based authentication. That works fine when your frontend and backend live on the same server. But the moment you separate them – say, a React app on Netlify talking to a Django API on PythonAnywhere – then sessions start to break down.

Cookies don't travel well across different domains, and suddenly your login system stops working.

That's where JSON Web Tokens (JWT) come in. JWTs give you a stateless, cookie-free way to authenticate users. They work seamlessly across domains, devices, and platforms. The server doesn't need to remember anything. It just verifies the token's signature and knows exactly who's making the request.

But authentication is only half the problem. Once you know who a user is, you still need to control what they can see. This is where scoping comes in.

Scoping means ensuring that each user can only access their own data. User A should never be able to read, edit, or delete User B's data (notes in our case), even if they somehow guess the right ID.

In this tutorial, you'll build a a personal note-taking API where users can register, log in with JWT tokens, and store notes that only they can access.

Along the way, you'll implement a custom user model, configure SimpleJWT for token-based authentication, and write scoped views that lock each user's data behind their own credentials.

What We'll Cover:

Prerequisities
What is JWT and Why Use It Over Session Authentication?
- How Session Authentication Works
- How JWT Authentication Works
Step 1: How to Set Up the Project and Install the Dependecies
Step 2: How to Create a Custom User Model
Step 3: How to Define the Note Model
- 3.2 How to Apply Migration
- 3.3 How to Register Models in the Admin
Step 4: How to Create the Serializer
- 4.1 How to Create UserSerializer
- 4.2 How to Create NoteSerializer
Step 5: How to Configure SimpleJWT
- 5.1 How to Update REST Framework Settings
- 5.2 How to Add Token URL Endpoints
Step 6: How to Build the Authentication Logic
Step 7: How to Implement Scoped Views
- 7.1 How to Create a NoteViewSet
- 7.2 Why This Matters: Preventing ID Enumeration Attacks
Step 8: How to Connect a URL
- 8.1 How to Create App-level URLs
- 8.2 How to Verify the Project-Level URLs
Step 9: How to Test the APIs with Postman
Step 10: How to Handle Token Expiration with Refresh Tokens
How You Can Improve This Project
Conclusion

Here's what this tutorial covers:

How to set up a custom user model (and why you should always do this)
How to configure SimpleJWT for access and refresh token authentication
How to build serializers that protect sensitive fields
How to scope your API views so users only see their own data
How to test the entire flow using Postman

Let's get started

Prerequisities

Before you begin, make sure you're comfortable with the following:

Django fundamentals: You should understand how Django projects and apps work, including models, views, URLs, and migrations.
Django REST Framework basics: You should be familiar with serializers, viewsets or API views, and how DRF handles requests and responses.
Basic command line usage: You'll run commands in your terminal throughout this tutorial.

Tools you'll need installed:

Python 3.8 or higher
pip (Python's package manager)
A code editor like Visual Studio Code
Postman (or any API testing tool) for testing your endpoints. You'll use this to send requests to your API.

What is JWT and Why Use It Over Session Authentication?

Before you write any code, it's important to understand what problem JWTs solve and why Django's built-in session authentication isn't always enough.

How Session Authentication Work

Django ships with a session-based authentication system. Here's how it works at a high level:

A user sends their username and password to the server.
The server verifies the credentials and creates a session which is a small record stored in the server's database that says "this user is logged in."
The server sends back a session ID as a cookie. The browser stores this cookie automatically.
On every subsequent request, the browser sends the cookie back to the server. The server looks up the session ID in its database and says "ah, this is User A. Let them through."

This works perfectly when your frontend and backend live on the same domain. The browser handles cookies automatically, and Django manages sessions in the database without you thinking about it.

But this approach has some limitations.

The cross-domain problem: If your React frontend lives at app.example.com and your Django API lives at api.example.com, cookies become tricky. Browsers enforce strict rules about which domains can send and receive cookies.

You can work around this with CORS (Cross-Origin Resource Sharing) headers and special cookie settings, but it adds complexity and can be fragile.
The scalability problem: Every active session is stored in the server's database. If you have 10,000 users logged in at the same time, that's 10,000 session records the server has to look up on every single request. As your application grows, this lookup becomes a bottleneck.
The mobile problem: Mobile apps don't handle cookies the same way browsers do. If you're building an API that will serve both a web app and a mobile app, session cookies create extra headaches.

How JWT Authentication Works

JWTs take a fundamentally different approach. Instead of storing session data on the server, they put the authentication information directly into the token itself.

Here's how the flow works:

A user sends their username and password to the server.
The server verifies the credentials and creates a JWT – a long encoded string that contains information like the user's ID and when the token expires.
The server sends this token back to the client. The client stores it (usually in memory or local storage).
On every subsequent request, the client includes the token in the request header. The server reads the token, verifies its signature, and says "this is User A. Let them through."

Notice the key difference: the server never stores anything.

It doesn't look up a session in a database. It simply reads the token, checks its cryptographic signature to make sure nobody tampered with it, and extracts the user information. That's why JWTs are called stateless – the server doesn't maintain any state about who is logged in.

This solves the cross-domain problem because tokens are sent in the request header, not as cookies. Headers work the same way regardless of which domain the request comes from.

This solves the scalability problem because the server doesn't store sessions. Verifying a token is a quick cryptographic check, not a database lookup.

This solves the mobile problem because any client that can send HTTP headers can use JWT. Mobile apps, desktop apps, other servers – they all work the same way.

Step 1: How to Set Up the Project and Install the Dependecies

1.1 How to Create the Project

Open your terminal, navigate to where you want your project to live, and run the following commands:

mkdir notes-project

cd notes-project

1.2 How to Create a Virtual Environment and Install the Required Dependencies

You will create a virtual environment here. Type the following command:

python3 -m venv venv

The above command creates a virtual environment inside a folder called venv. The first venv is the command and the second venv represents the name of the folder. You can name the folder anything though venv is usually preferred.

To activate the virtual environment, we need to use the following command:

On macOS/Linux:

source venv/bin/activate

On Windows:

venv\Scripts\activate

You'll know it worked when you see (venv) at the beginning of your terminal prompt. From this point on, any Python packages you install will only exist inside this virtual environment.

With the virutal environment activated, install Django, Django Rest Framework, and Simple JWT Framework using the command:

pip install django djangorestframework djangorestframework-simplejwt

You can verify everything installed correctly by running:

pip list

You should see all three packages listed along with their dependencies.

1.3 How to Create the Project and the App

Run the following command to create the Django project:

django-admin startproject notes_core .

The dot at the end is important. It tells Django to create the project files in your current directory instead of creating an extra nested folder.

Now let's type this command to create the app:

python manage.py startapp notes

1.4 How to Register the App and Django Rest Framework (DRF)

Open notes_core/settings.py and add rest_framework and notes in the INSTALLED_APPS list:

Django now knows about your new app and the REST framework. Let's move on to the most important architectural decision you'll make for this project.

Step 2: How to Create a Custom User Model

If you've built Django projects before, you might have used Django's default User model. For quick prototypes, that works fine. But for any project you plan to grow or maintain, starting with a custom user model is a best practice you should never skip.

Here's why: Django's default User model uses a username field as the primary identifier. If you later decide you want users to log in with their email address instead, or you need to add a profile picture field, or a phone number, then you're stuck.

Using a custom user model gives you full control over what a "user" means in your app. Instead of being tied to a username, you can design login around something more practical, like email or phone_number for a fitness or mobile-based app. You can also include fields like role (doctor, patient, receptionist in a clinic system) or date of birth directly in the user model, instead of managing a separate profile.

It also helps future-proof your project. If you start with the default model and later decide to switch login from username to email, or add required fields, it becomes difficult and risky to change. Using a custom user model from the beginning avoids this problem and makes it much easier to adapt your authentication system as your app grows.

By creating a custom user model from the start, even if it's identical to the default one, you give yourself the freedom to make changes later without any of that pain.

2.1 How to Define the Custom User Model

Open notes/models/py and add the following code:

from django.contrib.auth.models import AbstractUser
from django.db import models

class CustomUser(AbstractUser):
    pass

You are importing Django’s built-in AbstractUser class.

Think of AbstractUser as a ready-made blueprint for a user. It already includes fields like username, password, email, first name, last name , and authentication logic.

The pass statement means you're not adding any extra fields yet.

But the key point is that this model is yours. So this model behaves exactly like Django’s default user model, but with one big advantage: you now have the flexibility to customize it later.

If three months from now you need to add a phone_number field or switch to email-based login, you just add a field to this class and run a migration.

from django.contrib.auth.models import AbstractUser
from django.db import models

class CustomUser(AbstractUser):
    phone_number = models.CharField(max_length=15)

You can also see all the fields that the CustomUser class has inherited from the AbstractUser class.

To do this we can use the Python shell. Type the following command:

python manage.py shell

When you type this command, make sure that the virtual environment is active:

After this, import the CustomUser model in the shell:

from notes.models import CustomUser

After that, type the following code:

[fields.name for field in CustomUser._meta.get_fields()]

The above statement lists out all the fields in the CustomUser class.

2.2 How to Tell Django to Use Your Custom User Model

Now comes the important bit. Open notes_core/settings.py and add this line:

AUTH_USER_MODEL = 'notes.CustomUser'

This setting tells Django to use your CustomUser model instead of the built-in one for everything authentication-related such as login, permissions, foreign keys, and so on.

There's no strict rule to where you need to add it, but the best practice is to add it near the end of the file.

You can see which user model Django is using by using the method get_user_model().

Open the Python shell again and import the get_user_model() method:

from django.contrib.auth import get_user_model

Then use get_user_model() and print the output:

user = get_user_model()
print(user)

You should see the name of our model being used:

If you hadn't added the AUTH_USER_MODEL in the settings.py file, then Django would have used the default user model:

Note: You'll need to do this before you run your first migration. If you run migrate before setting AUTH_USER_MODEL, Django creates tables for the default User model, and switching afterward becomes a headache.

2.3 How to Run Migrations

Now create and apply the initial migrations:

python manage.py makemigrations
python manage.py migrate

Django will create the necessary tables for your custom user model along with all the built-in Django tables.

We can again peek under the hood to see the SQL queries that Django used to create the tables especially the CustomUser table.

Type this command:

python manage.py sqlmigrate notes 0001

Here notes is the name of the app and 0001 represents the migration number.

And you should get this output:

Let's also create a superuser so you can access the admin panel later for debugging:

python manage.py createsuperuser

Fill in the username, email (optional), and password when prompted.

Step 3: How to Define the Note Model

Now let's create the data model for the core of your application. First add a new import to use the settings object.

from django.conf import settings

Then add the following code below the CustomUser class:

class Notes(models.Model):
    owner = models.ForeignKey(
        settings.AUTH_USER_MODEL,
        on_delete=models.CASCADE,
        related_name='notes'
    )
    title = models.CharField(max_length=200)
    body = models.TextField()
    created_at = models.DateTimeField(auto_now_add=True)
    def __str__(self):
        return f"{self.title} (by {self.owner.username})"

Here's the complete model.py code:

from django.contrib.auth.models import AbstractUser
from django.db import models
from django.conf import settings

class CustomUser(AbstractUser):
    pass

class Notes(models.Model):
    owner = models.ForeignKey(
        settings.AUTH_USER_MODEL,
        on_delete=models.CASCADE,
        related_name='notes'
    )
    title = models.CharField(max_length=200)
    body = models.TextField()
    created_at = models.DateTimeField(auto_now_add=True)
    def __str__(self):
        return f"{self.title} (by {self.owner.username})"

Let's walk through each field:

owner = models.ForeignKey(settings.AUTH_USER_MODEL, ...): Creates a relationship between each note and a user. The ForeignKey field tells Django that each note belogs to exactly one user but a user can have many notes.

Notice that we use settings.AUTH_USER_MODEL instead of directly importing CustomUser. This is the recommended practice because it keeps your code flexible. If you ever change the user model reference in settings, this foreign key adapts automatically.

The on_delete=models.CASCADE means that if a user is deleted, all their notes are deleted too.

The related_name='notes' lets you access a user's notes with user.notes.all().
title = models.CharField(max_length=200): Creates a text field for the task name, limited to 200 characters.
body = models.TextField(): Holds the actual note content. TextField has no character limit, so users can write as much as they need.
created_at = models.DateTimeField(auto_now_add=True): Automatically records the date and time when a task is created. You never need to set this manually.

The __str__() method gives each note a readable representation. Instead of seeing "Note object (1)" in the admin panel or during debugging, you'll see something like "Meeting Notes (by Solina)."

3.2 How to Apply Migration

Run the migration commands to create the Note table:

python manage.py makemigrations
python manage.py migrate

As before, we can see the exact SQL query Django used to create the notes table:

3.3 How to Register Models in the Admin

Open notes/admin.py and register both models so you can inspect data through the admin panel:

from django.contrib import admin
from .models import CustomUser, Notes

admin.site.register(CustomUser)
admin.site.register(Notes)

This is helpful during development when you want to quickly check whether data is being saved correctly.

Step 4: How to Create the Serializer

In DRF, a serializer is like a bridge between your database and the internet.

Django models store data as Python objects. But when you want to send that data to a frontend application (like React or a mobile app), you can't send Python objects. You need to send a format that everyone understands which is usually JSON.

Serializers perform three main jobs:

Serialization: Converting complex Python objects (Models) into Python dictionaries (which can be easily rendered into JSON).
Deserialization: Converting JSON data coming from a user back into complex Python objects.
Validation: Checking if the incoming data is correct before saving it to the database.

4.1 How to Create UserSerializer

Create a new file called notes/serializers.py and add the following code:

from rest_framework import serializers
from django.contrib.auth import get_user_model

User = get_user_model()
class UserSerializer(serializers.ModelSerializer):
    password = serializers.CharField(write_only=True)

    class Meta:
        model = User
        fields = ['id', 'username', 'email', 'password']

    def create(self, validated_data):
        user = User.objects.create_user(
            username=validated_data['username'],
            email=validated_data.get('email', ''),
            password=validated_data['password']
        )
        return user

Let's break down this serializer.

The UserSerializer handles user registration.
User = get_user_model() gets the user model that you're using and stores in the variable User. In our case, we're using the CustomUser model
class UserSerializer(serializers.ModelSerializer):: Here you've created the UserSerializer class, which inherits ModelSerializer.

A ModelSerializer is a shortcut that automatically creates a serializers class with fields that are in the model class.

When we use a ModelSerializer, DRF inspects the model and automatically does these things:

1. Generates fields from the model so you don't have to
2. Automatically adds field validations that are present in the model
3. Implements create() and update() methods. A ModelSerializer knows which model to use and how to update and create it. You can override create() and update() methods if you need customized behaviors. You have overridden the create() method in the above code.
password = serializers.CharField(write_only=True): This line is crucial. The write_only=True flag means the password will be accepted during registration but will never appear in any API response. Without this, your API would send back the password (even if hashed) every time user data is returned.

So users can create accounts, but their passwords are never exposed back.
class Meta: Inside the Meta class, you tell the serializer which model to use. In this case, the model to use is User and the fields to be handled.
The create() method: This is the most important part. This method runs when we create a new user. Instead of using the default .create() method you have overridden it.

It's important to understand why we have overridden this method. The default create() method is not suitable for creating users securely.

By default this method stores the password in plain text format. This is a serious problem because passwords should never be stored in raw form. They need to be hashed so that even if the database is compromised, the passwords are never exposed.

Django provides a special method called create_user() that automatically handles this by hashing the password and setting up the user properly for authentication.

4.2 How to Create NoteSerializer

After the UserSerializer class, let's create the NoteSerializer class. The NoteSerializer handles the notes data

First of all, you need to add an import to the Notes class. Add the line from .models import Notes at the end of the last import.

Put this code below the UserSerializer class:

class NoteSerializer(serializers.ModelSerializer):
    owner = serializers.ReadOnlyField(source='owner.username')
    class Meta:
        model = Notes
        fields = ['id', 'owner', 'title', 'body', 'created_at']

Now let's break it down:

owner = serializers.ReadOnlyField(source='owner.username'): This is the most important line in the code. This makes the owner field read-only. That means the API will display who owns a note (showing their username), but no one can set or change the owner through the API.

Without this protection, a malicious user could send a POST request with "owner": 5 and assign their note to someone else's account, or worse, modify someone else's notes by reassigning ownership.

The source='owner.username' part tells DRF to display the owner's username instead of their numeric ID, which makes the API responses more readable.
class Meta: ...: As before the Meta class contains the model which the serializer use and the fields that the API will expose.

Here is the complete code in the serializers.py file

from rest_framework import serializers
from django.contrib.auth import get_user_model
from .models import Notes

User = get_user_model()
class UserSerializer(serializers.ModelSerializer):
    password = serializers.CharField(write_only=True)
    class Meta:
        model = User
        fields = ['id', 'username', 'email', 'password']

    def create(self, validated_data):
        user = User.objects.create_user(
            username=validated_data['username'],
            email=validated_data.get('email', ''),
            password=validated_data['password']
        )
        return user

class NoteSerializer(serializers.ModelSerializer):
    owner = serializers.ReadOnlyField(source='owner.username')
    class Meta:
        model = Notes
        fields = ['id', 'owner', 'title', 'body', 'created_at']

Step 5: How to Configure SimpleJWT

Now let's set up the authentication system. This is where you tell DRF to use JWT for authentication instead of sessions. This step is crucial because without it, DRF will default to session-based auth.

SimpleJWT provides a complete JWT implementation for DRF, so you don't have to build token generation, signing, or verification from scratch.

The access token is what your client sends with every API request. It's short-lived by design. Think of it like a visitor badge at an office building: it gets you through the door, but it expires at the end of the day. If someone steals it, the damage is limited because it stops working soon.

The refresh token is longer-lived and has a single purpose: getting a new access token when the current one expires. The client stores it securely and only sends it to one specific endpoint. Think of it like your employee ID card. You use it to get a new visitor badge each morning, but you don't flash it at every door.

This separation exists for security. If the short-lived access token is compromised (which is more likely since it's sent with every request), the attacker has a narrow window before it expires. The refresh token, which is sent less frequently, has a lower risk of interception.

Let's look at how the access and refresh token work together

User logs in, server gives both access token and refresh token
User makes requests using the access token
Access token expires
App sends refresh token to server
Server checks it and gives a new access token
User continues without logging in again

5.1 How to Update REST Framework Settings

Open notes_core/settings.py and add the following code:

from datetime import timedelta
REST_FRAMEWORK = {
    'DEFAULT_AUTHENTICATION_CLASSES': (
        'rest_framework_simplejwt.authentication.JWTAuthentication',
    ),

    'DEFAULT_PERMISSION_CLASSES': (
        'rest_framework.permissions.IsAuthenticated',
    ),
}

SIMPLE_JWT = {
    'ACCESS_TOKEN_LIFETIME': timedelta(minutes=30),
    'REFRESH_TOKEN_LIFETIME': timedelta(days=1),
}

Let's unpack what each section does.

The DEFAULT_AUTHENTICATION_CLASSES setting tells DRF to use JWT as the authentication method for all API endpoints. Every incoming request will be checked for a valid JWT token in the Authorization header.

The DEFAULT_PERMISSION_CLASSES setting sets IsAuthenticated as the global permission policy. This means every endpoint in your API is locked down by default. Only users with a valid token can access any endpoint.

This is a secure-by-default approach: instead of remembering to protect each view individually, everything is protected, and you explicitly open up the endpoints that need to be public (like the registration endpoint, which you'll handle in the next step).

The SIMPLE_JWT dictionary controls token behavior. The access token lasts 30 minutes. This is the token clients include in every request. If someone intercepts it, the damage is limited to a 30-minute window. The refresh token lasts one day.

When the access token expires, the client can use the refresh token to get a new access token without forcing the user to log in again. The duration of the refresh token is 1 day. This means after 1 day, the user must log in again with their username and password. You'll see exactly how this works later when you test with Postman.

5.2 How to Add Token URL Endpoints

SimpleJWT provides ready-made views for obtaining and refreshing tokens. You just need to wire them up to URLs.

Open notes_core/urls.py and update it with the following code:

from django.contrib import admin
from django.urls import path, include
from rest_framework_simplejwt.views import (
    TokenObtainPairView,
    TokenRefreshView,
)

urlpatterns = [
    path('admin/', admin.site.urls),
    path('api/', include('notes.urls')),
    path('api/token/', TokenObtainPairView.as_view(), name='token_obtain_pair'),
    path('api/token/refresh/', TokenRefreshView.as_view(), name='token_refresh'),
]

The token/ endpoint accepts a username and password, and returns an access token and a refresh token.

The token/refresh/ endpoint accepts a refresh token and returns a new access token. You'll see these in action during testing.

Step 6: How to Build the Authentication Logic

Open notes/views.py and add the following:

from rest_framework import generics, permissions
from django.contrib.auth import get_user_model
from .serializers import UserSerializer

User = get_user_model()

class RegisterView(generics.CreateAPIView):
    queryset = User.objects.all()
    serializer_class = UserSerializer
    permission_classes = [permissions.AllowAny]

Now let's walk through this code.

The first section are the imports and after that we have used the the get_user_model() method to get the CustomUser model.

Now the main part is RegisterView class. The class inherits from generics.CreateAPIView which is a built in DRF view designed specifically for handling POST requests that create new objects.

Because of this, you don’t have to manually write the logic for handling POST requests, validating data, or saving to the database. DRF does all of that for you behind the scenes.

Inside the class, queryset = Users.objects.all() defines the set of user objects this view can work with.

The serializer_class = UserSerializer tells the view which serializer to use for validating incoming data and creating the user.

Finally permission_classes = [permissions.AllowAny] overrides the global IsAuthenticated permission you set earlier in the value of DEFAULT_PERMISSION_CLASSES .

This means that anyone can access the registration endpoint, even if they aren't logged in. This makes sense for a registration endpoint because new users won’t have accounts yet.

Every other view in your API will inherit the global IsAuthenticated permission, so only this registration endpoint is open.

Step 7: How to Implement Scoped Views

This is the heart of the tutorial. You've set up authentication so the API knows who is making a request. Now you need to make sure each user can only interact with their own notes.

Think of it this way: authentication is the lock on the front door of an apartment building. It keeps strangers out. But scoping is the lock on each individual apartment. Just because you live in the building doesn't mean you can walk into your neighbor's apartment.

Without scoping, an authenticated user could potentially see every note in the database, or worse, modify notes that belong to someone else. Two method overrides on your viewset prevent this entirely.

7.1 How to Create a NoteViewSet

Now let's create the NoteViewSet. First add these imports to the top of the file. We're importing the viewsets, serializers, and model.

from .models import Note
from .serializers import UserSerializer, NoteSerializer
from rest_framework import generics, viewsets, permissions

Add the following to notes/views.py, below the RegisterView:

class NoteViewSet(viewsets.ModelViewSet):
    serializer_class = NoteSerializer

    def get_queryset(self):
        return Notes.objects.filter(owner=self.request.user).order_by('-created_at')

    def perform_create(self, serializer):
        serializer.save(owner=self.request.user)

Now let's talk about this code in detail.

You've created a new class called NoteViewSet which inherits from the DRF class ModelViewSet. This gives you full CRUD operations, meaning you can list notes and retrieve a single note, as well as create, update, and delete a note.

The next part serializer_class = NoteSerializer tells Django to use the NoteSerializer class to convert between Python objects and JSON.

But the magic is the two methods that you are overriding: get_queryset() and perform_create().

The get_queryset() method controls which notes the API returns. If you didn't override this method, it would return Note.objects.all() (which would give every user access to every note in the database).

But here, you've overridden this method so that it filters notes by the current user.

Next is the perform_create() method, which is called when the note is saved. You've overridden this method so that it saves the notes of the user who's currently logged in. If you hadn't overridden the this method, it would return all the notes regardless of the logged in user.

Notice that you have passed self.request.user parameters in to the filter() function. This is the code that attaches the logged-in user as the owner of the note.

Remember how you made the owner field read-only in the serializer? This is the other half of that security measure.

The user can't set the owner through the API request, and the server automatically sets it to whoever is authenticated. These two pieces work together to make ownership tamper-proof.

7.2 Why This Matters: Preventing ID Enumeration Attacks

Without get_queryset filtering, your API might allow something like this: a user sends a GET request to /api/notes/42/ and sees a note that belongs to someone else, simply because they guessed the ID.

This is called an ID enumeration attack — an attacker cycles through IDs (1, 2, 3, 4...) to discover and access other people's data.

With your scoped get_queryset, even if User B sends a request to /api/notes/42/ and note 42 belongs to User A, the viewset won't find it in User B's filtered queryset. DRF will return a 404 — as far as User B is concerned, that note doesn't exist.

Step 8: How to Connect a URL

Now you need to wire up the views to URL paths so the API knows which view to call for each endpoint.

8.1 How to Create App-level URLs

Create a new file called notes/urls.py and add the following:

from django.urls import path, include
from rest_framework.routers import DefaultRouter
from .views import RegisterView, NoteViewSet

router = DefaultRouter()
router.register(r'notes', NoteViewSet, basename='note')

urlpatterns = [
    path('register/', RegisterView.as_view(), name='register'),
    path('', include(router.urls)),
]

The DefaultRouter automatically generates URL patterns for the NoteViewSet. Since you're using a ModelViewSet, the router creates endpoints for listing all notes, creating a note, retrieving a single note, updating a note, and deleting a note — all from that single router.register call.

The basename='note' parameter is required here because your viewset doesn't have a queryset attribute defined directly on the class (you're using get_queryset instead). DRF uses the basename to generate the URL pattern names like note-list and note-detail.

8.2 How to Verify the Project-Level URLs

Make sure your notes_core/urls.py looks like this (you set this up in Step 5, but let's confirm):

from django.contrib import admin
from django.urls import path, include
from rest_framework_simplejwt.views import (
    TokenObtainPairView,
    TokenRefreshView,
)

urlpatterns = [
    path('admin/', admin.site.urls),
    path('api/', include('notes.urls')),
    path('api/token/', TokenObtainPairView.as_view(), name='token_obtain_pair'),
    path('api/token/refresh/', TokenRefreshView.as_view(), name='token_refresh'),
]

Here's the full picture of your API's URL structure:

Endpoint	Method	Description
`api/register/`	POST	Create a new user account
`api/token/`	POST	Get access and refresh tokens
`api/token/refresh/`	POST	Get a new access token using a refresh token
`api/notes/`	GET	List all notes for the authenticated user
`api/notes/`	POST	Create a new note
`api/notes//`	GET	Retrieve a specific note
`api/notes//`	PUT/PATCH	Update a specific note
`api/notes//`	DELETE	Delete a specific note

Start the development server to make sure everything runs without errors:

python manage.py runserver

If the server starts without complaints, your code is wired up correctly.

Step 9: How to Test the APIs with Postman

Building the API is one thing. Proving it works is another. Let's walk through the entire flow using Postman, from registering a user to demonstrating that scoping actually works.

If you haven't used Postman before, it's a tool that lets you send HTTP requests to your API and inspect the responses. You can download it from postman.com/downloads.

Alternatively, you can use curl from the command line or any other API testing tool you're comfortable with.

Make sure your development server is running before proceeding.

9.1 How to Register a User

Open Postman:

Create a new request:

Method	POST
URL	`http://127.0.0.1:8000/api/register/`
Body tab	Select "raw" and choose "JSON" from the dropdown
Body Content	{ "username": "priya", "email": "priya@example.com", "password": "securepassword123" }

Click Send. You should get a 201 Created response with the user data (without the password, thanks to your write_only=True field) which you wrote in the UserSerializer class.

9.2 How to Obtain Access and Refresh Tokens

Now log in to get your JWTs:

Method	POST
URL	`http://127.0.0.1:8000/api/token/`
Body	{"username" : "priya", "password" : "securepassword123"}

You'll get a response with access and refresh tokens.

Copy the access token. You'll need it for every subsequent request. Also save the refresh token, as you'll use it later.

A JWT is only encoded and not encrypted. The encoding is merely a way to transform the data into a safe, standard string format that can be easily transmitted over the internet.

Any one can peel through the encoding to see the data. This is done using base64url encoding.

We can use the Python library pyjwt to decode JWTs or use any of the online sites to decode. It's important to note that you should use online sites with caution since JWTs may contain sensitive information.

For this demo, we'll use site called jwt.io.

Open the site and paste in the access token that you have just created:

The JWT has three parts: the header, the payload, and the signature.

The header sections tells you how the header is signed. In this case it is signed using the HS256 algorithm.

The payload is where the actual data or claim lives. It contains standard claims such as token types, expiration time ( exp ), issued at time ( iat ), and custom claims.

The signature section is used to verify integrity. You can't decode it to meaningful data. This section ensures that the token wasn't tampered with.

9.3 How to Create a Note

Now use the access token to create a note:

Method	POST
URL	`http://127.0.0.1:8000/api/notes/`
Header tab:	Add a new header:
Key: Authorization, Value: Bearer
Body	{'title': 'My note', 'body': 'This contains secret information'}

Notice that you don't include an owner field. That's handled automatically by perform_create. You should get a 201 Created response:

You can create a few more notes, so that we have some data to work with.

9.4 How to List Your Notes

Now to fetch all of Priya's notes:

Method	GET
URL	`http://127.0.0.1:8000/api/notes/`
Header tab:	Same Authorization: Bearer header

You should see all the notes created, sorted by most recent first.

9.5 How to Demonstrate Scoping

Let's prove that a second user can't view the first user's notes.

First, register the second user.

Send a POST request to http://127.0.0.1/api/register with the following data:

Method	POST
URL	`http://127.0.0.1:8000/api/register/`
Body tab	Select "raw" and choose "JSON" from the dropdown
Body Content	{ "username": "sujan", "email": "sujan@example.com", "password": "anotherpassword123" }

Then get tokens for Sujan by sending a POST request to http://127.0.0.1:8000/api/token/ with Sujan's credentials (username and password) and then copy Sujan's access token.

Now send a GET request to http://127.0.0.1:8000/api/notes/ using Sujan's token in the Authorization header.

The response should be an empty list since this user hasn't created any notes:

More importantly, Priya's notes are completely invisible to him. Even if Sujan tries to access a specific note by ID – say, http://127.0.0.1:8000/api/notes/1/ – he'll get a 404 Not Found response, not a 403 Forbidden.

This is intentional. A 404 Not Found doesn't reveal that the note exists, while a 403 Forbidden would confirm its existence to a potential attacker.

A 403 Forbidden response is like a door with a sign: “Authorized personnel only”. You now know something important is inside. A 404 Not Found response is like a blank wall. You don’t even know a room exists.

Now that you know why we've used the 404 response instead of 403, let's demonstrate this.

First, I'll access Priya's individual note using her credentials and her access token:

Now, I'll change the access token and put Sujan's (new user) access token:

You can see that using the new user's token to access the previous user's note leads to 404 Not Found response.

Step 10: How to Handle Token Expiration with Refresh Tokens

Access tokens are deliberately short-lived (30 minutes in your configuration). This limits the window of damage if a token is stolen.

But you don't want users to re-enter their credentials every 30 minutes. That's what refresh tokens are for.

When Priya's access token expires, her API requests will start returning 401 Unauthorized responses. Instead of logging in again, the client sends the refresh token to get a fresh access token.

Method	POST
URL	`http://127.0.0.1:8000/api/token/refresh/`
Body tab	Select "raw" and choose "JSON" from the dropdown
Body Content	{ refresh: < Priya's refresh token >}

Replace your old access token with this new one, and you're good for another 30 minutes. The refresh token itself lasts for one day, so the user only needs to fully log in again once every 24 hours.

In a real application, the frontend client handles this automatically. When an API call returns a 401, the client catches it, sends the refresh token to get a new access token, and retries the original request — all without the user noticing.

Here's what that flow looks like in pseudocode:

Client sends request with access token
Server responds with 401 (token expired)
Client sends refresh token to /api/token/refresh/
Server responds with a new access token
Client retries the original request with the new access token
Server responds with the data

If the refresh token itself has expired (after 24 hours in your configuration), step 4 will also return a 401. At that point, the user truly needs to log in again with their username and password. This is the intended behavior: it means even a stolen refresh token has a limited useful life.

How You Can Improve This Project

This API is functional and secure, but there's plenty of room to build on it. Here are some directions you could take.

Add search and filtering. Let users search their notes by title or body text. You can use DRF's SearchFilter and django-filter to add query parameters like ?search=meeting to the notes list endpoint.
Add categories or tags. Create a Category model and add a foreign key to Note, or use a many-to-many relationship for tags. This would let users organize their notes and filter by category.
Add pagination. Once a user has hundreds of notes, returning them all in a single response becomes slow. DRF has built-in pagination classes that let you return notes in pages of 10, 20, or whatever size you choose.
Deploy to a production server. The API currently runs on your local machine. You could deploy it to platforms like PythonAnywhere, Railway, or Render to make it accessible from anywhere. You'd need to configure a production database (like PostgreSQL), set a secure SECRET_KEY, and serve the application behind HTTPS.
Build a frontend. Connect a React, Next.js, or Vue.js frontend to this API. Store the JWTs in the client and implement the token refresh flow so users stay logged in seamlessly.
Add token blacklisting. SimpleJWT supports token blacklisting, which lets you invalidate refresh tokens when a user logs out. Without this, a refresh token remains valid until it expires, even after the user "logs out."

Each of these improvements builds on the patterns you've already learned and will deepen your understanding of Django, DRF, and API design.

Conclusion

You've built a fully functional, secure note-taking API with Django, Django REST Framework, and SimpleJWT. Along the way, you learned some fundamental concepts that apply to any API you'll build in the future.

You started with a custom user model — a small decision at the beginning that saves you from a painful migration later. You configured JWT authentication so your API can serve mobile clients and decoupled frontends that can't rely on session cookies.

You built serializers that protect sensitive data by keeping passwords write-only and ownership read-only. Most importantly, you implemented scoped views that ensure each user's data is completely isolated from everyone else's.

The patterns you practiced here — overriding get_queryset to filter by the current user, overriding perform_create to assign ownership automatically, and using read-only fields to prevent data tampering — are the same patterns you'll use in production APIs handling real user data.

The best way to solidify what you've learned is to keep building. Try adding search and filtering, build a React frontend that consumes this API, or start a completely new project may be a task manager, a journal app, or a bookmarks API using the same JWT and scoping patterns. The core workflow stays the same. Only the models and business logic change.

How to Build and Deploy a Fitness Tracker Using Python Django and PythonAnywhere - A Beginner Friendly Guide

Prabodh Tuladhar — Fri, 03 Apr 2026 17:57:00 +0000

If you've learned some Python basics but still feel stuck when it comes to building something real, you're not alone. Many beginners go through tutorials, learn about variables, functions, and loops, and then hit a wall when they try to create an actual project.

The gap between "I know Python syntax" and "I can build a working web app" can feel enormous. But it does not have to be.

In this tutorial, you'll build a fitness tracker web application from scratch using Django, one of the most popular Python web frameworks. By the end, you'll have a fully functional app running live on the internet – something you can show to friends, add to your portfolio, or keep building on.

Here's what you'll learn:

How Django projects and apps are structured
How to define database models to store workout data
How to create views that handle user requests
How to build HTML templates that display your data
How to connect URLs to views so users can navigate your app
How to deploy your finished app to PythonAnywhere so anyone can access it

The app itself is straightforward: you can log a workout by entering an activity name, duration, and date. You can then view all your logged workouts on a separate page. It's simple, but it covers the core Django concepts you need to build much bigger things later.

Let's get started.

Prerequisites
What You Are Going Build
Step 1: How to Set Up Your Django Project
Step 2: How to Create a Django App
- 2.1 How to Generate the App
- 2.2 How to Register the App
Step 3: How to create a Workout Model
- 3.1 How to Define the Model
Step 4: How to Apply Migrations
- 4.1 How to Generate the Migration
- 4.2 How to Apply the Migration
Step 5: How to Register the Model in the Admin Panel
- 5.2 How to Create a Superuser
- 5.3 How to Access the Admin Panel
Step 6: How to Create Views for the App
- 6.1 How to Create a Form Class
- 6.2 How to Write Views
Step 7: How to Create Templates
Step 8: How to Connect URLs
- 8.1 How to Create App Level URLs
- 8.2 How to Link App URLs to project
Step 9: How to Test the Application Locally
Step 10: How to Prepare for Deployment
- 10.1 How to Update Settings for Production
Step 11: How to Deploy Your Django App on PythonAnywhere
Common Mistakes and How to Fix Them
How You Can Improve This Project
Conclusion

Prerequisites

Before you begin, make sure you are comfortable with the following:

Python fundamentals: You should understand variables, functions, lists, dictionaries, and basic control flow (if/else statements and loops).

Basic command line usage: You'll be running commands in your terminal throughout this tutorial. You should know how to open a terminal, navigate between folders, and run commands. If you're on Windows, you can use Command Prompt or PowerShell. On macOS or Linux, the default Terminal app works well.

Tools you'll need installed:

Python 3.8 or higher. You can check your version by running python --version or python3 --version in your terminal. If you don't have Python installed, download it from python.org
pip. This is Python's package manager. It usually comes bundled with Python. You can verify by running pip --version or pip3 --version. Note the commands python3 and pip3 tell the terminal that you are explicitly using Python Version 3
A code editor. Visual Studio Code is a great free option, but you can use any editor you're comfortable with.

That's everything. You don't need prior Django experience or web development knowledge. This tutorial will walk you through each step.

What You Are Going Build

The fitness tracker you will build has two main features:

A form to log workouts. You will enter the name of an activity (like "Running" or "Push-ups"), how long you did it (in minutes), and the date. When you submit the form, Django saves that workout to a database.

A page to view all your workouts. This page displays every workout you have logged, showing the activity, duration, and date in a clean list.

Here's how data flows through the app at a high level:

You fill out the workout form in your browser and click submit.
Your browser sends that data to Django.
Django's view function receives the data, validates it, and saves it to the database.
When you visit the workouts page, Django's view function pulls all saved workouts from the database.
Django passes that data to an HTML template, which renders it as a page your browser can display.

This request-response cycle is the foundation of how Django works. Once you understand it, you can build almost anything.

Step 1: How to Set Up Your Django Project

Every Django project starts with a few setup steps. You'll create an isolated Python environment, install Django, and generate the initial project structure.

1. 1 How to Create a Virtual Environment

A virtual environment is a self-contained folder that contains its own Python interpreter and installed packages for a specific project. This keeps your project's dependencies separate from other Python projects on your computer. This separation prevents version conflicts and keeps setups consistent.

For example, one project might require an older version of Django, while another needs the latest version, and a virtual environment allows both to work smoothly on the same system.

Without it, global installations can clash, break projects, and make setups hard to reproduce. Over time, the system environment becomes cluttered with unused or incompatible packages making debugging and maintenance more difficult.

Now let's set it up.

Open your terminal, and navigate to where you want your project to live and run the following command

mkdir fitness-tracker
cd fitness-tracker

The first command creates a new folder called fitness-tracker. The second command moves you into that folder.

You'll create the Python virutal environment here.

python3 -m venv venv

By using the ls command, you can see that we've created the virtual environment folder.

To activate the virtual environment, we need to use the following command:

On macOS/Linux:

source venv/bin/activate

On Windows:

venv\Scripts\activate

You'll know it worked when you see (venv) at the beginning of your terminal prompt. From this point on, any Python packages you install will only exist inside this virtual environment.

1.2 How to Install Django

With your virtual environment activated, install Django using pip:

pip install django

This downloads and installs the latest stable version of Django. You can verify the installation by running:

python3 -m django --version

After running both these commands, you should see Django being installed and the version number:

1.3 How to Create the Project

We have finished installing Django. Now let's create a Django project. Django provides a command line utility that generates the boilerplate files that you need. Type the following command:

django-admin startproject fitness_project .

The command creates a folder named fitness-project. Notice the dot at the end of the command. The dot at the end is important. It tells Django to create the project files in your current directory instead of creating an extra nested folder.

Now that we've created our Django project, let's open the project in your favourite text editor and look at folder structure.

You'll notice that the folder already comes with a bunch of files.

1.4 How to Run the Development Server

Now let's make sure everything is working. You'll need to run a server for this. Type the following command:

python manage.py runserver

You can type this command in the terminal with the virtual environment activated or you can use the integrated terminal if you're using VS Code. I'll be using the integrated terminal from this point on.

Open your browser and go to http://127.0.0.1:8000/. You should see Django's default welcome page with a rocket ship graphic confirming that your project is set up correctly.

Press Ctrl + C in your terminal to stop the server when you're ready to move on.

Step 2: How to Create a Django App

In Django, a project is the overall container for your entire web application, while an app is a smaller, self-contained module inside that project that focuses on a specific piece of functionality.

A useful way to picture this is to think of a house. The project is the whole house. Each app is like a room inside that house. One room might be a kitchen, another a bedroom, each designed with a clear purpose. In the same way, a Django app is built to handle one responsibility, such as authentication, payments, or in this case, workout tracking.

Now, here's the important part: why not just put everything into one big project instead of using apps? You technically could, especially for very small projects. But as your application grows, that approach quickly becomes difficult to manage.

By using apps, you naturally separate concerns. It also makes collaboration smoother, since different people can work on different apps without constantly stepping on each other’s code.

Another major benefit is reusability. Since apps are modular, you can take an app from one project and reuse it in another.

For example, if you build a workout tracking app once, you could plug it into a completely different Django project later without rebuilding it from scratch. Later, you might create a completely different project, say a fitness coaching platform or a health dashboard. Instead of rebuilding the tracking feature from scratch, you can reuse the same app.

For this project, you'll create a single app called tracker that handles everything related to logging and displaying workouts.

2.1 How to Generate the App

Make sure you're in the same directory as the manage.py file, then run the following code:

python manage.py startapp tracker

This create a new folder called tracker with the following following structure:

Each file has its own purpose. You'll work with models.py, views.py and admin.py throughout this project.

2.2 How to Register the App

Django doesn't automatically know about your new app. You need to tell it by adding the app to the INSTALLED_APPS list in settings.py file.

Open fitness_project/settings.py and find the INSTALLED_APPS list. Add the name of the app, that is tracker, to the end of the list:

You'll notice that a number of apps have already been installed automatically by Django. This is part of Django’s “batteries-included” philosophy, where many common features are ready to use out of the box.

Here is a short summary of what each of the apps does.

App Name	Purpose
django.contrib.admin	Powers the built-in admin dashboard, letting you manage your data through a web interface.
django.contrib.auth	Handles users, login systems, permissions, and password management.
django.contrib.contenttypes	Helps Django track and manage relationships between different models.
django.contrib.sessions	Stores user session data, so users stay logged in across requests.
django.contrib.messages	Lets you show temporary notifications like success or error messages.
django.contrib.staticfiles	Manages static assets such as CSS, JavaScript, and images

Now Django knows your tracker app exists and will include it when running the project.

Step 3: How to Create a Workout Model

A model in Django is a Python class that defines the structure of your data. Each model maps directly to a table in your database. Each attribute on the model becomes a column in that table.

Think of a model as a blueprint for a spreadsheet. The class name is the name of the spreadsheet, and each field is a column header. Every time you save a new workout, Django creates a new row in that spreadsheet.

3.1 How to Define the Model

Open tracker/models.py and replace its contents with this code:

from django.db import models

class Workout(models.Model):
    activity = models.CharField(max_length=200)
    duration = models.IntegerField(help_text="Duration in minutes")
    date = models.DateField()

    def __str__(self):
        return f"{self.activity} - {self.duration} min on {self.date}"

Let's discuss what each part does:

activity = models.CharField(max_length=200) creates a text fields that can hold up to 200 characters. This is where you'll store the name of the exercise like "Running" or "Cycling".
duration = models.IntegerField(help_text="Duration in minutes") creates a whole number field for storing how many minutes the workout lasted. The help_text parameter adds a hint that will appear in forms and the admin panel.
date = models.DateField() creates a date field for recording when the workout happened.

The __str__() method defines how a Workout object appears when printed or displayed in the admin panel. Instead of seeing something unhelpful like "Workout object (1)," you will see "Running - 30 min on 2025-03-15."

Step 4: How to Apply Migrations

You've defined your model, but Django hasn't created the actual database table yet. To do that, you need to run migrations.

Migrations are Django's way of translating your Python model definitions into database instructions. Migrations are done in two steps.

When you change a model – maybe by adding a field, removing a field, or renaming one – you create a new migration that describes that change. You can do this using the makemigrations command.

Then you apply the migration using the migrate command and Django updates the database to match.

This two-step process of first detecting the change and then applying the change gives you a reliable record of every change to your database structure over time.

4.1 How to Generate the Migration

Run the following command in the integrated terminal:

python manage.py makemigrations

You should see output like this:

Migrations for 'tracker': tracker/migrations/0001_initial.py 
    + Create model Workout

Django inspected your Workout model and created a migration file that describes how to build the corresponding database table. You can find this file at tracker/migrations/0001_initial.py if you want to look at it, but you don't need to edit it.

4.2 How to Apply the Migration

Now tell Django to execute that migration and actually create the table in the database:

python manage.py migrate

You'll see several lines of output as Django applies not just your migration, but also the default migrations for Django's built-in apps (authentication, sessions, and so on).

When it finishes, your database has a table ready to store workouts.

When the migrate command runs, we can see the exact SQL commands that Django used to build and change the database. Though this isn't required for creating the application, it's always good to know what's happening under hood.

Run this command:

python manage.py sqlmigrate tracker 001

And you should get this output:

The 001 you added at the end is the migration number and represents first version of the database schema.

In practice, your workflow usually looks like this: you change your models, run makemigrations to generate the migration files, and then run the migrate command to apply those changes to the database.

Step 5: How to Register the Model in the Admin Panel

Django comes with a powerful admin interface built in. It gives you a graphical way to view, add, edit, and delete records in your database without writing any extra code. This is incredibly useful during development because you can quickly test your models and see your data.

But by default, it doesn’t know:

Which models you want to manage
How you want them displayed

So you register models in admin.py to tell Django to include the specific model in the admin interface.

5.1 How to Add Model to Admin

Open tracker/admin.py and add the following code:

from django.contrib import admin
from .models import Workout

admin.site.register(Workout)

This single line tells Django to include the Workout model in the admin interface.

5.2 How to Create a Superuser

To access the admin panel, you need an admin account. Create one by running:

python manage.py createsuperuser

Django will prompt you for a username, email address, and password. Choose something you will remember. The email is optional – you can press Enter to skip it.

5.3 How to Access the Admin Panel

Start the development server:

python manage.py runserver

Then navigate to http://127.0.0.1:8000/admin/ in your browser. Log in with the credentials you just created.

You should see the Django administration dashboard with a "Tracker" section containing your "Workouts" model.

Try clicking "Add" to create a couple of test workouts. This will confirm that your model is working correctly before you build the rest of the app.

Step 6: How to Create Views for the App

A view in Django is a Python function (or class) that receives a web request and returns a web response. That response could be an HTML page, a redirect, a 404 error, or anything else a browser can handle.

Views are where your application logic lives. They decide what data to fetch, what processing to do, and what to show the user.

For this app, you need two views: one to display the form where users add a workout, and one to display the list of all saved workouts.

6.1 How to Create a Form Class

Before writing the views, you need a Django form that handles the workout input.

Django forms are a built-in way to handle user input like login forms, contact forms, or anything that collects data from a user. Instead of manually writing HTML, validating inputs, and handling errors, Django gives you a structured way to do all of that in one place.

Most user inputs are based on the models you’ve created, and Django can automatically generate forms from those models using ModelForms, which speeds things up significantly.

Let's create a new file called forms.py in the tracker folder and add the following code:

from django import forms
from .models import Workout

class WorkoutForm(forms.ModelForm):

    class Meta:
        model = Workout
        fields = ['activity', 'duration', 'date']
        widgets = {
            'date': forms.DateInput(attrs={'type': 'date'}),
        }

In the above code, the ModelForm automatically generates form fields based on the Workout model. The widgets dictionary tells Django to render the date field as an HTML date picker instead of a plain text input.

We can actually see the forms being automatically created by Django. For this we need to enter the shell. In the terminal, type the following command:

python manage.py shell

Now lets import the WorkoutForm class that we just created.

Type the following code:

from tracker.forms import WorkoutForm

Notice that we've given the name of the app as well when we imported the form.

Then create an object of the WorkoutForm class and print it.

from tracker.forms import WorkoutForm
workoutform = WorkoutForm()
print(workoutform)

You should get the following output:

You can see that all the model fields have been renderd as HTML forms and the date field has been created as a date type that is type="date" instead of plain text.

6.2 How to Write Views

As we've discussed above, our project has two views: one to add a workout and the other to display all the saved workouts.

First, let's create a view to add a workout. In the tracker/views.py file, type the following code:

from django.shortcuts import render, redirect
from .models import Workout

# view to list all workouts
def workout_list(request):
    workouts = Workout.objects.all().order_by('-date')
    return render(request, 'tracker/workout_list.html', {'workouts': workouts})

Let's walk through this view:

The workout_list view handles the page that displays all workouts.
It queries the database for every Workout object, orders them by date (most recent first, thanks to the - prefix), and passes that list to a template called workout_list.html.
The render function combines the template with the data and returns the finished HTML page.

To create the logic to add a workout, first add the Workout form import at the end of the import section. Then add the following code after the workout_list view:

from django.shortcuts import render, redirect
from .models import Workout
from .forms import WorkoutForm

# view to list all the workouts
def workout_list(request):
    workouts = Workout.objects.all().order_by('-date')
    return render(request, 'tracker/workout_list.html', {'workouts': workouts})

# view to add a workout
def add_workout(request):
    if request.method == 'POST':
        form = WorkoutForm(request.POST)
        if form.is_valid():
            form.save()
            return redirect('workout_list')
    else:
        form = WorkoutForm()
    return render(request, 'tracker/add_workout.html', {'form': form})

The add_workout view handles both displaying the empty form and processing submitted form data.
When a user first visits the page, the request method is GET, so Django creates a blank form and renders it.
When the user fills out the form and clicks submit, the request method is POST. Django then validates the submitted data, saves it to the database if everything is correct, and redirects the user to the workout list page.
If the data isn't valid, Django re-renders the form with error messages.

Here is the complete views code:

from django.shortcuts import render, redirect
from .models import Workout
from .forms import WorkoutForm

# view to list all workouts
def workout_list(request):
    workouts = Workout.objects.all().order_by('-date')
    return render(request, 'tracker/workout_list.html', {'workouts': workouts})

# view to add a workout
def add_workout(request):
    if request.method == 'POST':
        form = WorkoutForm(request.POST)
        if form.is_valid():
            form.save()
            return redirect('workout_list')
    else:
        form = WorkoutForm()
    return render(request, 'tracker/add_workout.html', {'form': form})

Step 7: How to Create Templates

Templates are HTML files that Django fills in with dynamic data. They're the front end of your application: the part users actually see in their browser.

7.1 How to Set Up the Template Directory

Django looks for templates inside a templates folder within each app. Create the following folder structure inside your tracker app.

tracker/templates/tracker

The double tracker folder name might look redundant, but it's a Django convention called template namespacing. It prevents naming conflicts if you have multiple apps with templates that share the same filename.

7.2 How to Create the Workout List Template

Create a file called tracker/templates/tracker/workout_list.html and add the following code:




    
    
    My Workouts
    



    
        My Workouts
        + Log a Workout
        {% if workouts %}
            {% for workout in workouts %}
                
                    
                        {{ workout.activity }}
                        {{ workout.duration }} minutes
                    
                    {{ workout.date }}
                
            {% endfor %}

        {% else %}
            
                No workouts logged yet. Start by adding one!
            
        {% endif %}

There are a few things worth noting here:

If you look closely at the HTML, you'll spot some weird-looking tags wrapped in curly braces ( {% %} and {{ }} ). Think of them as special instructions for Django.

You use the double curly braces ({{ }}) when you want to output or display a piece of data directly on the page.

On the other hand, you use the brace-and-percent-sign combo ( {% %} ) when you need Django to actually perform an action or apply logic, like running a loop or checking a condition.

They allow us to inject dynamic data straight from our Python backend right into our otherwise static HTML.

Lets look at this code snippet for the workout_list.html


    
        My Workouts
        + Log a Workout
        {% if workouts %}
            {% for workout in workouts %}
                
                    
                        {{ workout.activity }}
                        {{ workout.duration }} minutes
                    
                    {{ workout.date }}
                
            {% endfor %}

        {% else %}
            
                No workouts logged yet. Start by adding one!
            
        {% endif %}

There are a few things worth noting here.

Right under the main heading, you'll see this line:

Instead of hardcoding a web link like href="/add-workout/", Django uses the {% url %} tag to generate the link dynamically. You pass it the name of the route (in this case, add_workout), and Django automatically figures out the correct URL path.

If you ever change the URL structure in your Python code later, Django updates this link automatically. You never have to hunt through HTML files to fix broken links!

The {% if workouts %} block checks whether there are any workouts to display. If the list is empty, it shows a friendly message instead of a blank page.

The {% for workout in workouts %} loop iterates over every workout in the list and renders a card for each one. The double curly braces {{ workout.activity }} insert the value of each field into the HTML

Inside the loop, you'll notice tags that look like this:

{{ workout.activity }}
{{ workout.duration }}
{{ workout.date }}

As Django loops through each workout object, it uses dot notation to peek inside that specific object and grab its details. It grabs the activity type (like "Running"), the duration ("30"), and the date ("March 30"), and prints that exact text directly onto the webpage for the user to see.

7.3 How to Create Add Workout Template

Create a file called tracker/templates/tracker/add_workout.html and add the following code:




    
    
    Log a Workout
    


    
       Log a Workout
        
            {% csrf_token %}
            
                Activity
                {{ form.activity }}
                {% if form.activity.errors %}
                    {{ form.activity.errors }}
                {% endif %}
            
            
                Duration (minutes)
                {{ form.duration }}
                {% if form.duration.errors %}
                    {{ form.duration.errors }}
                {% endif %}
            

            
                Date
                {{ form.date }}
                {% if form.date.errors %}
                    {{ form.date.errors }}
                {% endif %}
            

            
                
                Cancel

In the previous template, we learned how to display data. Now, we're looking at a form that actually collects data. Handling forms manually in web development can get messy, but Django provides some powerful template tags to do the heavy lifting for us.

Let's look at the Django-specific logic powering this form:

First, right after opening the

tag, you'll spot a very important line: {% csrf_token %}. Whenever you submit data to a server using a "POST" method, malicious sites can potentially intercept or forge that request.

By including this {% csrf_token %}, you tell Django to generate a unique, hidden security key for the form. When the user clicks "Save Workout," Django checks this token to guarantee the request is legitimate. If you forget this tag, Django will simply reject your form!


            {% csrf_token %}
            
                Activity
                {{ form.activity }}
                {% if form.activity.errors %}
                    {{ form.activity.errors }}
                {% endif %}
            
            
                Duration (minutes)
                {{ form.duration }}
                {% if form.duration.errors %}
                    {{ form.duration.errors }}
                {% endif %}
            

            
                Date
                {{ form.date }}
                {% if form.date.errors %}
                    {{ form.date.errors }}
                {% endif %}
            

            
                
                Cancel

Now let's talk about automatically generating the form fields. Instead of manually typing out all the HTML tags for the activity, duration, and date, we let Django do it for us using display tags ({{ }}).

Each {{ form.activity }}, {{ form.duration }}, and {{ form.date }} tag renders the corresponding form input. Django handles the HTML attributes, input types, and validation for you based on the model and form definitions.

The error blocks below each field display validation messages if a user submits invalid data, like entering text in the duration field instead of a number. Users make mistakes. They might leave a required field blank or type text into a number field. Fortunately, Django validates the data for you and sends back errors if something goes wrong.

Underneath each input field, we use a logic block that looks like this:
{% if form.activity.errors %}

This code checks a simple condition: Did the user mess up this specific field? If Django found an error with the "activity" input, the code drops into the if block and uses{{ form.activity.errors }} block to print the exact error message (like "This field is required") right below the input box.

You may notice that both templates include inline CSS rather than a separate stylesheet. For a small project like this, inline styles keep things simple and self-contained. In a larger project, you would use Django's static files system to manage CSS separately.

Step 8: How to Connect URLs

You have views and templates, but Django doesn't know when to use them yet. You need to map URLs to views so that visiting a specific address in the browser triggers the right view function.

8.1 How to Create App Level URLs

Create a new file called tracker/urls.py and add the following code:

from django.urls import path
from . import views

urlpatterns = [ 
    path('', views.workout_list, name='workout_list'), 
    path('add/', views.add_workout, name='add_workout'), 
]

Each path function takes three arguments.

The first is the route string that represents a URL pattern (an empty string means the root of the app).

The second is the view function to call when that URL is visited.

The third is a name you can use to reference this URL elsewhere in your code, like in the {% url %} template tags you used earlier.

8.2 How to Link App URLs to project

Now that your app-level URLs are set up, the next step is to connect them to the main project so Django knows where to start routing requests. Think of it like linking a smaller map (your app) to a bigger map (your project), so everything works together smoothly.

Open fitness_project.urls.py and update it to include your app's URLs:

from django.contrib import admin
from django.urls import path, include

urlpatterns = [
    path('admin/', admin.site.urls),
    path('', include('tracker.urls')),
]

The include() function tells Django to look at the URL patterns defined in the tracker/urls.py file whenever someone visits your site. The empty string prefix means your tracker app handles requests at the root of the site.

Here's the full picture of how a request flows through the URL system.

When someone visits http://127.0.0.1:8000/add/, Django first checks fitness_project/urls.py. It matches the empty prefix and delegates to tracker/urls.py. There, it matches add/ and calls the add_workout view.

Step 9: How to Test the Application Locally

At this point, your app has everything it needs to work. Let's test it.

Start the development server by running the command:

python manage.py runserver

Open your browser and visit http://127.0.0.1:8000/. You should see the workout list page with the heading "My Workouts" and a button that says "+ Log a Workout."

Click that button. You should see the workout form with fields for activity, duration, and date.

Fill in some test data:

Activity: Skipping
Duration: 25
Date: Pick today's date from the date picker

Click "Save Workout" You should be redirected back to the workout list page, and your new workout should appear as a card.

Try adding a few more workouts with different activities and dates. Make sure they all show up on the list page in the correct order (most recent first).

This is also a good time to experiment. Try submitting the form with missing fields and see how Django handles validation.

Try accessing the admin panel at http://127.0.0.1:8000/admin/ to see your workouts there as well.

If everything works as expected, you're ready to put your app on the internet.

Step 10: How to Prepare for Deployment

Running your app on localhost is great for development, but nobody else can see it. Deployment means putting your app on a server that's accessible from anywhere on the internet.

Before you deploy, you'll need to make a few changes to your project's settings.

10.1 How to Update Settings for Production

Open fitness_project/settings.py and make the following changes.

First, set DEBUG to False.

During development, DEBUG = True shows detailed error pages that help you fix problems. In production, these error pages would expose sensitive information about your code and server to anyone who triggers an error.

Next, update ALLOWED_HOSTS to include PythonAnywhere's domain.

This setting tells Django which domain names are allowed to serve your app. Replace yourusername with the actual PythonAnywhere username you will create in the next step.

ALLOWED_HOSTS = ['yourusername.pythonanywhere.com']

Finally, add a STATIC_ROOT setting so Django knows where to collect your static files (CSS, JavaScript, images) for production:

import os
STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles')

These are the minimum changes needed for a basic deployment.

💡 For a production app handling real user data, you would also want to set a secure SECRET_KEY, configure a proper database like PostgreSQL, and set up HTTPS. But for a learning project, these changes are enough.

Step 11: How to Deploy Your Django App on PythonAnywhere

PythonAnywhere is a hosting platform designed specifically for Python web applications. It offers a free tier that's perfect for beginner projects, and it handles much of the server configuration that would otherwise be complex to set up on your own.

11.1 How to Create a PythonAnywhere Account

Go to pythonanywhere.com and sign up for a free "Beginner" account. Remember the username you choose, because your app will be available at yourusername.pythonanywhere.com.

Now signup to the website. Fill in the username, email and password and click on the free tier or now.

11.2 How to Upload Your Project Files

After logging in, you have two options for getting your project files onto PythonAnywhere.

Option A: Upload using Git

If your project is in a Git repository, open a Bash console from the PythonAnywhere dashboard by clicking "Consoles" and then "Bash." Then clone your repository:

git clone https://github.com/yourusername/fitness-tracker.git

In this tutorial, we won't be using Git. Instead we'll follow the second option.

Option B: Upload files manually

First go your project folder in your computer and created a compressed version of the project.

IMPORTANT NOTE: When you create the compressed file, make sure to first create a copy of the project somewhere and remove the venv and pycache folder before you compress it.

Navigate to your home directory and click on upload file tab and upload the compressed file.

Now we need to unzip the compressed file. To do this, go to the Consoles tab and click on Bash console.

The bash console should open. Then type the following command in the console to unzip the folder:

unzip fitness-tracker.zip

11.3 How to Set Up a Virtual Environment in PythonAnywhere

Open a Bash console from the PythonAnywhere dashboard. Navigate to your project directory and create a fresh virtual environment:

cd fitness-tracker

Type the following command to install a virtual environment as we've done before and then activate the virtual environment:

python3 -m venv venv

source venv/bin/activate

Now install Django as before using pip install django command:

11.4 How to Run Migrations and Create a SuperUser on PythonAnywhere

While you're still in the Bash console with your virtual environment activated, run the migrations to create the database tables on the server:

python manage.py makemigrations

python manage.py migrate

python manage.py createsuperuser

11.4 How to Configure the Web App in Pythonanywhere

Go to the "Web" tab on the PythonAnywhere dashboard and click "Add a new web app." Follow the setup wizard:

Click "Next" on the domain name step (remember the free tier uses yourusername.pythonanywhere.com).

Select "Manual configuration" (not "Django" – the manual option gives you more control).

Then choose the Python version that matches what you installed. In my case it's 3.13, so I'll choose 3.13

Click on Next button and a WSGI (Web Server Gateway Interface) will be created.

With this we've created the web app:

After you've set up the web app, you have to do two more things:

Set the virtual environment path
Configure the WSGI file

11.5 How to Set the Virtual Environment Path

On the Web tab, scroll down to the "Virtualenv" section and enter the path to your virtual enviroment. The path to the file should be like this:

/home/yourusername/fitness-tracker/venv

11.6 How to Configure the WSGI file

Still on the Web tab, scroll to the code section and click on the WSGI configuration file link:

Delete all the contents and replace them with the content below and save the file:

import os
import sys
path = '/home/prabodhtuladhardev/fitness-tracker' #replace with your username
if path not in sys.path:
    sys.path.append(path)

os.environ['DJANGO_SETTINGS_MODULE'] = 'fitness_project.settings'

from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

11.7 How to Set Up Static Files

Still on the "Web" tab, scroll down to the "Static files" section. Add an entry:

URL: /static/
Directory: /home/yourusername/fitness-tracker/staticfiles

Then go back to your Bash console and run the following command:

python manage.py collectstatic

This copies all static files to the staticfiles directory so PythonAnywhere can serve them directly.

Go back to the "Web" tab and click the green "Reload" button at the top. This restarts your app with all the new configuration.

11.8 How to View Your Live Application

Open a new browser tab and visit https://yourusername.pythonanywhere.com. You should see your fitness tracker, live on the internet.

Try adding a workout.

Visit the admin panel at https://yourusername.pythonanywhere.com/admin/.

Everything should work just as it did on your local machine, but now anyone with the link can access it.

This is a meaningful milestone. You've gone from zero to a deployed Django application. Share the link with a friend or post it in a coding community. Seeing your work live on the internet is one of the most motivating experiences in learning to code.

Common Mistakes and How to Fix Them

Even when you follow each step carefully, things can go wrong. Here are the most common issues beginners run into and how to solve them.

"ModuleNotFoundError: No module named 'django'" – This usually means your virtual environment isn't activated. Run source venv/bin/activate (macOS/Linux) or venv\Scripts\activate (Windows) and try again. On PythonAnywhere, make sure the virtualenv path in the "Web" tab points to the correct location.

"DisallowedHost" error – You forgot to add your domain to ALLOWED_HOSTS in settings.py, or there's a typo. Double-check that it matches your PythonAnywhere URL exactly.

Static files not loading in production – Make sure you ran python manage.py collectstatic and that the static file mapping on PythonAnywhere points to the correct staticfiles directory. Also verify that STATIC_ROOT is set in settings.py.

"No such table" or migration errors – You probably forgot to run python manage.py migrate after cloning or uploading your project to PythonAnywhere. Run the migrate command in the Bash console.

Changes not showing up on PythonAnywhere – After making any code changes, you must click the "Reload" button on the "Web" tab. PythonAnywhere does not automatically detect file changes.

How You Can Improve This Project

The fitness tracker you built is intentionally simple. That's a feature, not a limitation. A working simple project is the perfect foundation for learning more.

Here are some ideas for expanding it.

Add user authentication: Right now, anyone who visits the site sees the same workout data. Django has a built-in authentication system that lets you add registration, login, and logout. Each user could then have their own private list of workouts.
Add the ability to edit and delete workouts. Currently, once a workout is saved, there's no way to change or remove it from the interface (you can do it through the admin panel, but not the main app). Try creating new views and templates for editing and deleting.
Add workout categories or tags. Let users categorize their workouts as "Cardio," "Strength," "Flexibility," and so on. This would involve adding a new field to the model or creating a separate Category model with a foreign key relationship.
Add charts and progress tracking. Use a JavaScript charting library like Chart.js to display workout trends over time. For example, you could show a bar chart of total minutes exercised per week.
Build an API with Django REST Framework. If you want to learn about building APIs, try installing Django REST Framework (DRF) and creating API endpoints for your workouts. This would let you build a mobile app or a separate front end that communicates with your Django back end.

Each of these improvements will teach you something new about Django while building on the foundation you already have.

Conclusion

You've built a fully functional fitness tracker web app with Django and deployed it to the internet. That's no small achievement.

Along the way, you learned how Django projects and apps are structured, how models define the shape of your data, how migrations translate those models into database tables, how views handle the logic of your application, how templates render dynamic HTML, and how URLs tie everything together. You also went through the entire deployment process on PythonAnywhere.

These are the core building blocks of Django development. The patterns you practiced here – defining a model, creating a form, writing a view, building a template, and connecting a URL – are the same patterns you will use in every Django project, no matter how complex.

The best way to solidify what you have learned is to keep building. Try one of the improvements mentioned above, or start a completely new project. A calorie tracker, a habit tracker, an expense tracker, or a personal journal would all use the same Django concepts with slightly different models and views.

How to Optimize Django REST APIs for Performance: Profiling, Caching, and Scaling.

Mari — Tue, 17 Feb 2026 18:22:09 +0000

Performance problems in APIs rarely start as performance problems. They usually start as small design decisions that worked perfectly when the application had ten users, ten records, or a single developer testing locally. Over time, as traffic increases and data grows, those same decisions begin to slow everything down.

In this article, we’ll walk step by step through how performance issues arise in Django REST APIs, how to see them clearly using profiling tools, and how to fix them using query optimization, caching, pagination, and basic scaling strategies.

This article will be most useful for developers who already understand Django, the Django REST Framework, and REST concepts, but are new to performance optimization.

Why Django REST APIs Become Slow

Before optimizing anything, it’s important to understand why APIs become slow in the first place.

Most performance issues in Django REST APIs come from three main sources:

Too many database queries
Doing expensive work repeatedly
Returning more data than necessary

Django is fast by default, but it does exactly what you ask it to do. If your API endpoint triggers 300 database queries, Django will happily run all 300.

Now let’s look at some common causes of performance issues in Django REST APIs.

1. N+1 Query Problems in Serializers

This happens when you loop over objects and access related fields, causing a separate query for each object.

# models.py
class Author(models.Model):
    name = models.CharField(max_length=100)

class Post(models.Model):
    title = models.CharField(max_length=200)
    author = models.ForeignKey(Author, on_delete=models.CASCADE)

# views.py (naive approach)
posts = Post.objects.all()
for post in posts:
    # This triggers a query per post to fetch the author
    print(post.author.name)

If you have 100 posts, this runs 101 queries: 1 for posts and 100 for authors. Django lazily loads related objects by default, so without intervention, your API performs repetitive database work that slows response times.

# Naive queryset fetching all related objects separately
posts = Post.objects.all()
authors = [post.author for post in posts]  # triggers extra queries per post

Each access to post.author triggers a new query. Even though you already fetched all posts, Django lazily loads related objects by default. This creates many extra queries, slowing down your API.

3. Serializing Large Datasets Without Pagination

Returning large query sets all at once can slow down your API and increase memory usage.

# views.py
from rest_framework.response import Response
from rest_framework.decorators import api_view
from .models import Post
from .serializers import PostSerializer

@api_view(['GET'])
def all_posts(request):
    posts = Post.objects.all()  # retrieves all posts at once
    serializer = PostSerializer(posts, many=True)
    return Response(serializer.data)

If your database has thousands of posts, this endpoint fetches everything in memory, serializes it, and sends it over the network. It’s slow and can crash under load. Later, we’ll learn to paginate results efficiently.

4. Recomputing Expensive Work Repeatedly

Some endpoints calculate the same values on every request instead of caching or precomputing.

def expensive_view(request):
    # Simulate expensive computation
    result = sum([i**2 for i in range(1000000)])
    return JsonResponse({"result": result})

Even if the data doesn’t change often, this computation happens on every request, consuming CPU time unnecessarily.

Performance optimization is about reducing unnecessary work.

At this point, it might be tempting to jump straight into fixes like caching responses or optimizing database queries. But doing that without evidence often leads to wasted effort or even new problems.

Before changing anything, you need to understand where your API is actually spending time. Is it the database? Is it serialization? Is it Python code running repeatedly on every request? This is where profiling becomes essential.

Profiling: Finding the Real Bottlenecks

Optimizing without profiling is guessing. Profiling helps you answer one question:

Where is my API actually spending time?

In practice, profiling means observing an API while it runs and collecting data about what it’s doing. This includes how many database queries are executed, how long those queries take, and how much time is spent in Python code, such as serializers or business logic.

By profiling first, you avoid making assumptions and can focus on fixing the parts of your API that are truly slowing things down.

Measuring Query Count in a View

During development, Django keeps track of all executed queries. You can inspect them directly:

from django.db import connection
from rest_framework.decorators import api_view
from rest_framework.response import Response
from .models import Post
from .serializers import PostSerializer

@api_view(["GET"])
def post_list(request):
    posts = Post.objects.all()
    serializer = PostSerializer(posts, many=True)

    response = Response(serializer.data)

    print(f"Total queries executed: {len(connection.queries)}")

    return response

If this prints 101 queries for 100 posts, you likely have an N+1 problem. This simple check confirms whether the database layer is the bottleneck.

One of the easiest ways to profile Django applications during development is by using tools that expose this information directly while requests are being processed.

The Django Debug Toolbar is one of the simplest ways to understand performance during development. It acts as a lightweight profiling tool that shows what happens behind the scenes when a request is handled.

It shows you:

How many SQL queries were executed
How long each query took
whether queries are duplicated
Which parts of the request lifecycle are slow

First, install it:

pip install django-debug-toolbar

In settings.py:

INSTALLED_APPS = [
    ...
    "debug_toolbar",
]

MIDDLEWARE = [
    ...
    "debug_toolbar.middleware.DebugToolbarMiddleware",
]

INTERNAL_IPS = [
    "127.0.0.1",
]

In urls.py:

import debug_toolbar
from django.urls import path, include

urlpatterns = [
    ...
    path("__debug__/", include(debug_toolbar.urls)),
]

When you load an endpoint in the browser during development, the toolbar displays total SQL queries, execution time, and duplicate queries. This makes inefficiencies immediately visible.

When you load an API endpoint and see 150 SQL queries for a single request, that’s a strong signal that something is wrong, often an N+1 query problem or inefficient serializer behavior.

Logging SQL Queries

Django allows you to log all executed SQL queries. This is especially useful when debugging API views.

Seeing the raw SQL makes inefficiencies obvious, such as repeated SELECT statements for the same table.

How to Enable SQL Query Logging

You can configure Django to log all SQL queries in settings.py:

LOGGING = {
    "version": 1,
    "handlers": {
        "console": {
            "class": "logging.StreamHandler",
        },
    },
    "loggers": {
        "django.db.backends": {
            "handlers": ["console"],
            "level": "DEBUG",
        },
    },
}

With this configuration, every SQL query will be printed to the console when your API runs. Repeated SELECT statements or unexpected queries become obvious.

Profiling API Response Time

Database queries are only one part of API performance. Beyond queries, it’s also important to measure the total response time of an endpoint.

Profiling response time helps you understand whether delays are caused by database access or by other parts of the request lifecycle. For example, if an endpoint takes 1.2 seconds to respond but only 50 milliseconds are spent on database queries, the bottleneck is likely in serialization, business logic, or repeated computations in Python.

By comparing query time and total response time, profiling helps you identify what to fix first instead of optimizing the wrong layer of the system.

How to Measure Total Response Time

import time
from rest_framework.decorators import api_view
from rest_framework.response import Response

@api_view(["GET"])
def example_view(request):
    start_time = time.time()

    # Simulate work
    data = {"message": "Hello world"}

    response = Response(data)

    end_time = time.time()
    print(f"Response time: {end_time - start_time:.4f} seconds")

    return response

If database queries are fast but the total response time is high, the bottleneck may be serialization or expensive Python logic.

Once you’ve identified that database access is a significant contributor to slow response times, the next step is to look more closely at how Django retrieves related data.

SQL Query Optimization in Django REST APIs

One of the most common reasons Django REST APIs become slow is inefficient access to related objects. This often manifests as the N+1 query problem, where fetching related objects triggers a separate database query for each item. Identifying and fixing this problem can significantly reduce the number of queries and improve API performance.

Understanding the N+1 Query Problem

Consider a simple example:

You fetch a list of posts
Each post has an author
For every post, Django fetches the author separately

If you have 100 posts, this results in 101 queries: 1 for the posts and 100 for the authors. This happens because Django lazily loads related objects by default. Without intervention, your API performs repetitive database work that slows down response times.

Solving the Problem with `select_related` and `prefetch_related`

Django provides built-in tools to control how related objects are loaded efficiently: select_related and prefetch_related.

1. Using select_related

select_related is designed for foreign key and one-to-one relationships. It performs an SQL join and retrieves related objects in a single query.

Use it when:

You know you will access related objects
The relationship is one-to-one or many-to-one

posts = Post.objects.select_related("author")

for post in posts:
    print(post.author.name)  # No additional queries

This performs a SQL JOIN and retrieves posts and authors in a single query, eliminating the N+1 problem.

It reduces multiple queries into just one, avoiding repeated database hits.

2. Using prefetch_related

prefetch_related is used for many-to-many and reverse foreign key relationships. It performs separate queries for each related table but combines the results in Python.

Use it when:

A SQL join would produce too much duplicated data
You are dealing with collections of related objects

Example: How to Optimize a Many-to-Many Relationship

Consider a blog application where posts can have multiple tags:

# models.py
class Tag(models.Model):
    name = models.CharField(max_length=50)

class Post(models.Model):
    title = models.CharField(max_length=200)
    tags = models.ManyToManyField(Tag)

Now imagine fetching posts and accessing their tags:

posts = Post.objects.all()

for post in posts:
    print(post.tags.all())  # Triggers additional queries

If you have 100 posts, Django may execute:

1 query to fetch posts
1 query per post to fetch related tags

This results in many unnecessary database hits.

You can optimize this using prefetch_related:

posts = Post.objects.prefetch_related("tags")

for post in posts:
    print(post.tags.all())  # Uses prefetched data

With this approach, Django performs one query for posts and one query for all related tags. It then matches them in Python, eliminating repeated database queries.

Together, these tools allow you to optimize your queries and eliminate the N+1 problem efficiently.

Common Beginner Mistakes

Even after applying these optimizations, it’s easy to make mistakes. Watch out for:

Forgetting that serializers can trigger additional queries
Using select_related on many-to-many relationships
Assuming Django automatically optimizes queries
Not checking the query count after adding serializers

Paying attention to these pitfalls ensures your API remains fast and scalable.

Caching in Django REST APIs

Even after optimizing database queries, API performance can still suffer if the same computations or database lookups are performed repeatedly. This is where caching comes in. Caching is a technique for storing the results of expensive operations so they can be retrieved more quickly the next time they are needed.

At its core, caching exists because computers have multiple layers of memory with different speeds:

CPU registers (fastest)
L1, L2, L3 caches
Main memory (RAM)
SSD storage
HDD storage (slowest)

Each layer trades speed for size: the closer the data is to the CPU, the faster it can be accessed. Software systems use the same principle; by storing frequently accessed data in a “closer” or faster location, applications can respond more quickly.

Cache Eviction

Caches are limited in size, so when a cache is full, some data must be removed to make room for new data. This process is called cache eviction.

Common eviction strategies include:

Least Recently Used (LRU): removes the data that hasn’t been accessed for the longest time
Random Replacement: removes a random item from the cache

The goal is to keep the data that is most likely to be requested again while freeing space for new data. Understanding this helps developers use caching effectively.

Caching in Application Architectures

Caching exists at several levels in modern software systems:

Client-side caching: Web browsers cache HTTP responses to reduce the need for repeated network requests. This is controlled with HTTP headers like Cache-Control.
CDN caching: Content Delivery Networks store static assets closer to users, reducing latency and server load.
Backend caching: Backend services cache results from database queries, computed values, or API responses. This is where Django caching is most commonly applied.

By applying caching strategically at the backend, APIs can serve data faster while reducing computation and database load.

Caching in Django

Django provides a flexible caching framework that supports multiple backends, including in-memory, file-based, database-backed, and third-party stores like Redis. The main types of caching in Django are:

Per-view caching: caches the entire output of a view. Ideal for endpoints where responses rarely change.
```
 from django.views.decorators.cache import cache_page

 @cache_page(60 * 15)  # cache for 15 minutes
 def my_view(request):
```
1. Template fragment caching: caches specific parts of a template to avoid repeated rendering.
2. Low-level caching: gives full control over what is cached and for how long, making it ideal for API responses.

By combining these approaches, you can reduce repeated work in your API, lower database load, and speed up response times.

When to Use Redis

While Django’s built-in caching backends are sufficient for many projects, high-traffic APIs often require a shared, in-memory cache. This is where Redis excels. Redis is designed for fast access, low latency, and can handle frequent reads across multiple servers.

You should consider using Redis when:

Data is read frequently but changes infrequently
Low latency is important for API responses
You need cache expiration and eviction policies
You want a shared cache across multiple servers or services

Redis is particularly effective for API endpoints that serve the same data to many users, such as frequently accessed lists or computed results.

Common Beginner Mistakes

Caching is powerful, but it’s easy to misuse. Some common pitfalls include:

Caching everything blindly: not all data benefits from caching
Forgetting cache invalidation: stale data can lead to incorrect responses
Using cache where query optimization would suffice: sometimes optimizing database queries is a better solution than caching.

Remember: caching should complement good database design, not replace it.

Pagination and Limiting Expensive Datasets

Even with caching, returning large datasets in a single request can slow down your API and increase memory usage. Pagination is a simple and effective way to limit the amount of data returned at once.

Pagination helps by reducing:

Database load
Memory usage
Serialization time
Network transfer size

Django REST Framework provides built-in pagination classes that make it easy to paginate endpoints. As a rule of thumb, always paginate list endpoints unless there is a strong reason not to.

Load Testing and Measuring Improvement

Optimizations are only meaningful if you can measure their impact. Load testing simulates multiple users accessing your API simultaneously, helping you answer key questions:

How many requests per second can my API handle?
Where does the API start to break under load?
Did caching, query optimization, and pagination actually improve performance?

By running load tests before and after optimization, you can validate that your changes have the desired effect and avoid optimizing the wrong parts of your system.

Summary and Next Steps

Optimizing Django REST APIs isn’t about chasing every tiny micro-optimization. It’s about reducing unnecessary work and focusing on the parts of your API that actually slow down performance.

Key Takeaways

Profile before optimizing: Identify the real bottlenecks before making changes.
Reduce database queries: Use techniques like select_related, prefetch_related, and avoid N+1 queries.
Cache frequently accessed data: Use Django caching and Redis to reduce repeated computations.
Paginate large datasets: Limit memory usage and network load by returning data in chunks.
Measure performance changes: Always verify that your optimizations have a real impact.

Next Steps for Your APIs

Add profiling to your existing APIs to understand where time is spent.
Identify one slow endpoint and focus on optimizing it first.
Optimize database queries using Django ORM best practices.
Introduce caching carefully; avoid caching everything blindly.
Measure the results with load testing and performance metrics.

Remember: Performance optimization is not a one-time task. It’s a habit built by continuously observing how your system works, testing improvements, and applying changes where they make the most impact.

How to Use the Django REST Framework - Build Backend APIs with DRF

Mari — Fri, 21 Nov 2025 21:13:28 +0000

When you click on most backend development tutorials, they often teach you what to do, not how to think.
That’s why many developers only realize their mistakes after they start building.

So, how does one actually think like a backend developer? Before answering that, let’s start with the basics: what exactly is backend development?

What is Backend Development?
Why Django REST Framework?
How to Think Like a Backend Developer
How to Install the Django REST Framework
The Backend Developer’s Mindset
Common Mistakes Beginners Make
Further Reading
Conclusion

What is Backend Development?

Backend development is the foundation of most web and mobile applications. It focuses on everything that happens behind the scenes, from processing logic and handling data to connecting with databases and APIs.

While it’s true that backend developers build APIs that communicate with the frontend, the job goes far beyond that. The backend is where data is validated, protected, stored, and retrieved.

In short: backend development is about building systems that ensure data integrity, performance, and scalability.

Backend developers are the ones responsible for designing and maintaining those systems. They ensure that every user request is processed efficiently and securely.

Now, how does the Django REST Framework (DRF) fit into all this?

Why Django REST Framework?

A beginner-friendly tutorial must use a tool that:

Teaches good structure
Encourages best practices
Hides unnecessary complexity
Helps you learn backend fundamentals correctly

That’s why this guide uses the Django REST Framework (DRF). Here’s how it compares to other popular Python frameworks.

Flask

Flask is a lightweight and flexible microframework. It is great for small projects, but:

You have to set up everything manually (routing, JSON handling, database handling).
You need extra libraries for authentication, validation, or serialization.
Beginners often create unstructured projects because Flask doesn’t enforce architecture.

Flask teaches freedom, not structure.

FastAPI

FastAPI is modern, fast, and async-first. However:

It assumes you already understand APIs.
It requires understanding Python type hints deeply.
The ecosystem is still growing.
Beginners may not understand its underlying concepts (dependency injection, async IO).

FastAPI teaches speed, not fundamentals.

Django REST Framework

DRF is ideal for beginners because:

It sits on top of Django, a very stable full-stack framework.
It encourages good architecture from day one.
It handles serialization, authentication, routing, validation, and permissions for you.
It gives you structure instead of chaos.

Bottom line: DRF can help you learn how backend systems work from scratch.

How to Think Like a Backend Developer

Thinking like a backend developer is not about memorizing code. It’s about learning to see the bigger picture, how data moves, how logic flows, and how to build systems that work reliably and can grow.

Backend thinking can be summarized into six main principles:

1. Think in Systems, Not Lines of Code

Many beginners focus on writing code that works for one feature. A backend developer thinks about the entire system.

Analogy: Imagine a factory. Each machine (function or endpoint) does one task, but the factory only works efficiently if every machine is arranged correctly and communicates properly.

Example: When a user submits a form to create a task:

The request reaches the server.
The backend validates the data.
The backend stores it in the database.
The backend sends a response to the user.

A backend developer doesn’t just write a function to save data. They ask:

Where should this logic live — view, serializer, or service layer?
How will the data be validated and cleaned?
How will the system scale if thousands of users submit tasks at the same time?

Seeing the system first makes code predictable, maintainable, and scalable.

2. Separate Concerns — Keep Things Organized

Backend thinking is about structure. Every piece of code should have a clear responsibility:

Models: Store and define your data
Serializers: Convert data to a format the client understands (like JSON)
Views: Apply the business logic and respond to requests

Why this matters: Without separation, code becomes messy and hard to debug. You might find yourself mixing database queries with validation or formatting, which leads to errors later.

Simple analogy: Think of a restaurant.

The chef prepares the food (model/data).
The waiter delivers the food to customers in a presentable way (serializer).
The manager decides who gets what and handles special requests (view/logic).

Each role is separate but connected. This is exactly how backend developers structure code.

3. Anticipate Problems Before They Happen

Backend developers don’t just code for today. They think ahead:

What if the user sends invalid data?
What if two users try to edit the same record at the same time?
How will the system handle millions of requests in the future?

Example: If a user tries to create a task without a title, a beginner might just let it crash. A backend developer writes validation rules to catch this and return a clear error message.

Rule of thumb: Always ask, “What could go wrong here?” and design your code to handle it gracefully.

4. Make Your Code Predictable and Readable

Backend development is about writing code for humans, not just computers.

Use clear variable names (task_title instead of x).
Keep functions short and focused.
Document your code.

This way, anyone can pick up your code and understand it, including your future self.

Tip: A backend system that is easy to read and predict is easier to debug, extend, and scale.

5. Think in the Request → Logic → Response Cycle

Every backend action fits into this pattern:

Request: The client sends data.
Logic: The server validates, processes, and decides what to do.
Response: The server sends data back in a structured way.

Example: User creates a task:

Request: { "title": "Learn DRF" }
Logic: Check title is not empty → save to database → mark completed as False
Response: { "id": 1, "title": "Learn DRF", "completed": false }

Thinking in this cycle makes debugging and designing systems intuitive.

6. Practice Thinking Like a Backend Developer

Ask questions before coding: “Where should this logic live? How will this affect other parts of the system?”
Break down problems into steps: Don’t just code the solution; code the process.
Visualize data flow: Draw diagrams if necessary, from user request to database and back.
Learn by doing: Build small projects and reflect on each component’s role.

Check out Andy Harris’s video on how to think like a programmer.

Now that you understand how backend developers think, let’s walk through setting up a real backend environment using Django REST Framework.

How to Install the Django REST Framework

Here’s how to get the Django REST framework running on your machine from scratch.

Step 1: Install Python

Make sure you have Python 3.8+ installed. You can check if Python is installed with this command:

python --version

If it’s not installed, download it from the official Python documentation.

Step 2: Create a Project Folder

Choose a location on your computer and create a folder for your project:

mkdir my_drf_project
cd my_drf_project

This keeps all your files organized in one place.

Step 3: Create a Virtual Environment

A virtual environment keeps your project dependencies separate from other projects.

Create a virtual environment:

python -m venv venv

Next, activate it. For Windows (PowerShell):

.\venv\Scripts\Activate.ps1

For Mac/Linux:

source venv/bin/activate

You’ll know it’s active when your terminal prompt starts with (venv).

Step 4: Install Django

Now install Django inside the virtual environment:

pip install django

Check that Django is installed:

python -m django --version

Step 5: Create a Django Project

Create a new Django project:

django-admin startproject core .

The . at the end means “create the project here.” Run the server to make sure it works:

python manage.py runserver

Visit http://127.0.0.1:8000/ in your browser. You should see the Django welcome page.

Step 6: Install Django REST Framework

Install DRF using pip:

pip install djangorestframework

Step 7: Add DRF to Installed Apps

Open core/settings.py and find the INSTALLED_APPS list. Add:

'rest_framework',

It should look like this:

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'rest_framework',
]

Step 8: Run Initial Migrations

Set up your database:

python manage.py migrate

Create a superuser for accessing the admin panel:

python manage.py createsuperuser

Follow the prompts for username, email, and password.

Step 9: Start the Server

Run your development server again:

python manage.py runserver

Visit:

http://127.0.0.1:8000/ → Django welcome page
http://127.0.0.1:8000/admin/ → Admin panel (login with superuser)

You now have Django + DRF installed and ready for API development.

Step 10: Verify DRF Installation

The easiest way to confirm that Django REST Framework is installed correctly is to build a very small test API. Each part of the setup helps you verify that DRF is working end-to-end.

Create a new app:

python manage.py startapp api

This creates an api folder where you’ll place your test model, serializer, and view. Adding it to INSTALLED_APPS tells Django to recognize the new app.

Add it to INSTALLED_APPS:

'api',

Create a simple models.py in the api app:

from django.db import models

class Task(models.Model):
    title = models.CharField(max_length=200)
    completed = models.BooleanField(default=False)

This model represents a basic task with a title and a completion status. Creating even a simple model lets you test whether DRF can serialize and expose database objects as API responses.

Run migrations:

python manage.py makemigrations
python manage.py migrate

These commands generate and apply database tables for the Task model. Without migrations, DRF won’t have anything to fetch and serialize.

Create a serializer (api/serializers.py):

from rest_framework import serializers
from .models import Task

class TaskSerializer(serializers.ModelSerializer):
    class Meta:
        model = Task
        fields = '__all__'

A serializer converts your Task model into JSON so it can be returned as an API response. This step confirms that DRF’s serializer tools are working.

Create a view (api/views.py):

from rest_framework import viewsets
from .models import Task
from .serializers import TaskSerializer

class TaskViewSet(viewsets.ModelViewSet):
    queryset = Task.objects.all()
    serializer_class = TaskSerializer

ModelViewSet automatically creates the CRUD API endpoints for your model. If this loads correctly, it means DRF’s generic views and viewsets are functioning.

Wire it to URLs (core/urls.py):

from django.urls import path, include
from rest_framework.routers import DefaultRouter
from api.views import TaskViewSet

router = DefaultRouter()
router.register('tasks', TaskViewSet)

urlpatterns = [
    path('admin/', admin.site.urls),
    path('api/', include(router.urls)),
]

The router generates routes /api/tasks/ for you. If routing works, DRF is properly integrated into your Django project.

Test the API by visiting:

http://127.0.0.1:8000/api/tasks/

If everything is set up correctly, you’ll see Django REST Framework’s browsable API. This confirms that DRF is installed, your project recognizes it, and it can serialize and return data successfully.

The Backend Developer’s Mindset

When writing backend code, your goal isn’t just to make something work; it’s to make it predictable, scalable, and maintainable.

Professional backend developers focus on:

Predictability over cleverness — Code should be clear to others.
Separation of concerns — Keep logic, data, and presentation layers distinct.
Validation — Never trust user input; always validate.
Consistency — Stick to naming conventions and reusable patterns.

This mindset is what separates backend coders from backend engineers.

Common Mistakes Beginners Make

Writing too much logic in views: Keep views light. Move business logic into services or serializers.
Ignoring validation: Always define validation rules in your serializers.
Not planning for scalability: Even small projects grow. Build like you expect more users.

Conclusion

Thinking like a backend developer isn’t about memorizing syntax; it’s about understanding how systems behave.

When you start reasoning through requests, logic, and responses, you begin to see the bigger picture, and that’s when you stop writing code and start building systems.

With Django REST Framework, that process becomes easier, cleaner, and more intuitive.

As you continue learning, build small APIs and gradually add features. The more you understand how data flows through a system, the more naturally backend thinking will come.

How to Revert a Migration in Django

Udemezue John — Wed, 16 Jul 2025 21:23:44 +0000

So, you're working with Django, you've run a migration, and now something’s broken. Maybe you added a field that shouldn't be there.

Maybe you renamed a model, and suddenly your database is a mess. Or maybe you're just experimenting and want to roll things back.

That’s where reverting migrations comes in.

Knowing how to undo a migration in Django is just as important as knowing how to make one. It’s not about being perfect – it’s about being able to fix mistakes fast, without panic. I've been there.

A single migration can break everything if it goes wrong. But the good news is, Django gives you tools to take a step back safely.

Let me walk you through how this works, using plain language and clear steps.

What Exactly Is a Migration in Django?
How to Revert a Migration in Django
- Case 1: Undo a Migration That’s Already Been Applied
- Case 2: Undo a Migration You Haven’t Applied Yet
Special Case: Reverting All Migrations (Reset Everything)
Example Scenario: Fixing a Broken Migration
Common Pitfalls (And How to Avoid Them)
FAQs
Further Resources
Conclusion

What Exactly Is a Migration in Django?

Before we can talk about undoing a migration, let’s make sure we’re on the same page.

A migration in Django is a record of changes to your database. It tracks what models you’ve added or changed, and applies those changes to your actual database using SQL (behind the scenes).

You usually create a migration with this command:

python manage.py makemigrations

And apply it like this:

python manage.py migrate

That’s when Django updates your database tables to match your models.

Now, what if you want to undo that last step?

How to Revert a Migration in Django

Alright, here’s the main part. Let’s say you just ran a migration and want to undo it. There are two situations:

You applied the migration already and want to reverse it
You haven’t applied it yet and just want to delete it

Let’s handle both.

Case 1: Undo a Migration That’s Already Been Applied

If you've already run python manage.py migrate, Django has changed your database.

To reverse that migration, use this:

python manage.py migrate your_app_name migration_name_before

Let me break that down:

your_app_name is the name of your Django app (like blog, users, or store)
migration_name_before is the name of the migration before the one you want to undo

Let’s go through an example.

Say you have these migrations for an app called store:

0001_initial.py  
0002_add_price_to_product.py  
0003_change_price_field.py

If you want to undo the 0003_change_price_field.py migration, you’d run:

python manage.py migrate store 0002

That tells Django to roll back to migration 0002, effectively undoing everything in 0003.

Once that’s done, you’ll see output like:

Operations to reverse:
   - Alter field price on product

And your database is back the way it was before 0003.

Case 2: Undo a Migration You Haven’t Applied Yet

Maybe you ran makemigrations, but not migrate. So you just created the migration file and haven’t actually touched the database yet.

In that case, you can safely delete the migration file.

Just go into your app’s migrations/ folder, and delete the unwanted migration file (for example: 0003_change_price_field.py).

Then you can re-run makemigrations with the correct changes.

Quick tip: Don't delete __init__.py or the 0001_initial.py file unless you know what you’re doing. That first one is usually required.

Special Case: Reverting All Migrations (Reset Everything)

Sometimes you just want to wipe all the migrations and start over.

This is common when you're still in development, and your database structure is messy.

Here's how I usually do it:

Delete the migration files inside the migrations/ folder of your app (except for __init__.py)
Drop the database or just clear the tables if you're using SQLite or a test DB
Run:

python manage.py makemigrations
python manage.py migrate

If you're using SQLite, you can also just delete the .sqlite3 file and start fresh.

For PostgreSQL or MySQL, you'll need to drop and recreate the database, or reset it using a tool like pgAdmin or DBeaver.

Example Scenario: Fixing a Broken Migration

Let’s say you added a new field to a model:

class Product(models.Model):
    name = models.CharField(max_length=100)
    price = models.DecimalField(max_digits=6, decimal_places=2, default=0.00)

You made a typo:

price = models.DecimalField(max_digits=6, decimal_places=2, default='free')

Oops. Django lets you do this:

python manage.py makemigrations store
python manage.py migrate

Then it breaks.

You can fix this by reverting:

python manage.py migrate store 0001

Then fix the typo in your model and run:

python manage.py makemigrations
python manage.py migrate

Back on track!

Common Pitfalls (And How to Avoid Them)

Don’t just delete a migration without reversing it first. This can confuse Django.
Always check which migrations are applied using:

python manage.py showmigrations

Keep backups of your database, especially in production. Use tools like pg_dump or mysqldump if needed.
Don't reset migrations in a live app unless you absolutely must. It can mess up production data.

FAQs

Can I revert more than one migration at a time?

Yes! You just migrate back to the point before the migrations you want to undo.

Example:

You’ve applied:

[X] 0001_initial  
[X] 0002_add_price_to_product  
[X] 0003_change_price_field  
[X] 0004_add_discount_field

To undo both 0004 and 0003, run:

python manage.py migrate store 0002

This rolls back both 0004 and 0003, leaving only 0001 and 0002 applied.

How do I know which migration names to use?

Run python manage.py showmigrations And you’ll see a list like:

 [X] 0001_initial
 [X] 0002_add_price_to_product
 [X] 0003_change_price_field

The [X] shows applied migrations. To undo 0003, migrate back to 0002.

Is reverting migrations safe?

It is, as long as you haven’t made changes to data that depend on the migration. Always test in development before trying in production.

Conclusion

Reverting migrations in Django isn't scary once you get the hang of it. It's like using undo in a Word document – you just need to know how far back to go.

So now that you know how to revert a migration in Django, what’s the trickiest migration issue you've run into—and how did you fix it?

Shoot me a message – I’d love to hear your story.

Further Resources

How to Activate Your Django Virtual Environment

Udemezue John — Wed, 16 Jul 2025 16:58:44 +0000

If you’re starting with Django, one of the first steps you’ll hear about is activating a virtual environment. And if that sounds a little technical, don’t worry – I’m going to walk you through exactly what that means, why it matters, and how to do it step-by-step, without any confusing terms.

I’ve helped a lot of people get started with Python and Django, and trust me: understanding virtual environments early on can save you tons of headaches later.

A virtual environment can help you keep your Django projects organized. It also avoids conflicts between different versions of packages, and gives you a cleaner way to manage your development tools.

By the end of this guide, you’ll not only know how to activate your virtual environment, but also why you should.

Let's get into it.

Here’s what we’ll cover:

What Is a Virtual Environment in Python?
Why Use a Virtual Environment?
How to Set Up and Activate a Django Virtual Environment
What Can You Do After Activating It?
How to Deactivate the Virtual Environment
FAQs
Bonus Tips
- Add a .gitignore File
- Use requirements.txt
Helpful Resources
Conclusion
Further Learning

What Is a Virtual Environment in Python?

A virtual environment is like a private workspace just for your project. Instead of installing packages (like Django) globally for your whole computer, you install them inside this little bubble. That way, different projects don’t mess with each other.

Imagine you’re working on two Django projects: one needs Django 3.2 and the other needs Django 4.1. Without a virtual environment, you'd run into version conflicts. But with virtual environments, each project stays separate and clean.

Why Use a Virtual Environment?

Here’s why I always use one when working with Django:

Keeps your project dependencies isolated.
Prevents version conflicts between different projects.
Makes it easy to manage and uninstall packages.
Most importantly, Django expects it, especially if you want to follow best practices.

How to Set Up and Activate a Django Virtual Environment

Let’s walk through the process from start to finish.

1. Install Python (If You Haven’t Yet)

You need Python 3.8 or later. You can check what version you have by opening your terminal and typing:

python --version

If you see something like Python 3.11.7You’re good.

If you don’t have Python, download it here:

👉 https://www.python.org/downloads/

Make sure to check the box “Add Python to PATH” during installation if you're on Windows.

2. Install `virtualenv` (Optional but Worth Knowing)

Python includes a built-in tool called venv, and that’s what we’ll use in this tutorial.

However, some developers prefer virtualenv because:

It works with older Python versions
It can be slightly faster in larger environments
It offers some additional flexibility

To install virtualenv just run:

pip install virtualenv

Note: You don’t need virtualenv for this tutorial, but it’s good to know about. We'll be using Python’s built-in venv going forward.

3. Create a Virtual Environment

Now go to your Django project folder (or make one):

mkdir my_django_project
cd my_django_project

Then run:

python -m venv venv

python -m venv uses Python’s built-in virtual environment module
venv is the name of the folder that will store your environment (you can call it anything)

This creates a folder called venv/ in your project directory. That folder contains everything your virtual environment needs.

4. Activate the Virtual Environment

Here’s the part everyone asks about.

Activation depends on your operating system.

On Windows (CMD):

venv\Scripts\activate

On Windows (PowerShell):

.\venv\Scripts\Activate.ps1

On Mac or Linux:

source venv/bin/activate

After you activate it, your terminal prompt will change. It’ll look something like this:

(venv) your-computer-name:my_django_project username$

That (venv) at the beginning means the virtual environment is active.

What Can You Do After Activating It?

Now that it’s active, you can install Django (or anything else) just for this project:

pip install django

This installs Django inside the virtual environment, not globally.

To double-check:

pip list

You’ll see Django and any other installed packages listed there.

How to Deactivate the Virtual Environment

When you’re done working, just type:

deactivate

That’s it. Your terminal goes back to normal, and your system’s Python is no longer linked to the project.

FAQs

Do I need to activate the environment every time?

Yes, every time you open a new terminal session and want to work on your Django project, activate it again using the command for your OS.

What if `activate` Doesn’t work?

If you’re on Windows, PowerShell might block the script. Run this:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Then try activating again.

Can I use VS Code or another editor with this?

Absolutely. VS Code even detects your virtual environment automatically. You can select the interpreter from the bottom-left or by pressing Ctrl+Shift+P → “Python: Select Interpreter.”

Bonus Tips

Add a `.gitignore` File

If you're using Git, you don’t want to upload the venv folder to GitHub. Add this line to your .gitignore file:

venv/

Use `requirements.txt`

Once you’ve installed your project’s packages, freeze them like this:

pip freeze > requirements.txt

Then later, you (or someone else) can install them with:

pip install -r requirements.txt

This is useful for team projects or for moving your app to a server.

Conclusion

Activating your Django virtual environment might seem like a small thing, but it’s a big step toward becoming a confident and organized developer.

Once you get the hang of it, it becomes second nature – and your future self will thank you for learning it the right way from the start.

Would you love to connect with me? You can do so on X.com/_udemezue

Helpful Resources

Further Learning

If you're serious about Django, here are some free and paid resources I recommend:

Django Crash Course for Beginners

Beau Carnes — Thu, 01 May 2025 16:58:11 +0000

Django is a high-level web framework built with Python that encourages rapid development and clean, pragmatic design. Django handles much of the heavy lifting involved in web development, so you can focus more on writing your app and less on reinventing the wheel. Whether you want to build a blog, an e-commerce platform, or a custom web service, Django provides the structure and tools to help you get the job done efficiently.

What makes Django especially powerful is its “batteries-included” philosophy. This means it comes with a wide range of features out of the box, including an ORM (Object-Relational Mapper) for interacting with databases, a templating engine for rendering dynamic HTML pages, robust form handling, user authentication, an admin interface, and much more. Django is also built with security in mind, offering protection against common web vulnerabilities like SQL injection, cross-site scripting, and cross-site request forgery. Plus, Django’s active community and extensive documentation make it one of the most accessible frameworks for beginners.

We just published a course on the freeCodeCamp.org YouTube channel that will teach you all about getting started with Django. Taught by Abel Gideon, this Django crash course for beginners offers a step-by-step introduction to the framework and its core components. You’ll begin with setting up your development environment and understanding how to use essential tools like django-admin and manage.py. From there, the course introduces the fundamental concepts of Django’s architecture, particularly the Model-View-Template (MVT) pattern, which separates data handling, logic, and presentation.

The course covers things like how to create Django apps, define views and handle requests, work with models and databases, and design user-facing pages using Django’s template system. You’ll also explore how forms work in Django, how to use the Django Admin panel for content management, and how to integrate a MySQL database into your project. The course culminates in building a complete Django project, giving you a real-world example of how everything fits together.

By the end of the course, you’ll have a clear understanding of how Django works and how to use it to create your own dynamic web applications. Whether you’re looking to build a personal website, a data-driven dashboard, or the backend for a mobile app, this course will give you the foundation you need to move forward confidently in Django development.

Watch the full course on the freeCodeCamp.org YouTube channel (1-hour watch).

How to Get the User Model in Django – A Simple Guide With Examples

Udemezue John — Wed, 30 Apr 2025 15:19:33 +0000

When I’m working with Django, one of the first things I often need to do is work with users – like getting the logged-in user, creating a new one, or extending the default user model to add more information.

Now, Django has a built-in User model, but sometimes you might want a custom one. That's where things can get a little confusing if you're just starting.

The good news? Getting the user model in Django is very simple once you understand how Django is set up.

Today, I’ll walk you through exactly how to get the user model in Django, explain why it matters, show you real code you can use, and answer a few common questions people usually have around this topic.

Let's jump right into it.

Why Getting the User Model Correctly Matters
How to Get the User Model in Django
Full Example: Using the User Model
When to Use settings.AUTH_USER_MODEL
Quick Summary
Common Mistakes to Avoid
FAQs
Further Resources
Conclusion

Why Getting the User Model Correctly Matters

Before anything else, it’s important to know why this even matters.

Django projects depend heavily on user information – not just for logins, but for permissions, profiles, admin management, and much more.

If you get the user model the wrong way, you can easily run into problems later, especially if you customize your user model.

Django even warns you about this in its official documentation. If you don't use the right way to access the user model, your project could break when you change or extend it.

That’s why it’s super important to always get the user model the recommended way, which I’ll show you next.

How to Get the User Model in Django

Alright, here’s the simplest way to get the user model in Django:

from django.contrib.auth import get_user_model

User = get_user_model()

What’s happening here?

get_user_model() is a built-in Django function.
It returns the correct User model – whether you're using the default one or a custom one you created.

If you’re wondering why not just import from django.contrib.auth.models import User, the reason is this: if you ever swap out the default User model for a custom one, directly importing like that will break your code.

By using get_user_model(), you stay safe and future-proof your project.

Full Example: Using the User Model

Let’s look at a full working example, not just a little snippet.

Imagine you want to create a new user inside a Django view:

from django.contrib.auth import get_user_model
from django.http import HttpResponse

def create_user_view(request):
    User = get_user_model()
    user = User.objects.create_user(username='newuser', password='securepassword123')
    return HttpResponse(f"Created user: {user.username}")

In this example:

First, I get the user model with get_user_model().
Then, I use Django’s built-in create_user method to create a user safely.
Finally, I send back a simple HTTP response showing the created username.

Notice how clean and flexible it is – no matter what user model you're using under the hood.

When to Use `settings.AUTH_USER_MODEL`

Another thing you’ll often see in Django projects is something like this:

from django.conf import settings

settings.AUTH_USER_MODEL

This doesn’t get the user model. Instead, it gives you the string path to the user model, like "auth.User" (for default) or "myapp.MyCustomUser" if you customized it.

You usually use settings.AUTH_USER_MODEL inside your models.py when you want to link to the User model in a ForeignKey, OneToOneField, or ManyToManyField.

For example:

from django.conf import settings
from django.db import models

class Profile(models.Model):
    user = models.OneToOneField(settings.AUTH_USER_MODEL, on_delete=models.CASCADE)
    bio = models.TextField()

Here, the Profile model is tied to the correct user model. Again, this keeps your project flexible and future-proof.

Quick Summary

Situation	What to Use
Getting the actual User model in Python code (views, forms, admin, and so on)	`get_user_model()`
Referring to the User model in database relationships (ForeignKey, OneToOneField, and so on)	`settings.AUTH_USER_MODEL`

Remember this table – it saves a lot of headaches later!

Common Mistakes to Avoid

Directly importing User: Never just do from django.contrib.auth.models import User unless you are 100% sure you're sticking with the default model forever (not recommended).
Hardcoding relationships: If you write something like ForeignKey('auth.User') instead of using settings.AUTH_USER_MODEL, it will break if you ever switch to a custom user model.
Not creating custom user models early: If you think you might ever need a custom user model (like adding phone numbers, extra profile fields), set it up early. Switching later is painful once you have a database full of users.

FAQs

1. Can I access `request.user` directly?

Yes! Inside views, request.user gives you the current logged-in user object. Behind the scenes, Django is using the correct user model, whether it’s custom or default.

2. What happens if I call `get_user_model()` multiple times?

No problem at all. Django caches it internally, so it’s efficient. Feel free to call it wherever you need it.

3. How do I know if I’m using a custom user model?

Check your Django settings file (settings.py) and look for AUTH_USER_MODEL. If it’s set (like 'myapp.MyCustomUser', you are using a custom model. If it’s not there, Django is using the default.

4. When should I create a custom user model?

If you even think you’ll need fields like phone number, date of birth, profile pictures, and so on, it’s better to set up a custom model early.

Here’s a great guide from Django’s official docs on customizing user models.

Conclusion

Working with users in Django doesn’t have to be tricky. Once you know to use get_user_model() when you need the model and settings.AUTH_USER_MODEL for database relationships, your code stays clean, safe, and ready for whatever changes come your way.

Now that you know how to get the user model in Django, what’s one thing you'd love to customize about your users in your project? Shoot me a message on X.

If you want me to show you how to build a custom user model from scratch, let me know – it’s not hard once you know the steps.

Further Resources

How to Register Models in Django Admin

Udemezue John — Tue, 29 Apr 2025 14:43:46 +0000

When you're building a website or an app with Django, one of the most exciting moments is when your database models finally come to life.

But to manage your data easily – adding, editing, or deleting entries – you need Django’s Admin panel.

Now, here’s the catch: just creating a model isn’t enough. If you want it to show up in the Admin panel, you have to register it.

And honestly, registering models in Django Admin is one of the simplest but most important steps. If you miss it, it feels like your model doesn’t even exist.

In this guide, I’ll walk you through exactly how to register your models in Django Admin, step-by-step, with easy-to-understand code examples.

Why Django Admin Matters
How to Register Models in Django Admin
FAQS
Helpful Links and Resources
Final Thoughts

Why Django Admin Matters

Django Admin is like your personal dashboard for the backend of your website. Once you register your models, you can manage your app's content without touching any code.

Imagine being able to add new blog posts, approve users, update product listings – all with a few clicks. That’s the magic of Django Admin.

Without properly registering your models, you’re stuck managing everything manually, which can get messy real quick.

Plus, Django Admin saves developers hours of time. It’s one of the reasons Django is such a powerful framework.

How to Register Models in Django Admin

Step 1: Make Sure You Have a Model

Before you can register anything, you need a model. Here’s a super basic example of a model inside a Django app called blog.

Inside blog/models.py:

from django.db import models

class Post(models.Model):
    title = models.CharField(max_length=200)
    body = models.TextField()
    date_created = models.DateTimeField(auto_now_add=True)

    def __str__(self):
        return self.title

In this model:

title is a short text field.
body is for longer content.
date_created automatically stores the time when the post is created.

And that __str__ method? That’s just telling Django how to show each Post in the Admin – it’ll display the post’s title instead of something like Post object (1).

Quick tip: Always add a __str__ method to your models. It makes your Admin interface much cleaner.

Step 2: Register Your Model in Admin

Alright, your model is ready. Time to register it!

Open blog/admin.py. When you create a new Django app, this file is empty by default.

Here’s how to register the Post model:

from django.contrib import admin
from .models import Post

admin.site.register(Post)

What’s happening here?

First, you import Django’s admin module.
Then, you import your model (Post).
Finally, you use admin.site.register() to tell Django, "Hey, I want this model to show up in the Admin panel."

Save the file. Now if you go to your Admin site (usually at http://127.0.0.1:8000/admin), you’ll see Posts listed there.

Step 3: (Optional) Customize How Your Model Looks in Admin

By default, Django Admin shows your models in a very basic table. But you can make it so much better with a little customization.

Here’s how you can make Posts show the title and creation date at a glance.

Still inside blog/admin.py:

from django.contrib import admin
from .models import Post

class PostAdmin(admin.ModelAdmin):
    list_display = ('title', 'date_created')

admin.site.register(Post, PostAdmin)

Now:

list_display tells Django which fields you want to show in the list view.
You create a PostAdmin class that describes how the Post model should behave in Admin.
When you register, you pass both the model (Post) and the admin class (PostAdmin).

Quick tip: Customizing your Admin improves your workflow a lot – especially when you’re managing many entries.

FAQS

1. I added a model, but it’s not showing up in Admin. What happened?

Make sure you:

Registered the model inside admin.py.
Ran migrations (python manage.py makemigrations and python manage.py migrate) if you changed anything in the model.

Also, check if the app is listed in your INSTALLED_APPS inside settings.py.

2. Do I have to register every model separately?

Yes. Each model you want to manage in Admin needs to be registered. But you can register multiple models together too:

from .models import Post, Comment, Category

admin.site.register([Post, Comment, Category])

3. How do I unregister a model?

You can use:

from django.contrib import admin
from .models import Post

admin.site.unregister(Post)

But honestly, most of the time, you just stop registering it if you don't want it there.

Final Thoughts

Registering models in Django Admin might seem like a tiny step, but it has a huge impact on how you work with your data.

It turns your database into a friendly dashboard that anyone can use – even non-technical people.

Once you get comfortable with registering and customising your models, you’ll move faster and feel a lot more in control of your app.

Now I’m curious — which model are you most excited to register in your Django Admin? Let’s chat on X.

Helpful Links and Resources

These are great places to go if you want to dive even deeper into Django Admin customization.

How to Enable CORS in Django

Udemezue John — Mon, 28 Apr 2025 15:51:42 +0000

If you've ever tried to connect your frontend app to your Django backend and suddenly hit an error that looks something like "has been blocked by CORS policy", you're not alone. It’s frustrating, especially when your code seems fine.

So what’s going on?

This is where CORS (Cross-Origin Resource Sharing) comes in. It's a browser security feature that blocks web pages from making requests to a different domain than the one that served the web page.

It’s there to protect users, but if it’s not configured correctly, it can stop your app from working the way you want.

Let’s fix that.

In this article, I’ll walk you through everything you need to know to enable CORS in Django without headaches.

Here’s what we’ll cover:

What is CORS and Why Should You Care?
How to Enable CORS in Django
Optional Settings You Might Need
Example: Full Settings File Snippet
Common Errors (And How to Fix Them)
FAQs
Further Resources
Final Thoughts

What is CORS and Why Should You Care?

Before you start changing settings, it’s important to understand what CORS is.

Imagine you have a frontend built with React running on http://localhost:3000 and a Django API running on http://localhost:8000.

When the frontend tries to talk to the backend, your browser sees that they’re not the same origin (they have different ports), and it blocks the request.

That’s CORS doing its job. It assumes you might be trying to do something unsafe – like stealing cookies or user data – so it steps in.

Now, as a developer, if you trust the frontend and you own both ends, then it’s safe to let those requests through. You just need to tell Django it’s okay.

How to Enable CORS in Django

You’re going to need a third-party package called django-cors-headers. It’s widely used and actively maintained. Here’s how to set it up:

1. Install `django-cors-headers`

Run this in your terminal:

pip install django-cors-headers

This adds the package to your environment so Django can use it.

2. Add It to `INSTALLED_APPS`

Open your settings.py file and find the INSTALLED_APPS section. Add this line:

INSTALLED_APPS = [
    ...
    'corsheaders',
]

This registers the app with Django.

3. Add Middleware

Now scroll down to the MIDDLEWARE section in settings.py. Add this at the top of the list:

MIDDLEWARE = [
    'corsheaders.middleware.CorsMiddleware',
    'django.middleware.common.CommonMiddleware',
    ...
]

Why at the top? Because middleware in Django runs in order. If you don’t place it at the top, the CORS headers might not be added correctly, and your browser will still block your requests.

4. Set the Allowed Origins

This is where you tell Django which origins are allowed to talk to your backend.

Still in settings.py, add:

CORS_ALLOWED_ORIGINS = [
    "http://localhost:3000",
]

Replace localhost:3000 with whatever domain or port your frontend is using. If you're using HTTPS or deploying, make sure to include the correct URL, like https://yourfrontend.com.

And that’s it! You’re now allowing your frontend to access your backend.

Optional Settings You Might Need

Depending on your project, you might run into other issues. Here are some extra settings you might find useful:

Allow All Origins (Not Recommended for Production)

If you’re just testing and want to allow everything (be careful with this), you can use:

CORS_ALLOW_ALL_ORIGINS = True

Again, don’t use this in production unless you understand the risks. It can open up your API to abuse.

Allow Credentials (Cookies, Auth)

If your frontend is sending authentication credentials like cookies or tokens, you also need this:

CORS_ALLOW_CREDENTIALS = True

And make sure you don’t use CORS_ALLOW_ALL_ORIGINS with this setting – it won’t work due to security rules. Stick to CORS_ALLOWED_ORIGINS.

Allow Specific Headers

By default, common headers are allowed, but if you’re sending custom ones (like X-Auth-Token), you can add:

CORS_ALLOW_HEADERS = [
    "content-type",
    "authorization",
    "x-auth-token",
    ...
]

Example: Full Settings File Snippet

Here’s a mini version of what your settings.py might look like after setup:

INSTALLED_APPS = [
    ...
    'corsheaders',
    ...
]

MIDDLEWARE = [
    'corsheaders.middleware.CorsMiddleware',
    'django.middleware.common.CommonMiddleware',
    ...
]

CORS_ALLOWED_ORIGINS = [
    "http://localhost:3000",
]

CORS_ALLOW_CREDENTIALS = True

You can tweak this based on your needs, but that’s the basic structure.

Common Errors (And How to Fix Them)

1. CORS Not Working At All?

Double check:

You added corsheaders.middleware.CorsMiddleware it at the top of the middleware list.
Your frontend origin matches exactly, including port and protocol.
You restarted your server after changing the settings.

2. Preflight Request Fails (OPTIONS method)

Sometimes your browser sends an OPTIONS request first to check if the server will allow the real request. Make sure your views or Django setup allow that method, or Django will return a 405 error.

You don’t usually need to do anything here unless you’re using a custom middleware or view decorator that blocks it.

3. Using Django Rest Framework?

No problem – django-cors-headers works out of the box. Just make sure it’s installed and the middleware is set up correctly.

FAQs

Can I allow multiple frontend URLs?

Yes! Just add more items to the list:

CORS_ALLOWED_ORIGINS = [
    "http://localhost:3000",
    "https://myfrontend.com",
]

Does CORS affect local development only?

No, it applies in production too. Any time your frontend and backend are on different origins (different domain or port), you need to handle CORS.

Is it secure to allow all origins?

No. Only do that temporarily during development. Always restrict access in production to just the domains you trust.

Do I need to change anything on the frontend?

Sometimes. If you're sending credentials (like cookies), you’ll need to set credentials: "include" in your fetch or Axios requests.

Example with fetch:

fetch("http://localhost:8000/api/data", {
  method: "GET",
  credentials: "include",
})

Final Thoughts

CORS can feel like a wall you keep running into when building web apps. But once you get the hang of how it works – and how to set it up in Django – it becomes a small thing you configure and move on.

Just remember:

Be specific in production
Always restart the server after changes
Don’t ignore warnings in your browser console – they’re your friends

Now you know how to enable CORS in Django the right way.

Further Resources

django-cors-headers GitHub page – for full documentation.
MDN CORS Overview – to understand how CORS works under the hood.
Official Django Middleware Docs

How to Create Models in Your Django Project

Udemezue John — Fri, 25 Apr 2025 19:47:47 +0000

If you're building something with Django, there's one thing you can't skip: creating models. Models are the heart of any Django app. They define how your data is structured, how it's stored in the database, and how Django can interact with it.

Now, if you're new to Django or still wrapping your head around the basics, don’t worry. I’ve been there too. Models might sound a bit intimidating at first, but they’re pretty straightforward once you see how they work.

I’ll walk you through it all – step by step – so by the end of this post, you’ll not only know how to create models, but also how to use them in real projects.

Let’s get into it.

Here’s what we’ll cover:

What is a Model in Django?
How to Create Models in Django
Extra Model Features That You’ll Use
Using Models in Django Admin
FAQs
Final Thoughts

What is a Model in Django?

A model in Django is just a Python class that tells Django how you want your data to look. Django takes care of the hard part (talking to the database), so you can focus on describing your data in simple Python code.

Here’s a quick example of a basic model:

from django.db import models

class Book(models.Model):
    title = models.CharField(max_length=100)
    author = models.CharField(max_length=50)
    published_date = models.DateField()
    price = models.DecimalField(max_digits=5, decimal_places=2)

Let me break it down:

title and author are just short pieces of text, so I’m using CharField.
published_date is a date – easy enough, that’s what DateField is for.
price is a number with decimals, so DecimalField does the job.

Each line describes one piece of data I want to store for every book. Simple, right?

How to Create Models in Django

Step 1: Start a Django Project (if you haven’t already)

If you’re brand new, first you need a Django project:

django-admin startproject mysite
cd mysite
python manage.py startapp books

Now you’ve got a Django app called books where you can put your models.

Step 2: Define Your Model

Inside your app folder (books), open models.py. That’s where you’ll define your model.

Here’s a slightly more real-world example:

from django.db import models

class Author(models.Model):
    name = models.CharField(max_length=100)
    birthdate = models.DateField()

    def __str__(self):
        return self.name


class Book(models.Model):
    title = models.CharField(max_length=200)
    author = models.ForeignKey(Author, on_delete=models.CASCADE)
    summary = models.TextField()
    isbn = models.CharField(max_length=13, unique=True)
    published = models.DateField()
    price = models.DecimalField(max_digits=6, decimal_places=2)

    def __str__(self):
        return self.title

What’s happening here:

I’ve created two models: Author and Book.
Book has a relationship with Author using ForeignKey. That means one author can have many books.
I’m using __str__() to return a nice name when I look at objects in the Django admin.

Step 3: Register the App and Create the Database

Before Django can use your models, make sure your app is added to the project settings.

Open mysite/settings.py and find the INSTALLED_APPS list. Add 'books', to it:

INSTALLED_APPS = [
    # other apps
    'books',
]

Now, run migrations to create the database tables for your models:

python manage.py makemigrations
python manage.py migrate

This is how Django turns your Python code into actual database tables. The first command makes a migration file (basically, instructions for the database), and the second applies it.

Step 4: Create and Use Objects

Now you can use these models in your code. Open the Django shell:

python manage.py shell

Then try this out:

from books.models import Author, Book
from datetime import date

# Create an author
jane = Author.objects.create(name="Jane Austen", birthdate=date(1775, 12, 16))

# Create a book
book = Book.objects.create(
    title="Pride and Prejudice",
    author=jane,
    summary="A novel about manners and marriage in early 19th-century England.",
    isbn="1234567890123",
    published=date(1813, 1, 28),
    price=9.99
)

print(book)

Django will save these to your database automatically.

Extra Model Features That You’ll Use

1. Default Values

You can give a field a default value:

is_published = models.BooleanField(default=False)

2. Auto Timestamps

These are super useful when tracking created or updated times:

created_at = models.DateTimeField(auto_now_add=True)
updated_at = models.DateTimeField(auto_now=True)

3. Model Meta Options

You can add class Meta to customize things like the default ordering:

class Book(models.Model):
    # fields...

    class Meta:
        ordering = ['published']

Using Models in Django Admin

Django’s built-in admin panel is one of the best parts of the framework. But your models won’t show up there unless you register them.

In books/admin.py, add:

from django.contrib import admin
from .models import Author, Book

admin.site.register(Author)
admin.site.register(Book)

Now run:

python manage.py createsuperuser

Then go to http://127.0.0.1:8000/admin, log in, and boom – your models are there, with a full interface.

FAQs

Can I change a model after I’ve made it?

Yes, but you’ll need to make a new migration:

python manage.py makemigrations
python manage.py migrate

What databases work with Django?

Django works with PostgreSQL, MySQL, SQLite (default), and more. Most people start with SQLite when learning because it's easy and works out of the box.

What’s the difference between CharField and TextField?

Use CharField for short text with a max length (like a name or title). Use TextField for longer text (like a blog post or summary).

Final Thoughts

Once you understand models, the rest of Django starts to click into place. Everything – forms, views, templates – eventually connects back to the model. It's how your app stores and works with real data.

The best way to learn is by building something. Start small, maybe a book catalog, a task manager, or a personal blog. Add models one at a time and play with them in the admin.

Further Resources

How to Change Your Django Secret Key (Without Breaking Your App)

Udemezue John — Fri, 25 Apr 2025 14:40:23 +0000

If you're working on a Django project, you've probably come across the SECRET_KEY in your settings file. It might seem like just another line of code, but it's one of the most important pieces of your project.

SECRET_KEY keeps your app secure by signing cookies, passwords, and other sensitive data. And if it ever gets exposed or leaked – yeah, that’s a problem.

Changing your Django SECRET_KEY is something you should do carefully. Maybe your key was committed to GitHub (we’ve all been there), or you just want to refresh it for better security.

Whatever the reason, I’ll walk you through how to do it safely without breaking anything. I’ll explain everything in plain English so you’re not left wondering what just happened.

Let’s get into it.

What Is The Django `SECRET_KEY`?

The SECRET_KEY is a long string of random characters stored in your settings.py file. It’s used internally by Django to:

Securely sign session cookies
Generate password reset tokens
Protect data using cryptographic signing

Here’s what it looks like in your Django project:

# settings.py
SECRET_KEY = 'django-insecure-12345supersecretrandomstring'

If someone gets access to your SECRET_KEY, they could potentially:

Forge session cookies and impersonate users
Reset passwords or tamper with signed data
Compromise the entire app

So yeah – it’s kind of a big deal.

When Should You Change Your Django Secret Key?

You should change your SECRET_KEY if:

You accidentally shared it in public code (like GitHub)
It was hardcoded in a file, and you want to switch to environment variables
You’re rotating keys as part of a security policy
You suspect it’s been compromised

Still not sure if it’s necessary? If the key has ever been shared or stored where someone else could access it, just change it.

How to Change Your Django `SECRET_KEY` Safely

1. Generate a New Secret Key

The key needs to be long, random, and secure. Django doesn’t provide a command for this out of the box, but you can generate one using Python.

Here’s a simple script:

from django.core.management.utils import get_random_secret_key

print(get_random_secret_key())

To run this:

Open your terminal
Run the Django shell with python manage.py shell
Paste in the script

It’ll return something like:

x3%6kn$mlg58+as!rcvnmvd8%(2p!p#&yk@r)+tdlj*w9kx!5gx

Copy this. You’ll need it in a second.

2. Store the Key Securely (Don’t Hardcode It)

Instead of pasting it into settings.py, it’s better to use an environment variable. That way, you don’t risk exposing it if you ever share your code.

Here’s how:

Open your .env file (create one if it doesn’t exist):

# .env
SECRET_KEY='x3%6kn$mlg58+as!rcvnmvd8%(2p!p#&yk@r)+tdlj*w9kx!5gx'

Install python-decouple if you haven’t already:

pip install python-decouple

Update your settings.py:

from decouple import config

SECRET_KEY = config('SECRET_KEY')

Now your key is stored outside your code. Much safer.

3. Commit Carefully

Make sure:

Your .env file is added to .gitignore
You never push it to your repository

Here’s how .gitignore should look:

# .gitignore
.env

You’d be surprised how often .env files get pushed by accident. Always double-check before you commit.

4. Restart Your App

After changing the key, restart your server. If you’re using a platform like Heroku or Docker, make sure you update the SECRET_KEY in your environment variables dashboard.

For Heroku:

heroku config:set SECRET_KEY='your-new-key'

For Docker:

# docker-compose.yml
environment:
  - SECRET_KEY=your-new-key

5. Re-Log In (and Ask Users To Do the Same)

Changing the secret key invalidates all old sessions. So, everyone (including you) will be logged out. This is expected behaviour. If you're running a public site, it’s a good idea to notify users in advance.

What Happens If You Don't Change It?

If your key is compromised, attackers can:

Forge data
Hijack accounts
Break authentication systems

It’s not just about best practices. It’s about real-world security.

FAQs

Will this break my app?

No, as long as you restart your app and store the key properly, everything will work fine. Just remember: all users will be logged out.

Can I use the same key for multiple projects?

Nope. Each project should have its unique secret key.

Can I rotate the key regularly?

Yes, just be mindful that changing it too often will log users out repeatedly.

I forgot to add `.env` to `.gitignore`. What now?

Regenerate the key, update your project, and make sure the new .env file isn’t tracked.

Final Thoughts

Changing your Django SECRET_KEY might feel intimidating the first time, but it’s pretty simple when you break it down. As long as you generate a secure key, store it safely, and don’t expose it publicly, you’re doing great.

One last thing—when was the last time you checked if your secret key was accidentally pushed to GitHub? It might be a good time to take a quick look.

Helpful Resources

What Is Q in Django? (And Why It's Super Useful)

Udemezue John — Thu, 24 Apr 2025 14:29:46 +0000

If you're working with Django and writing queries, chances are you’ve bumped into a situation where you need to combine filters in a way that’s just... not straightforward.

Maybe you're trying to search for users with a username or an email that matches something. Or maybe you're trying to filter results where one condition is true but another is false.

That’s where Q comes in.

I remember the first time I ran into this problem – trying to use or in a .filter() and realizing quickly that regular Python logic doesn’t play nice there.

The error messages were confusing, and the docs didn’t help much. So let me break it down for you in a simple, practical way.

By the end of this guide, you’ll understand exactly what Q is, how it works, and how it can make your Django queries cleaner, more powerful, and a lot more flexible.

What's Q All About?
How to Use Q in Django
When Should You Use Q?
Mixing Q and Regular Filters
Real-World Example: Filtering Products
Gotchas (Things To Watch Out For)
Frequently Asked Questions
Further Resources
Wrapping Up

What's Q All About?

In Django, the Q object (from django.db.models) lets you build complex queries using OR, AND, and NOT logic – something that’s hard to do using just regular .filter() calls.

Normally, when you use .filter() in Django, it adds AND logic like this:

MyModel.objects.filter(name='Alice', age=30)

This will get all rows where the name is 'Alice' and the age is 30. But what if you want:

Get all rows where name is 'Alice' or age is 30?

You can’t just do this:

MyModel.objects.filter(name='Alice' or age=30)  # ❌ This won't work!

That’s where Q comes in.

How to Use Q in Django

Here’s the basic import:

from django.db.models import Q

Now, you can use Q to create conditions and combine them using the | (OR), & (AND), and ~ (NOT) operators.

Let’s say you have a model like this:

from django.db import models

class Person(models.Model):
    name = models.CharField(max_length=100)
    age = models.IntegerField()
    city = models.CharField(max_length=100)

Example 1: OR Logic

from django.db.models import Q

people = Person.objects.filter(Q(name='Alice') | Q(age=30))

This will return anyone whose name is 'Alice' or whose age is 30. That’s clean and readable, right?

Example 2: AND Logic (Still Useful with Q)

people = Person.objects.filter(Q(name='Alice') & Q(age=30))

This will return people where both conditions are true. Technically, this gives the same result as using:

Person.objects.filter(name='Alice', age=30)

So why bother with Q here?

The real power of Q with AND is when you start nesting more complex conditions. For instance, suppose you want to find people who are named Alice and either live in Paris or are under 25. Here’s how you could write that:

people = Person.objects.filter(
    Q(name='Alice') & (Q(city='Paris') | Q(age__lt=25))
)

Without Q, this logic would be hard (and messy) to express. Q lets you group conditions logically and write flexible, readable queries.

Example 3: NOT Logic

What if you want everyone except people named Alice?

people = Person.objects.filter(~Q(name='Alice'))

The ~ operator flips the condition – it's saying “not this”.

When Should You Use Q?

You can reach for Q when:

You need OR conditions
You want to combine filters dynamically (for example, building a query based on user input)
You need to write complex conditional logic
You want to exclude certain things using ~Q(...)

But are there times you shouldn't use Q?

Yes – if you're writing a straightforward filter with only AND logic (like name='Alice' and age=30), using Q doesn't add much value. It can make your code unnecessarily verbose. Stick with plain .filter() unless you need more flexibility.

Mixing Q and Regular Filters

You can mix Q objects with normal keyword arguments in a filter. Just be careful with parentheses and order.

Person.objects.filter(Q(name='Alice') | Q(city='Paris'), age__gte=25)

This translates to:

(name = 'Alice' OR city = 'Paris') AND age >= 25

But here’s where parentheses make a big difference.

Take this incorrect example:

Person.objects.filter(Q(name='Alice') | Q(city='Paris') & Q(age__gte=25))

Due to operator precedence, this will evaluate as:

name = 'Alice' OR (city = 'Paris' AND age >= 25)

Which is not what you probably intended!

So when in doubt, use parentheses to clearly define your logic:

# Correct: (name = 'Alice' OR city = 'Paris') AND age >= 25
Person.objects.filter((Q(name='Alice') | Q(city='Paris')) & Q(age__gte=25))

Real-World Example: Filtering Products

Say you’ve got a Product model with price, in_stock, and category.

You want all products that are either:

cheaper than $20 and in stock
or
In the 'Books' category

Here’s how that might look:

Product.objects.filter(
    (Q(price__lt=20) & Q(in_stock=True)) | Q(category='Books')
)

Without QYou’d have to write separate queries and merge them, or use more complicated logic. This way is faster and more efficient.

Things to Watch Out For

Use parentheses: Just like in math, they control how things combine. Don’t trust default operator precedence unless you know it well.
Don’t use or/and keywords: Python’s logical operators don’t work with Django ORM queries. Use | and & instead.
Mixing Q with .exclude()? Be extra careful. Why? Because .exclude() inverts the logic of the entire filter. That means if you write:
```
  Person.objects.exclude(Q(name='Alice') & Q(city='Paris'))
```
It’s saying: Exclude anyone who is named Alice and lives in Paris.

But what if you wrote:
```
  Person.objects.exclude(Q(name='Alice') | Q(city='Paris'))
```
Now it excludes anyone named Alice or who lives in Paris – a much broader exclusion! So always double-check what you're excluding.
You might need to invert specific parts of your logic using ~Q(...) before passing them to .exclude() Rather than excluding the whole expression.

Frequently Asked Questions

Is using Q slower than a regular `filter()`?

Nope! Under the hood, Django converts your query into optimized SQL. Whether you use filter(name='Alice') or filter(Q(name='Alice'))Performance is almost the same. What matters more is how complex your query is.

Can I use Q with `annotate()` or `aggregate()`?

Yep. You can use Q with annotate() to apply conditional logic for things like counting or filtering within annotations.

from django.db.models import Count

# Count users with more than one blog post
User.objects.annotate(
    post_count=Count('posts', filter=Q(posts__published=True))
)

Can I build Q objects dynamically?

Absolutely. That’s one of the best parts! You can build up a list of Q() objects and combine them however you want:

filters = Q()
if search_name:
    filters |= Q(name__icontains=search_name)
if search_city:
    filters |= Q(city__icontains=search_city)

results = Person.objects.filter(filters)

This is especially useful for search forms or APIS where users can pass different combinations of filters.

Wrapping Up

So that’s Q In Django. It’s not some scary, abstract concept – it’s just a powerful way to control how your queries behave.

Once you get used to using Q, your code becomes cleaner, easier to read, and more flexible when handling complex filters.

Honestly, I can’t imagine writing Django queries without it anymore.

Further Resources

Want to go deeper?

Django Q Object Official Docs
Real Python's Guide to Q Objects
Django ORM Cookbook – solid practical examples

How to Change the Password of a Superuser in Django

Udemezue John — Wed, 23 Apr 2025 13:59:23 +0000

Changing a superuser password in Django might sound like a big task, but it’s one of the easiest things to do once you know how.

If you’re working on a Django project – whether it’s a hobby blog, a client’s website, or a bigger web application – managing your admin accounts safely is a must.

And one key part of that? Making sure your superuser password is strong, secure, and easy for you to update.

You might be doing this because you forgot the old password, you're handing the project off to someone else, or you're tightening security after a team change.

Whatever your reason is, this guide will walk you through the easiest and safest ways to change a superuser password in Django.

I’ll break everything down in simple language, no heavy tech lingo or assumptions.

Let’s dive in.

What we’ll cover:

Why Changing the Superuser Password Matters
3 Simple Ways to Change a Django Superuser Password
Bonus: Forgot Your Superuser Username?
FAQs
Final Thoughts
Further Reading and Tools

Why Changing the Superuser Password Matters

Your Django superuser has full access to the admin dashboard. This means they can add or delete users, edit data, manage settings – everything. If that account gets compromised, the whole site is at risk.

Here’s what could go wrong if the password is weak or outdated:

Someone could delete your database.
A hacker could inject malicious data.
Private user info could be exposed.

According to Verizon’s Data Breach Investigations Report, over 80% of hacking-related breaches are due to compromised or weak passwords. That’s a huge risk for something that’s easy to fix in a few minutes.

So let’s make sure your Django admin is locked down tight – without breaking anything.

3 Simple Ways to Change a Django Superuser Password

I’ll show you three different ways to update your superuser password. You only need to pick one that fits your current setup.

Method 1: Use Django’s Built-In Command

If you have access to the command line and your project’s virtual environment, this is the cleanest way.

Activate your virtual environment

This depends on your setup, but if you're using venv it might look like this:

source venv/bin/activate

Or on Windows:

venv\Scripts\activate

Navigate to your project folder

This is where manage.py lives:

cd your_project_folder

Run the following command:

python manage.py changepassword your_superuser_username

Example:

python manage.py changepassword admin

Django will then ask you to enter a new password. Type it in, hit enter, confirm it again, and you’re done.

That’s it. You just changed your superuser password!

Method 2: Use the Django Shell

Maybe you don’t remember the username or want more control. The Django shell lets you interact directly with your database using Python.

Here’s how:

First, open the shell:

python manage.py shell

Then run the following code:

from django.contrib.auth import get_user_model

User = get_user_model()

user = User.objects.get(username="admin")  # Replace 'admin' with your username
user.set_password("new_secure_password")   # Replace with your new password
user.save()

Now exit the shell:

exit()

That’s it. This method is especially helpful if you’re working in a staging environment or doing things programmatically.

Method 3: Use Django Admin (If You’re Logged In)

This one only works if you can still log in with the current superuser account.

Go to your Django admin page, usually at http://127.0.0.1:8000/admin/.
Log in with your current credentials.
Click on Users.
Find your superuser account and click on it.
Scroll down to the “Password” section and click "this form" under the "Raw passwords are not stored..." message.
Enter your new password twice and save.

This method is super quick and doesn’t require any code at all.

Bonus: Forgot Your Superuser Username?

If you don’t remember the exact username of your superuser, no worries. You can list all users like this:

python manage.py shell

Then:

from django.contrib.auth import get_user_model

User = get_user_model()

for user in User.objects.all():
    print(user.username)

This will print out all usernames in your system, including your superuser.

FAQs

What if I forgot both the username and password?

Use the shell method above to list all usernames, then reset it using either the shell or the changepassword command.

Will this log out other users?

Changing your superuser password won’t affect other users unless you have custom logic tied to sessions. For most projects, everything else keeps running just fine.

Can I change the password from the database directly?

Technically yes, but don’t do it. Passwords in Django are hashed using PBKDF2 by default. If you enter something manually in the database, it won’t work unless it's hashed the right way. Always use the Django shell or admin panel instead.

How do I know if my new password is secure?

Django checks password strength by default. But if you want to be extra safe, use a tool like Bitwarden Password Generator or 1Password’s Generator.

Final Thoughts

That’s pretty much everything you need to know to change your superuser password in Django. It’s quick, safe, and once you’ve done it once, it’ll be second nature.

It’s small actions like this that go a long way in keeping your Django projects secure. And since it only takes a minute or two, there’s no reason to put it off.

Let’s keep the conversation going, Connect with me on x.com/_udemezue

How to Use a Foreign Key in Django

Udemezue John — Tue, 22 Apr 2025 14:05:27 +0000

When you're building something in Django – whether it's a blog, a to-do app, or even something way more complex – at some point, you'll want to connect different pieces of data.

That’s where ForeignKey comes in. It helps link one model to another, like tying a comment to a post, or an order to a customer.

It’s one of those things in Django that can seem confusing at first, but once it clicks, you’ll wonder how you ever built apps without it.

So let’s break it all down. I’ll walk you through everything from what a ForeignKey is, to how to use it in your Django project.

Here’s what we’ll cover:

What is a Foreign Key in Django?
Why Use a ForeignKey Instead of Storing IDs Manually?
Real-World Example: Blog Posts and Comments
What is on_delete and Why Does It Matter?
How to Access Related Objects in Django
How to Create Foreign Key Relationships in Django Admin
- What Happens in the Database?
How to Query with ForeignKey
- Get all comments for a post with id=1:
- Get all posts that have at least one comment by a specific user:
FAQs
Final Thoughts
- Further Resources

What is a Foreign Key in Django?

In the simplest terms, a Foreign Key in Django creates a many-to-one relationship between two models. This means many rows in one table can be related to a single row in another.

For example:

One blog post can have many comments
One customer can have many orders
One author can write many books

If you're coming from a spreadsheet background, think of it like linking two sheets using a shared column. In Django, you do this in your model definitions.

Why Use a ForeignKey Instead of Storing IDs Manually?

You might be wondering, “Why not just store the ID of the related object in a plain integer field?”

Well, you could – but you'd lose a ton of power. Without a ForeignKey:

You don’t get automatic validation that the related object exists.
You can't follow relationships easily in queries (for example, post.comments.all() wouldn’t be possible).
The Django admin can’t provide dropdowns or inline forms for related data.
You lose out on helpful features like on_delete behaviour and related object naming.

ForeignKey fields automate and enforce these relationships, making your code cleaner, more secure, and easier to maintain.

Real-World Example: Blog Posts and Comments

Let’s say you’re building a blog. You’ll probably have a Post model and a Comment model. Each comment needs to be linked to a specific post.

Here’s how that looks in code:

from django.db import models

class Post(models.Model):
    title = models.CharField(max_length=200)
    content = models.TextField()
    published_at = models.DateTimeField(auto_now_add=True)

    def __str__(self):
        return self.title

class Comment(models.Model):
    post = models.ForeignKey(Post, on_delete=models.CASCADE)
    author = models.CharField(max_length=100)
    text = models.TextField()
    created_at = models.DateTimeField(auto_now_add=True)

    def __str__(self):
        return f'Comment by {self.author}'

Let me explain each part of that:

models.ForeignKey(Post, on_delete=models.CASCADE): This line creates the connection. It means each comment is linked to one post. The on_delete=models.CASCADE part tells Django to delete all related comments if a post is deleted.
__str__ methods just make it easier to read things in the admin or shell.

What is `on_delete` and Why Does It Matter?

When you create a ForeignKey in Django, you have to include an on_delete argument. This controls what happens to the child rows (like comments) if the parent row (like a blog post) is deleted.

Here are the common options:

models.CASCADE: Delete the child rows, too (like deleting all comments when a post is deleted).
models.PROTECT: Prevent deletion if there are related objects.
models.SET_NULL: Set the ForeignKey to NULL instead of deleting.
models.SET_DEFAULT: Set a default value.
models.DO_NOTHING: Do nothing (not recommended unless you really know what you're doing).

I usually go with CASCADE for simple apps, but it's worth thinking through depending on the situation.

Once you’ve set up the ForeignKey, Django gives you a few nice tools to work with related data.

For example, let’s say you have a post object:

post = Post.objects.get(id=1)

You can get all comments for that post like this:

comments = post.comment_set.all()

The comment_set is automatically created by Django, and you can customize the name with related_name:

class Comment(models.Model):
    post = models.ForeignKey(Post, on_delete=models.CASCADE, related_name='comments')

Now you can do:

post.comments.all()

Much cleaner, right?

How to Create Foreign Key Relationships in Django Admin

The Django admin handles ForeignKeys well. If you’ve got both Post and Comment models registered in admin.py, you’ll get a dropdown in the comment form to select the post it belongs to.

You can also make inline forms, so you can add comments while editing a post. Here’s a quick example:

from django.contrib import admin
from .models import Post, Comment

class CommentInline(admin.TabularInline):
    model = Comment
    extra = 1

class PostAdmin(admin.ModelAdmin):
    inlines = [CommentInline]

admin.site.register(Post, PostAdmin)
admin.site.register(Comment)

Now when you're editing a post, you can add or edit comments right there on the same page.

What Happens in the Database?

Django uses a relational database (like PostgreSQL, MySQL, or SQLite), and ForeignKey creates a column in the database table that holds the ID of the related object.

If you run python manage.py makemigrations and then python manage.py migrate, Django will create the actual database tables with the proper relationships behind the scenes.

How to Query with ForeignKey

You can also filter or search based on ForeignKey relationships:

Get all comments for a post with id=1:

Comment.objects.filter(post_id=1)

Or, using the post object:

post = Post.objects.get(id=1)
comments = Comment.objects.filter(post=post)

Get all posts that have at least one comment by a specific user:

Post.objects.filter(comments__author='John')

That comments__author part is thanks to the related_name='comments' I added earlier.

FAQs

Can a ForeignKey be optional?

Yes, just add null=True, blank=True like this:

post = models.ForeignKey(Post, on_delete=models.SET_NULL, null=True, blank=True)

You might want this if the related object isn't always required. For example, a Comment might optionally belong to a Post, or a Task might optionally have a related Project. It’s useful when building drafts, soft deletes, or handling legacy data.

Can a ForeignKey point to the same model (self)?

Absolutely. That’s called a self-referential ForeignKey, often used for things like threaded comments or categories.

class Category(models.Model):
    name = models.CharField(max_length=100)
    parent = models.ForeignKey('self', null=True, blank=True, on_delete=models.SET_NULL)

Can a model have more than one ForeignKey?

Totally. For example, an Order model could have one ForeignKey to a Customer, and another to a ShippingAddress.

Final Thoughts

If you’re building anything in Django that deals with more than one model, understanding ForeignKey is essential. It makes your app more structured, easier to query, and way more powerful.

At first, it might feel like a lot, but once you build one or two relationships and see it all working in the admin and your views, it clicks.

And if something’s still unclear, that’s normal. I had to build a few mini-projects before it started to feel natural.

Django - freeCodeCamp.org

How to Build a Scoped Note-Taking API with Django Rest Framework and SimpleJWT

What We'll Cover:

Prerequisities

What is JWT and Why Use It Over Session Authentication?

How Session Authentication Work

How JWT Authentication Works

Step 1: How to Set Up the Project and Install the Dependecies

1.1 How to Create the Project

1.2 How to Create a Virtual Environment and Install the Required Dependencies

1.3 How to Create the Project and the App

1.4 How to Register the App and Django Rest Framework (DRF)

Step 2: How to Create a Custom User Model

2.1 How to Define the Custom User Model

2.2 How to Tell Django to Use Your Custom User Model

2.3 How to Run Migrations

Step 3: How to Define the Note Model

3.2 How to Apply Migration

3.3 How to Register Models in the Admin

Step 4: How to Create the Serializer

4.1 How to Create UserSerializer

4.2 How to Create NoteSerializer

Step 5: How to Configure SimpleJWT

5.1 How to Update REST Framework Settings

5.2 How to Add Token URL Endpoints

Step 6: How to Build the Authentication Logic

Step 7: How to Implement Scoped Views

7.1 How to Create a NoteViewSet

7.2 Why This Matters: Preventing ID Enumeration Attacks

Step 8: How to Connect a URL

8.1 How to Create App-level URLs

8.2 How to Verify the Project-Level URLs

Step 9: How to Test the APIs with Postman

9.1 How to Register a User

9.2 How to Obtain Access and Refresh Tokens

9.3 How to Create a Note

9.4 How to List Your Notes

9.5 How to Demonstrate Scoping

Step 10: How to Handle Token Expiration with Refresh Tokens

How You Can Improve This Project

Conclusion

How to Build and Deploy a Fitness Tracker Using Python Django and PythonAnywhere - A Beginner Friendly Guide

Table of Contents

Prerequisites

What You Are Going Build

Step 1: How to Set Up Your Django Project

1. 1 How to Create a Virtual Environment

1.2 How to Install Django

1.3 How to Create the Project

1.4 How to Run the Development Server

Step 2: How to Create a Django App

2.1 How to Generate the App

2.2 How to Register the App

Step 3: How to Create a Workout Model

3.1 How to Define the Model

Step 4: How to Apply Migrations

4.1 How to Generate the Migration

4.2 How to Apply the Migration

Step 5: How to Register the Model in the Admin Panel

5.1 How to Add Model to Admin

5.2 How to Create a Superuser

5.3 How to Access the Admin Panel

Step 6: How to Create Views for the App

6.1 How to Create a Form Class

6.2 How to Write Views

Step 7: How to Create Templates

7.1 How to Set Up the Template Directory

7.2 How to Create the Workout List Template

My Workouts

My Workouts

7.3 How to Create Add Workout Template

Log a Workout

Step 8: How to Connect URLs

8.1 How to Create App Level URLs

8.2 How to Link App URLs to project

Step 9: How to Test the Application Locally

Step 10: How to Prepare for Deployment

10.1 How to Update Settings for Production

Step 11: How to Deploy Your Django App on PythonAnywhere

11.1 How to Create a PythonAnywhere Account

Solving the Problem with `select_related` and `prefetch_related`