DEV Community: M Saad Ahmad

Day 79 of #100DaysOfCode — Flask Routes, Requests, and Responses

M Saad Ahmad — Wed, 22 Apr 2026 05:43:05 +0000

Yesterday, I got Flask running and understood the basic structure. Today, on day 79, I delved deeper into the three things at the core of every Flask application: routes, the request object, and responses. This is the layer where every HTTP interaction happens, and getting comfortable here makes everything else in Flask easier.

Routes in Depth

The `url_for` Function

Hardcoding URLs in templates and redirects is a bad habit. If you rename a route, every hardcoded URL breaks. Flask's url_for generates URLs by function name instead:

from flask import Flask, url_for

app = Flask(__name__)

@app.route('/')
def home():
    return 'Home'

@app.route('/profile/<username>')
def profile(username):
    return f'Profile: {username}'

with app.test_request_context():
    print(url_for('home'))                    # /
    print(url_for('profile', username='haris'))  # /profile/haris

In Django this was {% url 'view_name' %} in templates and reverse() in Python code. Flask's equivalent is url_for() in both places. Same concept, different name.

Route Converters

Flask supports several built-in type converters for URL variables:

@app.route('/post/<int:id>')       # integer
def post(id):
    return f'Post {id}'

@app.route('/price/<float:amount>')  # float
def price(amount):
    return f'Price: {amount}'

@app.route('/files/<path:filepath>')  # path — allows slashes
def files(filepath):
    return f'File: {filepath}'

@app.route('/user/<uuid:user_id>')   # UUID
def user(user_id):
    return f'User: {user_id}'

The path converter is unique, unlike string, which stops at slashes; path captures everything, including slashes. Useful for file path URLs.

Trailing Slashes

Flask has an opinion about trailing slashes:

@app.route('/about/')   # with trailing slash
def about():
    return 'About'

If you define a route with a trailing slash and someone visits without it, Flask redirects them automatically. If you define without a trailing slash and someone visits with it, Flask returns a 404. Be intentional about what you use.

HTTP Methods

from flask import Flask, request

app = Flask(__name__)

@app.route('/login', methods=['GET', 'POST'])
def login():
    if request.method == 'POST':
        return 'Processing login'
    return 'Show login form'

You can also separate methods into different functions using add_url_rule:

@app.get('/items')
def get_items():
    return 'List items'

@app.post('/items')
def create_item():
    return 'Create item'

@app.get() and @app.post() are shorthand decorators added in Flask 2.0. Cleaner than methods=['GET'] when you want to keep handlers separate.

The Request Object

The request object is Flask's way of giving you everything about the incoming HTTP request. Import it from Flask, and it's available inside any route function.

from flask import Flask, request

app = Flask(__name__)

Unlike Django, where request is passed as a parameter to every view function, Flask's request is a context variable; you import it once and use it anywhere inside a request context. This is one of Flask's more distinctive patterns.

Query Parameters

@app.route('/search')
def search():
    keyword = request.args.get('keyword', '')
    location = request.args.get('location', '')
    return f'Searching for {keyword} in {location}'

request.args is a dictionary of query string parameters: the stuff after ? in the URL. request.args.get('key', default) works exactly like a Python dict's .get(). In Django, this was request.GET.get('keyword').

Form Data

@app.route('/submit', methods=['POST'])
def submit():
    name = request.form.get('name')
    email = request.form.get('email')
    return f'Received: {name}, {email}'

request.form contains POST data from HTML forms. In Django, this was request.POST.get('name').

JSON Data

@app.route('/api/data', methods=['POST'])
def receive_data():
    data = request.get_json()
    name = data.get('name')
    return f'Received JSON: {name}'

request.get_json() parses the request body as JSON and returns a Python dictionary. This is what API clients send when they POST JSON instead of form data.

File Uploads

@app.route('/upload', methods=['POST'])
def upload():
    file = request.files.get('avatar')
    if file:
        file.save(f'uploads/{file.filename}')
        return 'File uploaded'
    return 'No file received'

request.files contains uploaded files. Call .save() to write the file to disk.

Request Headers and Cookies

@app.route('/info')
def info():
    user_agent = request.headers.get('User-Agent')
    token = request.headers.get('Authorization')
    session_id = request.cookies.get('session_id')
    return f'Agent: {user_agent}'

request.headers — all HTTP headers as a dictionary.
request.cookies — all cookies sent with the request.

Useful Request Properties

@app.route('/details')
def details():
    print(request.method)       # GET, POST, PUT, etc.
    print(request.url)          # full URL including query string
    print(request.base_url)     # URL without query string
    print(request.path)         # path only, e.g. /details
    print(request.host)         # hostname, e.g. 127.0.0.1:5000
    print(request.is_json)      # True if Content-Type is application/json
    print(request.remote_addr)  # client IP address
    return 'Check the console'

Responses in Depth

Return a String

The simplest response: Flask wraps it in a 200 OK response automatically:

@app.route('/')
def home():
    return 'Hello'

Return with a Status Code

@app.route('/not-found')
def not_found():
    return 'Page not found', 404

@app.route('/created')
def created():
    return 'Resource created', 201

A tuple of (body, status_code), clean and readable.

Return with Headers

@app.route('/download')
def download():
    return 'file content', 200, {
        'Content-Disposition': 'attachment; filename=file.txt',
        'Content-Type': 'text/plain'
    }

A tuple of (body, status_code, headers_dict).

make_response

When you need more control:

from flask import make_response

@app.route('/custom')
def custom():
    response = make_response('Custom response', 200)
    response.headers['X-Custom'] = 'value'
    response.set_cookie('user', 'haris')
    return response

make_response gives you a proper response object to manipulate before returning.

Redirects

from flask import redirect, url_for

@app.route('/old-page')
def old_page():
    return redirect(url_for('home'))

@app.route('/external')
def external():
    return redirect('https://google.com')

redirect() combined with url_for() is the Flask equivalent of Django's redirect('view_name').

JSON Responses

from flask import jsonify

@app.route('/api/user')
def api_user():
    user = {
        'id': 1,
        'username': 'haris',
        'role': 'developer'
    }
    return jsonify(user)

jsonify converts a Python dictionary to a JSON response with the correct Content-Type: application/json header set automatically.

Abort — Early Exit with an Error

from flask import abort

@app.route('/admin')
def admin():
    if not is_admin():
        abort(403)
    return 'Admin panel'

abort() immediately stops processing and returns an error response. 403 for forbidden, 404 for not found, 500 for server error. In Django you used get_object_or_404() which does something similar under the hood.

Error Handlers

Flask lets you register custom handlers for HTTP errors:

@app.errorhandler(404)
def page_not_found(error):
    return 'Custom 404 page', 404

@app.errorhandler(403)
def forbidden(error):
    return 'You do not have permission', 403

@app.errorhandler(500)
def server_error(error):
    return 'Something went wrong', 500

These catch errors across the entire app. In Django, this was done with custom 404.html and 500.html template files. Flask gives you full control via Python functions.

Before and After Request Hooks

Flask lets you run code before or after every request:

@app.before_request
def before():
    print(f'Request incoming: {request.path}')

@app.after_request
def after(response):
    response.headers['X-Frame-Options'] = 'DENY'
    return response

@app.teardown_request
def teardown(error=None):
    # runs after request regardless of exceptions
    pass

@app.before_request — runs before the view function. Useful for authentication checks and logging.
@app.after_request — runs after the view, receives the response object. Useful for adding headers.
@app.teardown_request — runs at the end regardless of whether an exception occurred. Useful for cleanup, like closing database connections.

In Django, this was middleware. Flask's hooks are simpler for basic cases, though Blueprints (day 84) have their own version of these hooks too.

Putting It Together — A Small Example

from flask import Flask, request, jsonify, redirect, url_for, abort

app = Flask(__name__)

users = {'haris': {'role': 'developer', 'location': 'Karachi'}}

@app.route('/users')
def list_users():
    return jsonify(list(users.keys()))

@app.route('/users/<username>')
def get_user(username):
    user = users.get(username)
    if not user:
        abort(404)
    return jsonify({'username': username, **user})

@app.route('/users', methods=['POST'])
def create_user():
    data = request.get_json()
    if not data or 'username' not in data:
        return jsonify({'error': 'username required'}), 400
    users[data['username']] = {'role': data.get('role', ''), 'location': data.get('location', '')}
    return jsonify({'created': data['username']}), 201

@app.errorhandler(404)
def not_found(e):
    return jsonify({'error': 'not found'}), 404

if __name__ == '__main__':
    app.run(debug=True)

A small in-memory API with list, detail, create, and a custom error handler, using everything from today in one place.

Wrapping Up

Routes, requests, and responses are the complete picture of how Flask handles HTTP. Everything else: templates, databases, auth, sits on top of this foundation. The patterns here are identical to Django conceptually, just lighter and more explicit.

Thanks for reading. Feel free to share your thoughts!

Day 78 of #100DaysOfCode — Introduction to Flask: Setup and First App

M Saad Ahmad — Tue, 21 Apr 2026 04:33:52 +0000

Django learning is done, DevBoard is still being finished in parallel, and today, for Day 78, Flask starts. Flask has a reputation for being the opposite of Django in almost every way; where Django gives you everything, Flask gives you almost nothing and lets you choose. Today I set it up, understood what makes it different, and got a first app running.

Flask vs Django — The Key Difference

Before writing a single line of Flask, it's worth understanding the philosophy difference because it changes how you think about everything.

Django is batteries included. You get an ORM, an admin panel, authentication, form handling, and a templating engine, all built in and all opinionated about how you should use them. You work within Django's structure.

Flask is a microframework. You get routing, a templating engine, and a development server. That's essentially it. No ORM, no admin panel, no built-in auth. You pick the tools you want and wire them together yourself.

Neither is better. They're built for different mindsets. Django is faster to get a standard app running. Flask gives you more control and is easier to keep lightweight.

Setup

mkdir flask-app
cd flask-app
python -m venv env
source env/bin/activate
pip install flask

That's the entire installation. Compare that to Django, where you also install djangorestframework, dj-database-url, python-decouple, Pillow before even starting. Flask starts with one package.

The Simplest Flask App

Create app.py:

from flask import Flask

app = Flask(__name__)

@app.route('/')
def home():
    return 'Hello from Flask!'

if __name__ == '__main__':
    app.run(debug=True)

Run it:

python app.py

Visit http://127.0.0.1:5000/ — you see "Hello from Flask!"

That's a complete web application in 8 lines. No project folder, no settings.py, no manage.py, no apps to register. Just a file.

Breaking It Down

app = Flask(__name__)

This creates the Flask application instance. __name__ tells Flask where to look for templates and static files; it uses the location of the current file as the reference point.

@app.route('/')
def home():
    return 'Hello from Flask!'

The @app.route('/') decorator registers the function as the handler for the / URL. The function returns a string, which Flask sends as the HTTP response. In Django, you'd write a view function and separately register it in urls.py. In Flask, the route and the view are defined together in one place.

if __name__ == '__main__':
    app.run(debug=True)

debug=True enables the debugger and auto-reloads the server when you change the code. Never use debug=True in production.

Multiple Routes

from flask import Flask

app = Flask(__name__)

@app.route('/')
def home():
    return 'Home Page'

@app.route('/about')
def about():
    return 'About Page'

@app.route('/contact')
def contact():
    return 'Contact Page'

if __name__ == '__main__':
    app.run(debug=True)

Each route is just a decorator above a function. As clean as it gets.

URL Variables

@app.route('/user/<username>')
def user_profile(username):
    return f'Profile of {username}'

@app.route('/post/<int:post_id>')
def show_post(post_id):
    return f'Post number {post_id}'

<username> captures a string. <int:post_id> captures an integer. Same concept as Django's <str:slug> and <int:pk> URL patterns, just different syntax and defined right on the route instead of in a separate urls.py.

The `flask` CLI

Flask also has a command line interface: an alternative to running python app.py directly:

export FLASK_APP=app.py
export FLASK_DEBUG=1
flask run

Or with the newer approach using environment variables in a .flaskenv file:

pip install python-dotenv

Create .flaskenv:

FLASK_APP=app.py
FLASK_DEBUG=1

Now just run flask run and Flask reads the configuration automatically. This is Flask's equivalent of Django's manage.py runserver.

Returning HTML

So far, we've been returning plain strings. Flask can return HTML directly:

@app.route('/')
def home():
    return '<h1>Hello from Flask</h1><p>This is a paragraph.</p>'

This works, but gets ugly fast. Templates solve this. For now, this shows that Flask's return is just an HTTP response, and you control exactly what goes in it.

HTTP Methods

By default, a route only handles GET requests. To handle POST:

@app.route('/submit', methods=['GET', 'POST'])
def submit():
    if request.method == 'POST':
        return 'Form submitted'
    return 'Show the form'

In Django, we check if request.method == 'POST': inside the view. Flask works the same way, just with the method restriction declared on the route decorator.

The Response Object

Flask lets you control the response in detail:

from flask import Flask, make_response

app = Flask(__name__)

@app.route('/')
def home():
    response = make_response('Hello from Flask', 200)
    response.headers['X-Custom-Header'] = 'value'
    return response

Most of the time, you just return a string or a rendered template, and Flask handles the response automatically. make_response is there when you need explicit control over status codes or headers.

JSON Responses

Flask has a built-in jsonify function for returning JSON:

from flask import Flask, jsonify

app = Flask(__name__)

@app.route('/api/status')
def status():
    return jsonify({
        'status': 'ok',
        'message': 'Flask is running',
        'version': '1.0'
    })

Visit /api/status and you get a properly formatted JSON response with the correct Content-Type header. No DRF needed for simple JSON endpoints; Flask handles it natively.

Flask vs Django Side by Side

Already, some patterns are clear:

Django	Flask
`urls.py` + view function	`@app.route()` decorator on the function
`python manage.py runserver`	`flask run` or `python app.py`
`HttpResponse`	`return` string or `make_response()`
`JsonResponse`	`jsonify()`
`<int:pk>` in URL	`<int:pk>` in route — same syntax
Separate `settings.py`	`app.config` dictionary

The concepts are identical. The syntax and where things live are different.

Wrapping Up

First day of Flask and already the contrast with Django is clear. Flask is genuinely lighter: one file, one import, running in seconds. The tradeoff is that everything Django gave you for free: database, auth, admin, you'll have to add piece by piece. That's what the next few days are for.

Tomorrow: routes deeper, URL building, request object, and handling different HTTP methods properly.

Thanks for reading. Feel free to share your thoughts!

Day 77 of #100DaysOfCode — Building DevBoard: Progress, Lessons, and What's Next

M Saad Ahmad — Mon, 20 Apr 2026 05:12:22 +0000

Honesty time. The plan was to deploy DevBoard today. That's not happening, and I think it's worth writing about why, because what happened this week is more representative of real software development than any clean tutorial ever is.

What Got Built

DevBoard is a developer job board with two sides: employers who post jobs and candidates who apply. Over the past few days, I built the foundation and the complete employer side:

The foundation (Day 73):

Custom user model from scratch using AbstractUser — something that has to be done before the very first migration, or it becomes a nightmare to fix later
Two distinct user roles — employer and candidate — each with their own profile model linked via OneToOneField
Automatic profile creation using Django signals, so the right profile is always created the moment a user registers
Separate registration flows for each role, with role-aware redirects after login
Custom decorators for role-based access control — @employer_required and @candidate_required

The employer dashboard (Day 74):

Job model with full details — title, description, location, job type, experience level, salary range, tech stack, deadline, and active/inactive status
Application model linking candidates to jobs, with a status system — pending, reviewed, accepted, rejected
unique_together constraint preventing duplicate applications at the database level
Employer dashboard showing all listings with application counts using ORM annotations
Full CRUD for job listings — post, edit, delete with a confirmation step
Job applications page where employers can see every applicant and update their status

All of this works. An employer can register, post a job, manage their listings, and review applications.

What's Still Left

The candidate side and the visual layer aren't done yet:

Job listings page with search and filter
Job detail page with the four-state apply button
Application flow for candidates
Candidate dashboard showing application statuses
REST API with DRF
Tailwind CSS styling across all pages
Deployment

What Actually Happened

Day 74's work took two days instead of one. The list of issues I ran into:

Page not found errors everywhere. The jobs app URLs weren't included in the project's main urls.py properly. Simple fix once I found it, but it took longer than it should have to track down.

Wrong pages being shown. URL pattern ordering in Django matters more than I expected. When I had jobs/<int:pk>/ and jobs/post/ defined in the wrong order, Django was interpreting the string "post" as a pk and routing to the wrong view. Moving the static paths above the dynamic ones fixed it.

Logic not working correctly. The employer ownership check, making sure an employer can only edit and delete their own jobs, was passing the wrong value in a couple of places. The view was running but operating on the wrong data.

The signal didn't fire. Profile creation via signals wasn't working because I forgot to import the signals module in apps.py's ready() method. Users were being created with no profile attached, which caused attribute errors everywhere downstream.

None of these were unsolvable problems. All of them were fixed. But each one took time to debug, understand, and fix properly, and that time adds up.

The Real Lesson

I planned this project assuming a roughly linear relationship between features and time. One feature equals roughly one day. That's not how building works.

The first day of any new area: models, signals, URL routing, always takes longer because you're encountering edge cases you haven't seen before. The second day in the same area is much faster because you've already been burned once. Day 74 was the first real day of building in Django without a tutorial holding my hand. Of course, it took longer.

What I should have done differently is plan more buffer into the building days. Learning days are more predictable; you cover a topic, and you're done. Building days depend on what breaks, and something always breaks.

What's Next

Rather than delaying the 100 days of code remaining progress to finish the DevBoard, I'm doing both in parallel from tomorrow.

DevBoard will get completed at a slower pace, alongside the 100 days of code, a few hours here and there until it's done. I'm estimating about a week to finish the candidate side, API, styling, and deployment. When it's fully live, I'll write a post about it.

What I'd Recommend

Build the foundation first and don't rush it. The custom user model decision, the role system, the signal wiring: these are the things that would have been painful to undo mid-project. Getting them right on day one meant every day after had a solid base to build on.

Expect debugging to take as much time as building your code. While AI LLM models can easily generate code these days, debugging and ensuring it functions correctly is a significant task on its own. When you encounter an issue, take a moment to slow down. Carefully read the entire error message. Check the URL patterns, examine the imports, and ensure that signals are correctly wired up. Most errors in Django come with clear messages once you know where to look.

And don't treat a plan as a contract. The plan exists to give direction. When reality diverges from the plan, and it will, adjust the plan; don't pretend the divergence didn't happen.

Thanks for reading. Feel free to share your thoughts!

Day 76 of #100DayOfCode — Building DevBoard: REST API and UI Polish

M Saad Ahmad — Sun, 19 Apr 2026 08:15:26 +0000

Yesterday, DevBoard became a complete two-sided platform. Today I added two things that take it from a functional app to a portfolio-ready one: a REST API built with DRF, so the data is accessible programmatically, and UI polish using Tailwind CSS, so it actually looks like something you'd want to show someone.

The REST API

DevBoard's HTML interface works great for browser users. But job board data is also useful to external clients: a mobile app, a browser extension, a third-party aggregator. That's what the API is for. I kept the API focused on the most useful resource: job listings.

What the API Exposes

I made a deliberate decision to keep the API read-only for public consumers and write-enabled only for authenticated employers. The reasoning is straightforward: anyone should be able to fetch job listings programmatically, but only authenticated employers should be able to create or modify them through the API. This mirrors the permissions on the HTML side exactly.

The API exposes three endpoints:

GET /api/jobs/ — list all active job listings with full details
GET /api/jobs/<pk>/ — retrieve a single job listing
POST /api/jobs/ — create a job listing (employers only, requires token)

I chose not to expose applications through the API for now. Application data is sensitive; it contains personal information and cover letters, and there's no clear use case for exposing it externally at this stage.

Serializers

Writing the JobSerializer was interesting because of the tech stack field. In the database, it's stored as a comma-separated string, but in the API response, it should be a proper list. That's what any client consuming the API would expect. DRF's SerializerMethodField handled this cleanly. I added a method that calls the model's existing get_tech_stack_list() helper and returns the result. The database stores a string, the API returns a list, the model method bridges the two.

I also added a company_name field to the serializer that reaches into the related EmployerProfile, again using SerializerMethodField. This means API consumers get the company name directly in the job object without having to make a second request to look up the employer. Fewer requests, better API design.

ViewSet and Router

I used ModelViewSet with a custom get_permissions() method to handle the split between public read access and authenticated write access. The router registered it in two lines. What took twenty lines in the HTML views took four in the API.

The browsable API interface DRF provides out of the box was immediately useful for testing. Visiting /api/ in the browser shows all registered endpoints. Clicking through to /api/jobs/ shows the current job listings as formatted JSON with a form for POST requests right there on the page. No Postman needed during development.

Token Authentication for the API

I wired the existing token authentication from day 71 into the API. Employers who already have a token from registering can use it immediately to create job listings through the API. No separate authentication system to build.

Testing the full flow with Postman confirmed it worked: POST to /api/token/ with employer credentials, receive a token, include it as Authorization: Token <token> in a POST to /api/jobs/, job gets created. The same job immediately appears in the HTML interface too; one database, two interfaces.

UI Polish with Tailwind CSS

The app worked, but looked like raw HTML. I added Tailwind CSS via CDN — one script tag in base.html, and went through every template applying utility classes. No custom CSS file needed.

What Changed Visually

The job listings page went from a plain list to a proper card grid. Each card has a white background, subtle shadow, rounded corners, and a hover state. The tech stack tags became small, rounded badges with a light blue background. The search and filter bar is now a clean horizontal row that sits above the results.

The job detail page got the most attention. The header section has the company name, location, and meta details arranged in a visually clear hierarchy. The tech stack tags match the listing cards. The apply button is prominent — large, full-width on mobile, with a clear visual distinction between the four states: a blue button for candidates who haven't applied, a green badge for accepted, a grey badge for pending, and a red badge for rejected.

The employer dashboard became a proper data table with alternating row colors, clear column headers, and action buttons that look like buttons. The application count links are now visually distinct from plain text.

Navigation in base.html got a dark top bar with the DevBoard logo on the left and user-specific links on the right. Logged-out users see Login and Register buttons. Employers see Dashboard and Post a Job. Candidates see Browse Jobs and My Applications.

Mobile Responsiveness

Tailwind's responsive prefixes made mobile layout straightforward. The job card grid collapses to a single column on small screens. The search form stacks vertically on mobile. The navigation collapses the right-side links. Not a full responsive redesign, but the app is usable on a phone now.

A Few Small Improvements Along the Way

While polishing the UI, I caught a few things worth fixing:

The login page had no redirect handling; after logging in, users always went to the homepage regardless of what they were trying to do before. I added ?next= handling in the login template so candidates who get redirected to login while trying to apply land back on the application page after logging in.

The registration pages now have links to each other: "Already have an account? Login" and "Looking to hire? Post a job instead." Small thing that makes the onboarding feel complete.

The employer dashboard now shows a zero-state message when no jobs have been posted yet, with a prominent link to post the first one. Same on the candidate dashboard for zero applications.

Where DevBoard Stands After Day 76

The app now has three layers working together: an HTML interface for browser users, a REST API for programmatic access, and a consistent visual design that makes it presentable. The data layer underneath serves all three without any duplication.

Thanks for reading. Feel free to share your thoughts!

Day 75 of #100DaysOfCode — Building DevBoard: Job Search and Applications

M Saad Ahmad — Sat, 18 Apr 2026 05:02:53 +0000

Yesterday, employers got their full dashboard. Today, for day 75, I built the candidate side, everything a developer needs to find a job on DevBoard. Browsing listings, searching and filtering by tech stack and location, viewing job details, and submitting an application with a cover letter. By the end of today, the two sides of the platform will be talking to each other in a complete loop.

The Job Listings Page

The first thing I built was the public job listings page: the homepage of DevBoard for anyone who isn't logged in yet. This is the most important page in the app. It needs to show enough information to be useful at a glance without being overwhelming.

Each listing card shows the job title, company name, location, job type, experience level, and the tech stack as individual tags. The tech stack display was satisfying to implement; the get_tech_stack_list() helper method I wrote on the model yesterday paid off here. Looping over the list in the template and rendering each skill as a small tag looks clean and is immediately scannable.

I made a deliberate decision to show the salary range only when both a minimum and a maximum are provided. Partial salary information, just a minimum with no maximum or vice versa, looks incomplete and unprofessional. If an employer didn't fill in both fields, the salary section doesn't render at all. Small decision, better experience.

Search and Filtering

This was the most technically interesting part of today. The search and filter system needed to handle multiple simultaneous filters: keyword search, location, job type, experience level, and combine them cleanly.

The approach I took was building the queryset progressively in the view. Start with all active jobs, then apply each filter only if the corresponding value was submitted. This means a user searching for "Django" in "Karachi" with "Full Time" selected gets all three filters applied at once, while a user who only types a keyword gets just the keyword filter. Each filter is optional, and they stack.

Keyword search uses Django's Q objects, something I hadn't used before today. Q objects let you combine filter conditions with OR logic, which is exactly what keyword search needs. A search for "Python" should match jobs where Python appears in the title, the description, or the tech stack, not just the title. Without Q objects, you'd need separate queries and manual deduplication. With them, it's one clean query.

The filter form stays filled in after submission, and the search inputs show whatever the user typed. This is handled by passing the current filter values back to the template in the context and binding them to the form fields. It sounds obvious, but easy to forget, and it makes the experience feel polished.

Job Detail Page

The job detail page is accessible to everyone, logged in or not. It shows the full job description, all the details, and the tech stack. At the bottom, there's an apply button.

For unauthenticated users, the apply button says "Login to Apply" and links to the login page. For logged-in employers, the button doesn't appear at all; employers don't apply to jobs. For candidates who have already applied, the button is replaced with an "Applied" badge showing their current application status. Only candidates who haven't applied yet see the actual apply button.

Getting these four states right in the template required careful use of {% if %} conditions and passing the right context from the view. The view checks whether the current user has an existing application for this job and passes that information to the template, so the template itself stays clean; it just checks a boolean flag rather than making its own database queries.

The Application Flow

Clicking apply takes the candidate to a simple application form, just a cover letter text area. The job details are shown alongside the form so candidates can reference them while writing.

The view has one important guard: if a candidate tries to apply to the same job twice by manipulating the URL, the unique_together constraint on the Application model catches it at the database level, and the view handles the integrity error gracefully with a message rather than a 500 error.

After submitting, the candidate is redirected back to the job detail page, where they now see the "Applied" badge with a "Pending" status. That immediate feedback matters; the candidate knows their application went through.

Candidate Dashboard

I added a simple candidate dashboard: a page showing all the jobs a candidate has applied to, with the current status of each application. Pending, reviewed, accepted, rejected, the status the employer sets on their side is immediately visible here.

This closed the loop between the two sides of the platform. An employer reviews an application and updates the status. The candidate refreshes their dashboard and sees the update. Two separate interfaces, one shared data layer.

A Problem I Hit

Midway through building the search feature, I ran into an issue with the queryset returning duplicate results. When a search term matched both the title and the tech stack of the same job, that job appeared twice in the results.

The fix was adding .distinct() to the queryset. Django's Q object queries with OR conditions can produce duplicates when they match multiple fields on the same object. .distinct() removes them. Simple fix, but it took me a few minutes to figure out why the same job was showing up twice in the results.

What DevBoard Can Do Now

At the end of day 75, DevBoard is a functioning two-sided platform:

Employers can:

Register with a company profile
Post, edit, and delete job listings
View all applications per listing
Update application status

Candidates can:

Register with skills and experience
Browse all active job listings
Search and filter by keyword, location, job type, and experience level
View full job details
Apply with a cover letter
Track all their applications and statuses

Tomorrow: the REST API with DRF and UI polish before deployment on day 77.

Thanks for reading. Feel free to share your thoughts!

Day 74 of #100DaysOfCode — Building DevBoard: Employer Dashboard

M Saad Ahmad — Fri, 17 Apr 2026 10:49:05 +0000

Yesterday, I built the foundation of the DevBoard project: custom user model, two roles, authentication. Today, for Day 74, I built the employer side of DevBoard. By the end of today, an employer can log in, post a job, manage their listings, and see who has applied. The jobs app went from completely empty to fully functional on the employer side.

Starting with the Job Model

The first thing I did was define the data. Before writing a single view or template, I sat down and thought through what a job listing actually needs. Title, description, location, those are obvious. But a real job board needs more: job type (full-time, part-time, remote), experience level, salary range, tech stack, and an application deadline.

The model ended up with more fields than I initially expected, but every field serves a purpose. The tech stack is stored as a comma-separated string with a helper method to convert it to a list, the same pattern I used for candidate skills yesterday. The is_active flag lets employers pause a listing without deleting it, which felt like an important distinction.

The Application model was equally important to think through carefully. An application links a candidate to a job, carries the cover letter, and has a status: pending, reviewed, accepted, rejected. The status field uses Django's choices system, which means the admin panel and forms automatically get a dropdown instead of a free-text field. Small detail, big difference in usability.

One constraint I added: a candidate can only apply to the same job once. Django's unique_together in the Meta class handles this at the database level, not just in form validation.

The Employer Dashboard

The dashboard is the first thing an employer sees after logging in. I wanted it to be genuinely useful, not just a list of jobs, but a quick overview of what's happening across all their listings.

The view fetches all jobs belonging to the current employer and annotates each one with its application count. Django's ORM annotation system is perfect for this; instead of making a separate query for each job, a single query fetches jobs and counts in one go. This was the most interesting ORM work I've done so far in this project.

The dashboard template shows each job with its title, status, date posted, and how many applications it has received. Active and inactive listings are visually distinguished so employers can immediately see the state of their board.

All employer views are protected with the @employer_required decorator I wrote yesterday. A candidate who somehow lands on an employer URL gets redirected away immediately.

Posting a Job

The job creation form was straightforward to build, but required one decision: should the tech stack be a free text field or a set of checkboxes for predefined technologies? I went with free text for now, comma-separated, same as candidate skills. It's less polished but faster to build and easier to extend later.

The form uses commit=False before saving to attach the current employer as the author of the listing. This is the same pattern from the authentication day: never trust the form to set ownership, always set it in the view.

After a successful post, the employer is redirected back to their dashboard, where the new listing immediately appears. Small detail, but important for the user experience; you want confirmation that the action worked.

Editing and Deleting Jobs

Editing uses the same form as creation, pre-filled with the existing job data. The view includes an ownership check before rendering; if somehow a different employer tries to edit another employer's job by manipulating the URL, they get redirected away. The check is simple: compare job.employer to request.user. If they don't match, redirect.

Deleting follows the same ownership check pattern. I added a confirmation step in the template: a simple "are you sure?" message before the delete form submits. Deleting a job also deletes all applications for it through Django's CASCADE behavior on the ForeignKey, which is exactly the right behavior here.

Viewing Applications

This was the most satisfying part of today. Each job has a detail page accessible only to the employer who posted it, showing all applications received. Each application shows the candidate's name, the date they applied, their cover letter, and the current status.

The employer can update the status of any application; move it from pending to reviewed, or make a decision. This is handled by a small dedicated view that only accepts POST requests and only updates the status field, nothing else. Keeping the update scope narrow felt like the right call.

I also added a link from each application to the candidate's profile so employers can see skills, experience, GitHub, and portfolio without leaving the app.

What the Jobs App Looks Like Now

By the end of today, the jobs app has models, views, forms, URLs, and templates for everything an employer needs. The accounts app and jobs app are now talking to each other; the employer profile set up yesterday connects directly to job listings today.

One thing I noticed while building: the role-based decorator I wrote yesterday made today's views cleaner than expected. Every employer view has one line of protection at the top, then focuses on the actual job. Worth the upfront investment.

Where Things Stand After Day 74

Employers can now:

See a dashboard with all their listings and application counts
Post new jobs with full details
Edit and delete their own listings
View all applications for each job
Update application status

Tomorrow: the candidate side: browsing jobs, searching and filtering, and applying.

Thanks for reading. Feel free to share your thoughts!

Day 73 of 100 Days Of Code — Building DevBoard: Project Setup and Authentication

M Saad Ahmad — Thu, 16 Apr 2026 08:01:24 +0000

Django learning is done. Today I started building a real, portfolio-worthy project called DevBoard, a developer job board where companies post jobs and developers find them. Day 73 was about laying the foundation right: project setup, a custom user model with two distinct roles, and a complete authentication system. Everything that comes after depends on getting this right first.

What is DevBoard?

DevBoard is a job board platform built specifically for developers. Two types of users:

Employers — companies that post job listings and review applications
Candidates — developers who browse listings, search by stack and location, and apply

By the end of day 77, DevBoard will be a fully deployed, working web application with both an HTML interface and a REST API.

Project Setup

python -m venv env
source env/bin/activate
pip install django djangorestframework python-decouple dj-database-url Pillow
django-admin startproject devboard
cd devboard
python manage.py startapp accounts
python manage.py startapp jobs

Two apps:

accounts — handles everything user-related: registration, login, profiles, roles
jobs — handles job listings, applications, and search

Registered both in settings.py:

INSTALLED_APPS = [
    ...
    'rest_framework',
    'rest_framework.authtoken',
    'accounts',
    'jobs',
]

Environment setup right from day one:

# .env
SECRET_KEY=your-secret-key-here
DEBUG=True
DATABASE_URL=sqlite:///db.sqlite3
ALLOWED_HOSTS=localhost,127.0.0.1

# settings.py
from decouple import config, Csv
import dj_database_url

SECRET_KEY = config('SECRET_KEY')
DEBUG = config('DEBUG', cast=bool, default=False)
ALLOWED_HOSTS = config('ALLOWED_HOSTS', cast=Csv())
DATABASES = {'default': dj_database_url.config(default=config('DATABASE_URL'))}

Custom User Model

This is the most important decision in any Django project, and it must be made before the first migration. Django's built-in User model works fine for basic projects, but once you need custom fields like a role, you need a custom user model.

If you start with Django's built-in User and try to swap it out later, it breaks migrations. Always set up a custom user model before running any migrations.

# accounts/models.py
from django.contrib.auth.models import AbstractUser
from django.db import models


class User(AbstractUser):
    EMPLOYER = 'employer'
    CANDIDATE = 'candidate'

    ROLE_CHOICES = [
        (EMPLOYER, 'Employer'),
        (CANDIDATE, 'Candidate'),
    ]

    role = models.CharField(max_length=20, choices=ROLE_CHOICES)
    bio = models.TextField(blank=True)
    avatar = models.ImageField(upload_to='avatars/', blank=True, null=True)
    location = models.CharField(max_length=100, blank=True)

    def is_employer(self):
        return self.role == self.EMPLOYER

    def is_candidate(self):
        return self.role == self.CANDIDATE

    def __str__(self):
        return f"{self.username} ({self.role})"

AbstractUser gives us everything Django's built-in user has: username, password, email, is_staff, is_active, plus the custom fields on top.

Tell Django to use this model instead of the default:

# settings.py
AUTH_USER_MODEL = 'accounts.User'

Now run the first migration:

python manage.py makemigrations
python manage.py migrate

Employer Profile

Employers need a company profile name, website, logo, description. This lives in a separate model linked to the User:

class EmployerProfile(models.Model):
    user = models.OneToOneField(
        User,
        on_delete=models.CASCADE,
        related_name='employer_profile'
    )
    company_name = models.CharField(max_length=200)
    company_website = models.URLField(blank=True)
    company_logo = models.ImageField(upload_to='logos/', blank=True, null=True)
    company_description = models.TextField(blank=True)
    founded_year = models.IntegerField(blank=True, null=True)

    def __str__(self):
        return self.company_name

OneToOneField means one user has exactly one employer profile. related_name='employer_profile' lets you access it as user.employer_profile from anywhere.

Candidate Profile

Candidates have a different profile, tech stack, experience, resume:

class CandidateProfile(models.Model):
    user = models.OneToOneField(
        User,
        on_delete=models.CASCADE,
        related_name='candidate_profile'
    )
    skills = models.TextField(help_text="Comma separated skills")
    experience_years = models.IntegerField(default=0)
    resume = models.FileField(upload_to='resumes/', blank=True, null=True)
    portfolio_url = models.URLField(blank=True)
    github_url = models.URLField(blank=True)
    linkedin_url = models.URLField(blank=True)

    def get_skills_list(self):
        return [skill.strip() for skill in self.skills.split(',')]

    def __str__(self):
        return f"{self.user.username}'s profile"

get_skills_list() is a convenience method that splits a comma-separated list of skills into a Python list, useful for displaying tags in templates.

Auto-Creating Profiles with Signals

When a user registers, the corresponding profile should be created automatically based on their role:

# accounts/signals.py
from django.db.models.signals import post_save
from django.dispatch import receiver
from .models import User, EmployerProfile, CandidateProfile


@receiver(post_save, sender=User)
def create_user_profile(sender, instance, created, **kwargs):
    if created:
        if instance.role == User.EMPLOYER:
            EmployerProfile.objects.create(user=instance)
        elif instance.role == User.CANDIDATE:
            CandidateProfile.objects.create(user=instance)

# accounts/apps.py
from django.apps import AppConfig


class AccountsConfig(AppConfig):
    name = 'accounts'

    def ready(self):
        import accounts.signals

Registration Forms

Two separate registration forms, one for each role:

# accounts/forms.py
from django import forms
from django.contrib.auth.forms import UserCreationForm
from .models import User


class EmployerRegistrationForm(UserCreationForm):
    company_name = forms.CharField(max_length=200)
    company_website = forms.URLField(required=False)

    class Meta:
        model = User
        fields = ['username', 'email', 'password1', 'password2']

    def save(self, commit=True):
        user = super().save(commit=False)
        user.role = User.EMPLOYER
        if commit:
            user.save()
            user.employer_profile.company_name = self.cleaned_data['company_name']
            user.employer_profile.company_website = self.cleaned_data.get('company_website', '')
            user.employer_profile.save()
        return user


class CandidateRegistrationForm(UserCreationForm):
    skills = forms.CharField(
        help_text="Enter your skills separated by commas",
        widget=forms.TextInput(attrs={'placeholder': 'Python, Django, React'})
    )
    experience_years = forms.IntegerField(min_value=0, initial=0)

    class Meta:
        model = User
        fields = ['username', 'email', 'password1', 'password2']

    def save(self, commit=True):
        user = super().save(commit=False)
        user.role = User.CANDIDATE
        if commit:
            user.save()
            user.candidate_profile.skills = self.cleaned_data['skills']
            user.candidate_profile.experience_years = self.cleaned_data['experience_years']
            user.candidate_profile.save()
        return user

Both forms set role automatically on save; the user never selects it manually. Role is determined by which registration page they use.

Registration Views

# accounts/views.py
from django.shortcuts import render, redirect
from django.contrib.auth import login
from django.contrib.auth.decorators import login_required
from .forms import EmployerRegistrationForm, CandidateRegistrationForm


def register_employer(request):
    if request.method == 'POST':
        form = EmployerRegistrationForm(request.POST)
        if form.is_valid():
            user = form.save()
            login(request, user)
            return redirect('employer_dashboard')
    else:
        form = EmployerRegistrationForm()
    return render(request, 'accounts/register_employer.html', {'form': form})


def register_candidate(request):
    if request.method == 'POST':
        form = CandidateRegistrationForm(request.POST)
        if form.is_valid():
            user = form.save()
            login(request, user)
            return redirect('job_list')
    else:
        form = CandidateRegistrationForm()
    return render(request, 'accounts/register_candidate.html', {'form': form})

After registration, employers go to their dashboard; candidates go to the job listings. The redirect is role-aware.

Role-Based Access Decorators

Instead of checking request.user.role in every view manually, custom decorators keep things clean:

# accounts/decorators.py
from django.shortcuts import redirect
from functools import wraps


def employer_required(view_func):
    @wraps(view_func)
    def wrapper(request, *args, **kwargs):
        if not request.user.is_authenticated:
            return redirect('login')
        if not request.user.is_employer():
            return redirect('job_list')
        return view_func(request, *args, **kwargs)
    return wrapper


def candidate_required(view_func):
    @wraps(view_func)
    def wrapper(request, *args, **kwargs):
        if not request.user.is_authenticated:
            return redirect('login')
        if not request.user.is_candidate():
            return redirect('job_list')
        return view_func(request, *args, **kwargs)
    return wrapper

Usage:

@employer_required
def post_job(request):
    ...

@candidate_required
def apply_for_job(request, pk):
    ...

URL Configuration

# accounts/urls.py
from django.urls import path
from django.contrib.auth import views as auth_views
from . import views

urlpatterns = [
    path('register/employer/', views.register_employer, name='register_employer'),
    path('register/candidate/', views.register_candidate, name='register_candidate'),
    path('login/', auth_views.LoginView.as_view(template_name='accounts/login.html'), name='login'),
    path('logout/', auth_views.LogoutView.as_view(), name='logout'),
]

# devboard/urls.py
from django.contrib import admin
from django.urls import path, include
from django.conf import settings
from django.conf.urls.static import static

urlpatterns = [
    path('admin/', admin.site.urls),
    path('accounts/', include('accounts.urls')),
    path('', include('jobs.urls')),
] + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

Admin Setup

# accounts/admin.py
from django.contrib import admin
from django.contrib.auth.admin import UserAdmin
from .models import User, EmployerProfile, CandidateProfile


@admin.register(User)
class CustomUserAdmin(UserAdmin):
    list_display = ['username', 'email', 'role', 'is_active']
    list_filter = ['role', 'is_active']
    fieldsets = UserAdmin.fieldsets + (
        ('Role & Profile', {'fields': ('role', 'bio', 'avatar', 'location')}),
    )


admin.site.register(EmployerProfile)
admin.site.register(CandidateProfile)

Where Things Stand After Day 73

The foundation is solid:

Custom user model with employer and candidate roles
Automatic profile creation on registration via signals
Separate registration flows for each role
Role-based decorators for protecting views
Environment variables configured from day one
Admin panel set up to manage users

Tomorrow: the employer side: posting jobs, managing listings, and viewing applications.

Day 72 of 100 Days Of Code — Static Files, Media Files, and Environment Variables in Django

M Saad Ahmad — Wed, 15 Apr 2026 03:57:36 +0000

Yesterday, the API was fully secured with token authentication. Today, for Day 72, I covered the practical side of Django that nobody talks about much, but every real project needs static files, media files, and environment variables. These aren't glamorous topics, but skipping them means your project isn't ready for deployment.

Static Files

Static files are files that don't change: CSS, JavaScript, and images that are part of your design. They're called "static" because they're served as-is, no processing involved.

Configuration

In settings.py:

STATIC_URL = '/static/'

STATICFILES_DIRS = [
    BASE_DIR / 'static',
]

STATIC_ROOT = BASE_DIR / 'staticfiles'

STATIC_URL — the URL prefix for static files in the browser
STATICFILES_DIRS — where Django looks for static files during development
STATIC_ROOT — where Django collects all static files for production

Folder Structure

Create a static folder at the project root:

mysite/
    static/
        css/
            style.css
        js/
            main.js
        images/
            logo.png
    core/
    mysite/
    manage.py

You can also keep static files inside each app:

core/
    static/
        core/
            css/
                style.css

The app-level folder follows the same namespacing pattern as templates; the inner core/ folder prevents naming conflicts between apps.

Using Static Files in Templates

{% load static %}

<!DOCTYPE html>
<html>
<head>
    <link rel="stylesheet" href="{% static 'css/style.css' %}">
</head>
<body>
    <img src="{% static 'images/logo.png' %}" alt="Logo">
    <script src="{% static 'js/main.js' %}"></script>
</body>
</html>

{% load static %} must be at the top of any template that uses static files. {% static 'path/to/file' %} generates the correct URL.

Collecting Static Files for Production

In production, Django doesn't serve static files itself; a web server like Nginx does. Before deploying, run:

python manage.py collectstatic

This copies every static file from all your apps and STATICFILES_DIRS into STATIC_ROOT. Your web server then serves files from that single folder.

Media Files

Media files are files uploaded by users: profile pictures, post images, attachments. Unlike static files, these are dynamic and generated at runtime.

Configuration

# settings.py
MEDIA_URL = '/media/'
MEDIA_ROOT = BASE_DIR / 'media'

MEDIA_URL — URL prefix for uploaded files
MEDIA_ROOT — where uploaded files are stored on disk

Serving Media Files in Development

Django doesn't serve media files automatically. Add this to your project's urls.py:

# mysite/urls.py
from django.conf import settings
from django.conf.urls.static import static

urlpatterns = [
    path('admin/', admin.site.urls),
    path('', include('core.urls')),
] + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

This only works in development. In production, your web server handles media files.

Adding a File Upload Field to a Model

class Post(models.Model):
    title = models.CharField(max_length=200)
    content = models.TextField()
    image = models.ImageField(upload_to='posts/', blank=True, null=True)
    created_at = models.DateTimeField(auto_now_add=True)

    def __str__(self):
        return self.title

upload_to='posts/' means uploaded images go into media/posts/. Run migrations after adding this field.

ImageField requires the Pillow package:

pip install Pillow

Handling File Uploads in a Form

When a form includes file uploads, the view needs request.FILES and the HTML form needs enctype:

def create_post(request):
    if request.method == 'POST':
        form = PostForm(request.POST, request.FILES)
        if form.is_valid():
            post = form.save(commit=False)
            post.author = request.user
            post.save()
            return redirect('home')
    else:
        form = PostForm()
    return render(request, 'core/create_post.html', {'form': form})

<form method="post" enctype="multipart/form-data">
    {% csrf_token %}
    {{ form.as_p }}
    <button type="submit">Save</button>
</form>

Without enctype="multipart/form-data", file data is not included in the POST request.

Displaying Uploaded Images in Templates

{% if post.image %}
    <img src="{{ post.image.url }}" alt="{{ post.title }}">
{% endif %}

Always check if the image exists before rendering; the field is optional here.

Environment Variables

Right now, settings.py likely has the secret key hardcoded, DEBUG=True, and database credentials in plain text. This is fine locally, but a serious security problem once the code goes to GitHub or a server.

Environment variables move sensitive values outside the codebase entirely.

Why This Matters

SECRET_KEY exposed in a public repo is a security vulnerability
DEBUG=True in production leaks error details to users
Database credentials in code means anyone with repo access has database access

python-decouple

python-decouple is the cleanest way to handle this in Django:

pip install python-decouple

Setting Up .env

Create a .env file at the project root:

SECRET_KEY=your-actual-secret-key-here
DEBUG=True
DATABASE_URL=sqlite:///db.sqlite3
ALLOWED_HOSTS=localhost,127.0.0.1

Immediately add .env to .gitignore:

# .gitignore
.env
env/
__pycache__/
*.pyc
staticfiles/
media/

Never commit .env to version control.

Using decouple in settings.py

from decouple import config, Csv

SECRET_KEY = config('SECRET_KEY')
DEBUG = config('DEBUG', default=False, cast=bool)
ALLOWED_HOSTS = config('ALLOWED_HOSTS', default='localhost', cast=Csv())

config('KEY') — reads the value from .env
default — fallback if the key isn't found
cast — converts the string value to the correct Python type
Csv() — splits a comma-separated string into a list

Database URL with dj-database-url

For database configuration, dj-database-url parses a database URL string into Django's DATABASES format:

pip install dj-database-url

import dj_database_url
from decouple import config

DATABASES = {
    'default': dj_database_url.config(
        default=config('DATABASE_URL')
    )
}

In .env:

DATABASE_URL=sqlite:///db.sqlite3

For PostgreSQL in production:

DATABASE_URL=postgres://user:password@localhost:5432/mydb

Switching databases becomes a one-line change in .env — no touching settings.py.

Separate Settings for Development and Production

A common pattern is having separate settings files:

mysite/
    settings/
        __init__.py
        base.py        # shared settings
        development.py # dev-specific
        production.py  # production-specific

# base.py — shared across all environments
SECRET_KEY = config('SECRET_KEY')
INSTALLED_APPS = [...]
TEMPLATES = [...]

# development.py
from .base import *
DEBUG = True
ALLOWED_HOSTS = ['localhost', '127.0.0.1']

# production.py
from .base import *
DEBUG = False
ALLOWED_HOSTS = config('ALLOWED_HOSTS', cast=Csv())

Run with a specific settings file:

python manage.py runserver --settings=mysite.settings.development

Or set it in the environment:

DJANGO_SETTINGS_MODULE=mysite.settings.development

A .env.example File

Since .env is gitignored, other developers cloning your repo won't know what variables are needed. Create a .env.example file with the keys but no values, and commit that:

# .env.example
SECRET_KEY=
DEBUG=
DATABASE_URL=
ALLOWED_HOSTS=

This is a convention every professional Django project follows.

Putting It All Together — Production Checklist

Before deploying any Django project, run through this:

python manage.py check --deploy

Django's built-in deployment check will flag any security issues. Common things it catches:

DEBUG = True — must be False in production
SECRET_KEY too short or predictable
Missing SECURE_SSL_REDIRECT
Missing SESSION_COOKIE_SECURE
ALLOWED_HOSTS empty or too permissive

Address every warning before going live.

Wrapping Up

Static files, media files, and environment variables are the unglamorous but essential parts of any Django project. Static files for design assets, media files for user uploads, and environment variables to keep secrets out of the codebase. Combined with the deployment checklist, the project is now actually ready to leave the local machine.

Thanks for reading. Feel free to share your thoughts!

Day 71 of #100DaysOfCode — DRF Deeper: ViewSets, Routers, and Token Authentication

M Saad Ahmad — Tue, 14 Apr 2026 07:38:40 +0000

Yesterday, I got DRF working with APIView and generic views. Today, for day 71, I went deeper: ViewSets and Routers, which are how DRF is actually used in real projects, and then Token Authentication to secure the API. By the end, the API was fully protected and only accessible with a valid token.

The Problem with What We Had

Yesterday's API worked, but had a lot of repetition in the URLs:

path('api/posts/', PostListCreateAPIView.as_view(), name='post-list'),
path('api/posts/<int:pk>/', PostRetrieveUpdateDestroyAPIView.as_view(), name='post-detail'),

Two classes, two URL patterns, for one model. In a real project with ten models, that's twenty classes and twenty URL patterns. ViewSets and Routers solve this.

ViewSets

A ViewSet combines all the related views for a model into a single class. Instead of separate lists and detail views, you write one ViewSet that handles everything.

from rest_framework import viewsets
from .models import Post
from .serializers import PostSerializer

class PostViewSet(viewsets.ModelViewSet):
    queryset = Post.objects.all()
    serializer_class = PostSerializer

That's it. ModelViewSet automatically provides:

Action	HTTP Method	URL
`list`	GET	`/api/posts/`
`create`	POST	`/api/posts/`
`retrieve`	GET	`/api/posts/{pk}/`
`update`	PUT	`/api/posts/{pk}/`
`partial_update`	PATCH	`/api/posts/{pk}/`
`destroy`	DELETE	`/api/posts/{pk}/`

Full CRUD in one class.

Routers

ViewSets need a Router to generate URLs automatically. You don't need to write path() manually anymore.

# core/urls.py
from django.urls import path, include
from rest_framework.routers import DefaultRouter
from .views import PostViewSet

router = DefaultRouter()
router.register('posts', PostViewSet, basename='post')

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

router.register() takes the URL prefix, the ViewSet, and a basename. The Router generates all six URL patterns automatically. One registration replaces two classes and two URL patterns.

Visit http://127.0.0.1:8000/api/. DRF's browsable API now shows you a clickable list of all registered endpoints.

Customizing ViewSets

Filtering the Queryset

class PostViewSet(viewsets.ModelViewSet):
    serializer_class = PostSerializer

    def get_queryset(self):
        return Post.objects.filter(author=self.request.user)

Overriding get_queryset() lets you filter based on the current user, query parameters, or anything else.

Attaching the Author on Create

class PostViewSet(viewsets.ModelViewSet):
    queryset = Post.objects.all()
    serializer_class = PostSerializer

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

perform_create() runs when a POST request passes validation. This is where you inject extra data before saving, same concept as commit=False in forms.

Custom Actions

Beyond the standard CRUD actions, you can add your own:

from rest_framework.decorators import action
from rest_framework.response import Response

class PostViewSet(viewsets.ModelViewSet):
    queryset = Post.objects.all()
    serializer_class = PostSerializer

    @action(detail=False, methods=['get'])
    def published(self, request):
        published_posts = Post.objects.filter(is_published=True)
        serializer = self.get_serializer(published_posts, many=True)
        return Response(serializer.data)

    @action(detail=True, methods=['post'])
    def publish(self, request, pk=None):
        post = self.get_object()
        post.is_published = True
        post.save()
        return Response({'status': 'post published'})

detail=False — action on the list endpoint: /api/posts/published/
detail=True — action on a single object: /api/posts/{pk}/publish/

The Router picks these up automatically and generates the URLs.

Read-Only ViewSet

If you only want to expose read operations and not allow creating or editing:

class PostReadOnlyViewSet(viewsets.ReadOnlyModelViewSet):
    queryset = Post.objects.filter(is_published=True)
    serializer_class = PostSerializer

ReadOnlyModelViewSet only provides list and retrieve. No create, update, or delete.

API Authentication

Right now, the API is completely open. Anyone can hit any endpoint. Authentication fixes that.

Types of Authentication in DRF

DRF supports several authentication methods:

Session Authentication — uses Django's session framework, works for browser-based clients
Token Authentication — a token is issued to each user, sent in request headers, works for any client
JWT Authentication — JSON Web Tokens, more advanced, requires an extra package
Basic Authentication — username and password in every request, only for development

For APIs consumed by frontend apps or mobile clients, Token Authentication is the standard starting point.

Setting Up Token Authentication

1. Add to INSTALLED_APPS

INSTALLED_APPS = [
    ...
    'rest_framework',
    'rest_framework.authtoken',
]

2. Run Migrations

python manage.py migrate

This creates the authtoken_token table in the database.

3. Configure DRF Settings

# settings.py
REST_FRAMEWORK = {
    'DEFAULT_AUTHENTICATION_CLASSES': [
        'rest_framework.authentication.TokenAuthentication',
    ],
    'DEFAULT_PERMISSION_CLASSES': [
        'rest_framework.permissions.IsAuthenticated',
    ],
}

DEFAULT_PERMISSION_CLASSES set to IsAuthenticated means every endpoint now requires authentication by default.

4. Create a Token Obtain Endpoint

# mysite/urls.py
from rest_framework.authtoken.views import obtain_auth_token

urlpatterns = [
    ...
    path('api/token/', obtain_auth_token, name='api-token'),
]

Send a POST request to /api/token/ with username and password:

{
    "username": "haris",
    "password": "securepass123"
}

DRF returns:

{
    "token": "9944b09199c62bcf9418ad846dd0e4bbdfc6ee4b"
}

Store this token on the client side. Send it in every subsequent request.

Using the Token in Requests

Include the token in the Authorization header of every request:

Authorization: Token 9944b09199c62bcf9418ad846dd0e4bbdfc6ee4b

In Postman, add a header with key Authorization and value Token <your_token_here>.

Without the token, the API returns:

{
    "detail": "Authentication credentials were not provided."
}

Permissions

Authentication answers "who are you?" Permissions answer "what are you allowed to do?"

Built-in Permission Classes

from rest_framework.permissions import IsAuthenticated, IsAdminUser, AllowAny, IsAuthenticatedOrReadOnly

IsAuthenticated — must be logged in
AllowAny — no restriction, open to everyone
IsAdminUser — only admin users
IsAuthenticatedOrReadOnly — anyone can read, only authenticated users can write

Setting Permissions Per ViewSet

You can override the global default on individual views:

from rest_framework.permissions import IsAuthenticatedOrReadOnly

class PostViewSet(viewsets.ModelViewSet):
    queryset = Post.objects.all()
    serializer_class = PostSerializer
    permission_classes = [IsAuthenticatedOrReadOnly]

Now, anyone can list and retrieve posts, but only authenticated users can create, update, or delete.

Custom Permissions

from rest_framework.permissions import BasePermission

class IsAuthorOrReadOnly(BasePermission):
    def has_object_permission(self, request, view, obj):
        if request.method in ['GET', 'HEAD', 'OPTIONS']:
            return True
        return obj.author == request.user

has_object_permission() runs on single-object actions — retrieve, update, delete. Here, it allows anyone to read but only the author to modify.

class PostViewSet(viewsets.ModelViewSet):
    queryset = Post.objects.all()
    serializer_class = PostSerializer
    permission_classes = [IsAuthenticated, IsAuthorOrReadOnly]

Generating Tokens Automatically on User Registration

Right now, tokens are only created when a user hits /api/token/. It's better to create one automatically when a user registers:

# core/signals.py
from django.db.models.signals import post_save
from django.contrib.auth.models import User
from rest_framework.authtoken.models import Token
from django.dispatch import receiver

@receiver(post_save, sender=User)
def create_auth_token(sender, instance=None, created=False, **kwargs):
    if created:
        Token.objects.create(user=instance)

# core/apps.py
from django.apps import AppConfig

class CoreConfig(AppConfig):
    name = 'core'

    def ready(self):
        import core.signals

Now every new user automatically gets a token the moment they register.

The Full API Picture

Client sends request to /api/posts/
        ↓
DRF checks Authorization header for token
        ↓
Token valid → identifies the user
        ↓
Permission classes check if user can perform this action
        ↓
ViewSet handles the request → queries database
        ↓
Serializer converts queryset to JSON
        ↓
Response returned to client

Wrapping Up

ViewSets and Routers cut the API code down dramatically; one class and one registration replaces multiple views and multiple URL patterns. Token Authentication locks the API down so only authenticated clients can access it, and custom permissions make sure users can only modify their own content.

Thanks for reading. Feel free to share your thoughts!

Day 70 of #100DaysOfCode — Class-Based Views + Introduction to DRF

M Saad Ahmad — Mon, 13 Apr 2026 07:37:03 +0000

Yesterday, the app had full authentication. Today, for day 70, I covered two things: Class-Based Views, which are Django's cleaner alternative to function-based views, and then used that understanding to jump into Django REST Framework. DRF builds directly.

Class-Based Views (CBVs)

So far, every view I've written has been a function. Django also lets you write views as classes. Same purpose, different structure, and Django provides a set of built-in generic CBVs that handle common patterns with very little code.

Function-Based View vs Class-Based View

Here's the same view written both ways:

# function-based
def post_list(request):
    posts = Post.objects.all()
    return render(request, 'core/post_list.html', {'posts': posts})

# class-based
from django.views.generic import ListView

class PostListView(ListView):
    model = Post
    template_name = 'core/post_list.html'
    context_object_name = 'posts'

Both do exactly the same thing. The CBV version is shorter because ListView handles the queryset fetching and context building automatically.

Wiring CBVs to URLs

CBVs need .as_view() when connecting to a URL:

from django.urls import path
from .views import PostListView

urlpatterns = [
    path('', PostListView.as_view(), name='home'),
]

Django's Built-in Generic CBVs

Django provides generic views for the most common patterns:

ListView — display a list of objects

from django.views.generic import ListView

class PostListView(ListView):
    model = Post
    template_name = 'core/post_list.html'
    context_object_name = 'posts'
    ordering = ['-created_at']
    paginate_by = 10  # built-in pagination

DetailView — display a single object

from django.views.generic import DetailView

class PostDetailView(DetailView):
    model = Post
    template_name = 'core/post_detail.html'
    context_object_name = 'post'

URL pattern for DetailView expects a pk or slug:

path('post/<int:pk>/', PostDetailView.as_view(), name='post_detail'),

CreateView — form to create an object

from django.views.generic.edit import CreateView
from django.urls import reverse_lazy

class PostCreateView(CreateView):
    model = Post
    fields = ['title', 'content', 'is_published']
    template_name = 'core/post_form.html'
    success_url = reverse_lazy('home')

reverse_lazy is like redirect() but evaluated lazily — required here because URLs aren't fully loaded when the class is defined.

UpdateView — form to edit an object

from django.views.generic.edit import UpdateView

class PostUpdateView(UpdateView):
    model = Post
    fields = ['title', 'content', 'is_published']
    template_name = 'core/post_form.html'
    success_url = reverse_lazy('home')

DeleteView — confirm and delete an object

from django.views.generic.edit import DeleteView

class PostDeleteView(DeleteView):
    model = Post
    template_name = 'core/post_confirm_delete.html'
    success_url = reverse_lazy('home')

Adding Login Required to CBVs

With function-based views you used @login_required. With CBVs you use LoginRequiredMixin:

from django.contrib.auth.mixins import LoginRequiredMixin

class PostCreateView(LoginRequiredMixin, CreateView):
    model = Post
    fields = ['title', 'content']
    template_name = 'core/post_form.html'
    success_url = reverse_lazy('home')

Always put LoginRequiredMixin as the first parent class.

Overriding Methods in CBVs

CBVs are classes, so you override methods to customize behavior:

class PostCreateView(LoginRequiredMixin, CreateView):
    model = Post
    fields = ['title', 'content']
    template_name = 'core/post_form.html'
    success_url = reverse_lazy('home')

    def form_valid(self, form):
        form.instance.author = self.request.user
        return super().form_valid(form)

form_valid() runs when the form passes validation. Here we attach the current user as author before saving, same as commit=False in the function-based approach, but cleaner.

When to Use FBVs vs CBVs

FBVs — more explicit, easier to read, better for complex custom logic
CBVs — less code for standard CRUD operations, built-in mixins for common behavior

Neither is wrong. Most Django projects use both depending on the situation.

Introduction to Django REST Framework

Now that CBVs make sense, DRF becomes much easier to understand. Because DRF is essentially CBVs built for APIs instead of HTML pages.

What is DRF?

Django REST Framework is a package that makes building REST APIs with Django straightforward. It handles:

Serializing Python objects to JSON
Deserializing and validating incoming JSON
API views and viewsets
Authentication for APIs
Browsable API interface for testing

Installation

pip install djangorestframework

Add to INSTALLED_APPS:

INSTALLED_APPS = [
    ...
    'rest_framework',
]

Serializers

A serializer is DRF's equivalent of a form. It converts model instances to JSON and validates incoming data.

# core/serializers.py
from rest_framework import serializers
from .models import Post

class PostSerializer(serializers.ModelSerializer):
    class Meta:
        model = Post
        fields = ['id', 'title', 'content', 'created_at', 'is_published']

Just like ModelForm, ModelSerializer generates fields automatically from the model.

Serializing Data

post = Post.objects.get(id=1)
serializer = PostSerializer(post)
print(serializer.data)
# {'id': 1, 'title': 'My Post', 'content': '...', ...}

# serializing multiple objects
posts = Post.objects.all()
serializer = PostSerializer(posts, many=True)
print(serializer.data)

Deserializing and Validating

data = {'title': 'New Post', 'content': 'Some content'}
serializer = PostSerializer(data=data)
if serializer.is_valid():
    serializer.save()
else:
    print(serializer.errors)

API Views

APIView — the base class

APIView is DRF's equivalent of Django's View. You define methods for each HTTP verb:

from rest_framework.views import APIView
from rest_framework.response import Response
from rest_framework import status
from .models import Post
from .serializers import PostSerializer

class PostListAPIView(APIView):
    def get(self, request):
        posts = Post.objects.all()
        serializer = PostSerializer(posts, many=True)
        return Response(serializer.data)

    def post(self, request):
        serializer = PostSerializer(data=request.data)
        if serializer.is_valid():
            serializer.save()
            return Response(serializer.data, status=status.HTTP_201_CREATED)
        return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)

Response automatically converts Python data to JSON. status gives you named HTTP status codes.

URL Setup for API Views

# core/urls.py
from django.urls import path
from .views import PostListAPIView

urlpatterns = [
    path('api/posts/', PostListAPIView.as_view(), name='post-list-api'),
]

Visit http://127.0.0.1:8000/api/posts/. DRF gives you a browsable API interface in the browser automatically. You can view responses and submit data without Postman.

Generic API Views

Just like Django has generic CBVs, DRF has generic API views that reduce boilerplate further:

from rest_framework import generics

class PostListCreateAPIView(generics.ListCreateAPIView):
    queryset = Post.objects.all()
    serializer_class = PostSerializer

class PostRetrieveUpdateDestroyAPIView(generics.RetrieveUpdateDestroyAPIView):
    queryset = Post.objects.all()
    serializer_class = PostSerializer

ListCreateAPIView — handles GET (list) and POST (create)
RetrieveUpdateDestroyAPIView — handles GET (single), PUT, PATCH, DELETE

urlpatterns = [
    path('api/posts/', PostListCreateAPIView.as_view(), name='post-list'),
    path('api/posts/<int:pk>/', PostRetrieveUpdateDestroyAPIView.as_view(), name='post-detail'),
]

Two classes, two URLs. Full CRUD API.

The Comparison That Makes It Click

Django (HTML)	DRF (JSON API)
`View`	`APIView`
`ListView`	`ListAPIView`
`CreateView`	`CreateAPIView`
`Form` / `ModelForm`	`Serializer` / `ModelSerializer`
`render()`	`Response()`
Template	JSON

Same concepts, different output format. That's DRF.

Wrapping Up

CBVs cleaned up the view code significantly, and understanding them made DRF immediately readable. Serializers work like forms, API views work like CBVs, and generic API views cut boilerplate to almost nothing. The app now serves both HTML pages and a JSON API from the same Django project.

Thanks for reading. Feel free to share your thoughts!

Day 69 of 100 Days Of Code — Authentication in Django

M Saad Ahmad — Sun, 12 Apr 2026 04:28:58 +0000

Yesterday I built forms that let users submit data. Today, for day 69, it was Authentication in Django. Django ships with a complete authentication system out of the box. User registration, login, logout, password handling, and protecting pages from unauthenticated access. All of it, without installing a single extra package.

What Django Gives You for Free

Django's django.contrib.auth app is included by default in INSTALLED_APPS. It provides:

A built-in User model
Login and logout views
Password hashing
Session management
Permission and group system
Decorators to protect views

You don't build any of this from scratch.

The Built-in User Model

Django's User model lives in django.contrib.auth.models. It comes with these fields by default:

username
password — stored as a hash, never plain text
email
first_name, last_name
is_active
is_staff — can access admin panel
is_superuser — has all permissions
date_joined
last_login

from django.contrib.auth.models import User

# create a user
user = User.objects.create_user(username='haris', password='securepass123')

# get a user
user = User.objects.get(username='haris')
print(user.email)
print(user.is_authenticated)  # True

Always use create_user() instead of create(); it handles password hashing automatically.

User Registration

Django doesn't provide a registration view out of the box, but it does provide UserCreationForm: a built-in form for creating new users.

# core/forms.py
from django.contrib.auth.forms import UserCreationForm
from django.contrib.auth.models import User

class RegisterForm(UserCreationForm):
    email = forms.EmailField(required=True)

    class Meta:
        model = User
        fields = ['username', 'email', 'password1', 'password2']

UserCreationForm already handles password confirmation and validation. We extend it here just to add an email field.

# core/views.py
from django.shortcuts import render, redirect
from .forms import RegisterForm

def register(request):
    if request.method == 'POST':
        form = RegisterForm(request.POST)
        if form.is_valid():
            form.save()
            return redirect('login')
    else:
        form = RegisterForm()

    return render(request, 'core/register.html', {'form': form})

<!-- core/templates/core/register.html -->
{% extends 'core/base.html' %}

{% block content %}
    <h1>Register</h1>
    <form method="post">
        {% csrf_token %}
        {{ form.as_p }}
        <button type="submit">Create Account</button>
    </form>
    <p>Already have an account? <a href="{% url 'login' %}">Login</a></p>
{% endblock %}

Login and Logout

Django provides built-in views for login and logout. You just wire them to URLs.

# mysite/urls.py
from django.contrib import admin
from django.urls import path, include
from django.contrib.auth import views as auth_views

urlpatterns = [
    path('admin/', admin.site.urls),
    path('', include('core.urls')),
    path('login/', auth_views.LoginView.as_view(template_name='core/login.html'), name='login'),
    path('logout/', auth_views.LogoutView.as_view(), name='logout'),
]

You provide your own template for login, Django handles all the logic.

<!-- core/templates/core/login.html -->
{% extends 'core/base.html' %}

{% block content %}
    <h1>Login</h1>
    <form method="post">
        {% csrf_token %}
        {{ form.as_p }}
        <button type="submit">Login</button>
    </form>
    <p>Don't have an account? <a href="{% url 'register' %}">Register</a></p>
{% endblock %}

After a successful login, Django redirects to /accounts/profile/ by default. Override this in settings.py:

LOGIN_REDIRECT_URL = 'home'
LOGOUT_REDIRECT_URL = 'login'

Accessing the Current User in Views

Once a user is logged in, Django attaches them to every request as request.user.

def home(request):
    print(request.user)               # the User object
    print(request.user.username)      # 'haris'
    print(request.user.is_authenticated)  # True if logged in, False if not

An unauthenticated user is represented by AnonymousUser. Always check is_authenticated before accessing user data.

Accessing the Current User in Templates

Django automatically makes request.user available in every template through the request context processor, which is included by default.

{% if request.user.is_authenticated %}
    <p>Welcome, {{ request.user.username }}</p>
    <a href="{% url 'logout' %}">Logout</a>
{% else %}
    <a href="{% url 'login' %}">Login</a>
    <a href="{% url 'register' %}">Register</a>
{% endif %}

Put this in your base.html so it appears on every page.

Protecting Views

The @login_required Decorator

Use this on any view that requires authentication:

from django.contrib.auth.decorators import login_required

@login_required
def create_post(request):
    ...

If an unauthenticated user tries to access this view, Django redirects them to the login page automatically. Set where Django sends them in settings.py:

LOGIN_URL = 'login'

Checking in the View Manually

Sometimes you need more control:

def some_view(request):
    if not request.user.is_authenticated:
        return redirect('login')
    ...

Linking Posts to Users

In most apps, content belongs to a user. Add a ForeignKey to the User model on your Post:

from django.contrib.auth.models import User

class Post(models.Model):
    author = models.ForeignKey(User, on_delete=models.CASCADE)
    title = models.CharField(max_length=200)
    content = models.TextField()
    created_at = models.DateTimeField(auto_now_add=True)

    def __str__(self):
        return self.title

on_delete=models.CASCADE means if the user is deleted, their posts are deleted too.

When saving a post from a form, attach the current user before saving:

@login_required
def create_post(request):
    if request.method == 'POST':
        form = PostForm(request.POST)
        if form.is_valid():
            post = form.save(commit=False)
            post.author = request.user
            post.save()
            return redirect('home')
    else:
        form = PostForm()

    return render(request, 'core/create_post.html', {'form': form})

commit=False tells Django to create the object in memory but not save to the database yet, giving you a chance to set extra fields like author before the actual save.

Restricting Actions to the Owner

You don't want users editing each other's posts:

@login_required
def edit_post(request, pk):
    post = get_object_or_404(Post, pk=pk)

    if post.author != request.user:
        return redirect('home')

    if request.method == 'POST':
        form = PostForm(request.POST, instance=post)
        if form.is_valid():
            form.save()
            return redirect('home')
    else:
        form = PostForm(instance=post)

    return render(request, 'core/edit_post.html', {'form': form})

URL Setup

# core/urls.py
from django.urls import path
from . import views

urlpatterns = [
    path('', views.home, name='home'),
    path('register/', views.register, name='register'),
    path('post/<int:pk>/', views.post_detail, name='post_detail'),
    path('post/create/', views.create_post, name='create_post'),
    path('post/<int:pk>/edit/', views.edit_post, name='edit_post'),
]

The Full Authentication Flow

User visits /post/create/
        ↓
@login_required checks request.user.is_authenticated
        ↓
Not authenticated → redirect to /login/
        ↓
User fills in login form → POST to /login/
        ↓
Django validates credentials, creates session
        ↓
Redirect to LOGIN_REDIRECT_URL → /
        ↓
User visits /post/create/ again
        ↓
Now authenticated → view runs normally

Wrapping Up

Django's authentication system is one of the best reasons to use it. Registration, login, logout, session management, password hashing, all handled. Today the app became a real multi-user system where posts belong to users, protected pages require login, and only owners can edit their own content.

Thanks for reading. Feel free to share your thoughts!

Day 68 of 100 Days Of Code — Django Forms

M Saad Ahmad — Sat, 11 Apr 2026 05:28:32 +0000

Yesterday, I learned Models and ORM and had a working app with real data from a database. But all that data was created through the admin panel. Today, for Day 68, I learned about Django Forms, letting users submit data from the browser directly. By the end, I had a form on a real page that validates input, handles errors, and saves to the database.

What is a Django Form?

A Django Form is a Python class that handles three things:

Rendering HTML input fields
Validating submitted data
Giving you clean, safe data to work with

You could write raw HTML forms and handle everything manually, but Django's form system saves a lot of work and handles security for you, including CSRF protection.

Two Types of Forms

Django has two kinds of forms:

Form — a standalone form, not tied to any model
ModelForm — a form generated directly from a model

In most cases, you'll use ModelForm because you're usually creating or editing database records.

Creating a Form

Standalone Form

# core/forms.py
from django import forms

class ContactForm(forms.Form):
    name = forms.CharField(max_length=100)
    email = forms.EmailField()
    message = forms.CharField(widget=forms.Textarea)

ModelForm

# core/forms.py
from django import forms
from .models import Post

class PostForm(forms.ModelForm):
    class Meta:
        model = Post
        fields = ['title', 'content', 'is_published']

The Meta class tells Django which model to use and which fields to include. Django generates the form fields automatically based on the model field types.

Use fields = '__all__' to include every field, or explicitly list the fields you want. Always prefer listing fields explicitly; never expose fields you don't intend to.

Common Form Fields

Field	Use
`CharField`	Short text input
`EmailField`	Email input with validation
`IntegerField`	Number input
`BooleanField`	Checkbox
`ChoiceField`	Dropdown select
`DateField`	Date input
`FileField`	File upload

Widgets

A widget controls how a field is rendered as HTML. Every field has a default widget, but you can override it:

class PostForm(forms.ModelForm):
    class Meta:
        model = Post
        fields = ['title', 'content', 'is_published']
        widgets = {
            'title': forms.TextInput(attrs={'placeholder': 'Enter title'}),
            'content': forms.Textarea(attrs={'rows': 5}),
        }

attrs lets you pass HTML attributes directly to the input element.

Handling Forms in Views

A form view handles two scenarios: a GET request (user visiting the page) and a POST request (user submitting the form).

# core/views.py
from django.shortcuts import render, redirect
from .forms import PostForm

def create_post(request):
    if request.method == 'POST':
        form = PostForm(request.POST)
        if form.is_valid():
            form.save()
            return redirect('home')
    else:
        form = PostForm()

    return render(request, 'core/create_post.html', {'form': form})

This pattern is the standard Django form view:

If POST — bind the submitted data to the form with PostForm(request.POST)
Validate with is_valid() — runs all field validators and form-level validation
If valid — save and redirect
If GET or invalid — render the form (with errors if invalid)

The redirect() after a successful save prevents the form from being resubmitted if the user refreshes the page.

Rendering the Form in a Template

<!-- core/templates/core/create_post.html -->
{% extends 'core/base.html' %}

{% block content %}
    <h1>Create Post</h1>
    <form method="post">
        {% csrf_token %}
        {{ form.as_p }}
        <button type="submit">Save</button>
    </form>
{% endblock %}

Three things to notice:

method="post" — forms that submit data must use POST
{% csrf_token %} — required by Django for every POST form, protects against cross-site request forgery attacks. Django will reject the form without it.
{{ form.as_p }} — renders all form fields wrapped in <p> tags

Other rendering options:

{{ form.as_p }} — fields in paragraph tags
{{ form.as_ul }} — fields in list items
{{ form.as_table }} — fields in table rows
{{ form }} — same as as_table

Rendering Fields Manually

For more control over layout, render fields individually:

<form method="post">
    {% csrf_token %}
    <div>
        <label for="{{ form.title.id_for_label }}">Title</label>
        {{ form.title }}
        {% if form.title.errors %}
            <span>{{ form.title.errors }}</span>
        {% endif %}
    </div>
    <div>
        <label for="{{ form.content.id_for_label }}">Content</label>
        {{ form.content }}
        {% if form.content.errors %}
            <span>{{ form.content.errors }}</span>
        {% endif %}
    </div>
    <button type="submit">Save</button>
</form>

This gives you full control over the HTML structure while still using Django's field rendering and error handling.

Form Validation

is_valid() runs two levels of validation:

Field-level — built into each field type. EmailField checks it's a valid email, IntegerField checks it's a number, CharField checks max_length, and so on.

Custom validation — you can add your own rules:

class PostForm(forms.ModelForm):
    class Meta:
        model = Post
        fields = ['title', 'content']

    def clean_title(self):
        title = self.cleaned_data['title']
        if len(title) < 5:
            raise forms.ValidationError("Title must be at least 5 characters.")
        return title

    def clean(self):
        cleaned_data = super().clean()
        title = cleaned_data.get('title')
        content = cleaned_data.get('content')
        if title and content and title == content:
            raise forms.ValidationError("Title and content cannot be the same.")
        return cleaned_data

clean_<fieldname>() — validates a single field
clean() — validates across multiple fields at once

After is_valid() passes, access the validated data through form.cleaned_data:

if form.is_valid():
    title = form.cleaned_data['title']

Editing an Existing Object

To edit rather than create, pass the existing instance to the form:

def edit_post(request, pk):
    post = get_object_or_404(Post, pk=pk)
    if request.method == 'POST':
        form = PostForm(request.POST, instance=post)
        if form.is_valid():
            form.save()
            return redirect('home')
    else:
        form = PostForm(instance=post)

    return render(request, 'core/edit_post.html', {'form': form})

Passing instance=post pre-fills the form with the existing data and tells save() to update rather than create.

URL Setup

# core/urls.py
from django.urls import path
from . import views

urlpatterns = [
    path('', views.home, name='home'),
    path('post/<int:pk>/', views.post_detail, name='post_detail'),
    path('post/create/', views.create_post, name='create_post'),
    path('post/<int:pk>/edit/', views.edit_post, name='edit_post'),
]

The Full Flow

User visits /post/create/
        ↓
GET request → view creates empty form
        ↓
Template renders the form as HTML
        ↓
User fills in fields and submits
        ↓
POST request → view binds data to form
        ↓
form.is_valid() runs all validators
        ↓
If valid → form.save() → redirect
If invalid → re-render form with errors shown

Wrapping Up

Forms are where Django starts feeling like a real full-stack framework. The model defines the data structure, the form handles input and validation, the view orchestrates the flow, and the template renders it. All four layers working together.

Tomorrow: Django Authentication; user registration, login, and logout.

Thanks for reading. Feel free to share your thoughts!

DEV Community: M Saad Ahmad

Day 79 of #100DaysOfCode — Flask Routes, Requests, and Responses

Routes in Depth

The url_for Function

Route Converters

Trailing Slashes

HTTP Methods

The Request Object

Query Parameters

Form Data

JSON Data

File Uploads

Request Headers and Cookies

Useful Request Properties

Responses in Depth

Return a String

Return with a Status Code

Return with Headers

make_response

Redirects

JSON Responses

Abort — Early Exit with an Error

Error Handlers

Before and After Request Hooks

Putting It Together — A Small Example

Wrapping Up

Day 78 of #100DaysOfCode — Introduction to Flask: Setup and First App

Flask vs Django — The Key Difference

Setup

The Simplest Flask App

Breaking It Down

Multiple Routes

URL Variables

The flask CLI

Returning HTML

HTTP Methods

The Response Object

JSON Responses

Flask vs Django Side by Side

Wrapping Up

Day 77 of #100DaysOfCode — Building DevBoard: Progress, Lessons, and What's Next

What Got Built

What's Still Left

What Actually Happened

The Real Lesson

What's Next

What I'd Recommend

Day 76 of #100DayOfCode — Building DevBoard: REST API and UI Polish

The REST API

What the API Exposes

Serializers

ViewSet and Router

Token Authentication for the API

UI Polish with Tailwind CSS

What Changed Visually

Mobile Responsiveness

A Few Small Improvements Along the Way

Where DevBoard Stands After Day 76

Day 75 of #100DaysOfCode — Building DevBoard: Job Search and Applications

The Job Listings Page

Search and Filtering

Job Detail Page

The Application Flow

Candidate Dashboard

A Problem I Hit

What DevBoard Can Do Now

Day 74 of #100DaysOfCode — Building DevBoard: Employer Dashboard

Starting with the Job Model

The Employer Dashboard

Posting a Job

Editing and Deleting Jobs

Viewing Applications

What the Jobs App Looks Like Now

Where Things Stand After Day 74

Day 73 of 100 Days Of Code — Building DevBoard: Project Setup and Authentication

What is DevBoard?

Project Setup

Custom User Model

Employer Profile

Candidate Profile

The `url_for` Function

The `flask` CLI