DEV Community: Merdas369

How I Learned About Context Processors in Django 🚀

Merdas369 — Wed, 17 Jun 2026 15:59:48 +0000

How I Learned About Context Processors in Django 🚀

I'm currently working on an online accessories shop with Django. While building the project, I created a navbar that displayed all product categories. At first, the navbar was hard-coded, and everything seemed fine.

Then I realized a problem 🤔.

If I added a new category in the future, I would have to manually update the navbar every time. That didn't feel right.

My first idea was to pass the categories through the context in my product list view. But after thinking more carefully, I noticed another issue: every page that needed the navbar would require the same context data.

That meant repeating the same code across multiple views, which would quickly become messy and difficult to maintain.

After doing some research, I discovered Django Context Processors, and it turned out to be exactly the solution I needed. 🎉

What are Context Processors?

Context processors are similar to the context data we pass from views, but they make data available globally to templates.

They're useful when you have data that should be accessible in many templates, such as:

Navigation categories
Site settings
User notifications
Shopping cart information

A context processor is simply a Python function that accepts a "request" object and returns a dictionary.

Example:

def custom_context(request):
    return {
        "custom_value": "hello from context processors"
    }

Registering the Context Processor

After creating the function, you need to register it in your Django settings:

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [os.path.join(BASE_DIR, 'templates')],
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                # Other context processors
                'myapp.context_processors.custom_context',
            ],
        },
    },
]

Using It in Templates

Once registered, the returned values become available in your templates automatically:

{{ custom_value }}

No need to pass the same data from every view anymore. 🎯

For my project, this was the perfect way to make category data available to the navbar across the entire site without duplicating code.

Sometimes while building a feature, you run into a problem that teaches you a Django concept you never knew existed. For me, that concept was Context Processors.

Django Debug Toolbar + Docker: The Missing INTERNAL_IPS Problem

Merdas369 — Sat, 13 Jun 2026 14:19:00 +0000

Django Debug Toolbar Didn't Appear When Running Django in Docker

I'm currently working on an online accessories shop as a personal project. I usually use Django Debug Toolbar in all of my Django projects, so setting it up is almost automatic for me.

This time, however, my project was running inside Docker.

After preparing everything and starting the containers, I opened the browser and noticed that the Django Debug Toolbar panel wasn't showing up.

My first thought was that I had missed a setup step, so I went back to the Django Debug Toolbar documentation and checked everything again. I followed the installation guide step by step and verified all the settings. Everything looked correct, but the toolbar still didn't appear.

After searching online for a while, I found the real cause.

Django Debug Toolbar only appears when the request comes from an IP address listed in "INTERNAL_IPS". Normally, when running Django locally, "127.0.0.1" or "localhost" is enough.

With Docker, things are a little different. The request doesn't always come from the usual local address, so Debug Toolbar may think the request is coming from an external IP and refuse to display itself.

To discover the actual IP address reaching Django, I created a simple view:

from django.http import HttpResponse

def test(request):
    return HttpResponse(request.META.get("REMOTE_ADDR"))

When I visited that endpoint, the response was:

172.18.0.1

After adding that IP address to "INTERNAL_IPS":

INTERNAL_IPS = [
    "127.0.0.1",
    "172.18.0.1",
]

the Django Debug Toolbar appeared perfectly in the browser.

What I Learned

This issue reminded me of an important debugging lesson:

When something that normally works suddenly stops working after introducing a new tool or layer (such as Docker), don't assume the original tool is broken. Sometimes the new component changes the environment in a way that affects the existing behavior.

In my case, Django Debug Toolbar was working exactly as designed. Docker simply changed where the request was coming from.

Using AI as a Project Manager Instead of a Code Generator

Merdas369 — Fri, 12 Jun 2026 15:32:56 +0000

I Don't Use AI to Write My Code — I Use It as My Project Manager
Over the past year, AI has become a common tool among developers. Some developers use it to generate code, write tests, explain concepts, or even build entire applications from prompts.
My approach is a little different.
I don't primarily use AI to write my code. Instead, I use it as a project manager.
The Problem
One challenge many developers face is not writing code itself. The bigger challenge is knowing what to build next.
When starting a new project, there are usually dozens of decisions to make:
What should the architecture look like?
Which features should be built first?
What models are needed?
What can be postponed?
How should the project be organized?
What are the milestones?
As solo developers, we often play multiple roles at once: developer, designer, architect, tester, and project manager.
This is where AI has become extremely valuable for me.
How I Use AI
When I start a project, I explain the project requirements to AI in detail.
For example, I recently started building an e-commerce application using Django, HTMX, Alpine.js, Tailwind CSS, PostgreSQL, Redis, and Docker.
Instead of asking AI to generate the entire project, I ask it to act as a senior project manager and technical lead.
I provide:
Project goals
Features
Technical stack
Constraints
Business requirements
Then I ask AI to create a roadmap.
The roadmap is usually divided into phases such as:
Foundation and setup
Product domain
Cart and checkout
Payments
User accounts
Admin features
Deployment
After finishing a phase, I return and ask for the next phase.
AI then gives me a list of tasks that I can complete one by one.
Why This Works for Me
There are several reasons I prefer this approach.

I Learn More If AI generates every file and function, I often find myself copying code without deeply understanding it. By implementing features myself, I stay involved in the technical decisions and understand how everything works.
I Stay Organized Large projects can become overwhelming. Having a roadmap and a clear list of tasks removes the feeling of "What should I do next?" I simply focus on the current task.
Better Project Structure AI can help identify missing pieces that I might overlook. For example: SEO requirements Inventory management Database relationships Deployment preparation Security considerations Having another "brain" reviewing the project plan can be very helpful.
It Feels Like Working With a Team Lead As a solo developer, there is nobody assigning tasks or reviewing the overall direction. Using AI as a project manager creates a workflow that feels closer to working in a team. I still write the code, make the decisions, and solve the problems, but I have guidance when planning the next steps. The Downsides Of course, this approach is not perfect. AI can sometimes: Suggest unnecessary complexity Miss business requirements Create unrealistic roadmaps Recommend tools that don't fit the project Because of that, I never follow its suggestions blindly. I treat the roadmap as advice, not as instructions. Ultimately, I am responsible for the project. My Current Workflow My workflow usually looks like this: Define the project requirements. Ask AI to create a roadmap. Break the roadmap into phases. Complete one phase at a time. Return to AI for the next set of tasks. Implement everything manually. Review and adjust the plan when needed. This gives me the structure of a project manager while keeping the learning and coding experience in my own hands. A Question for Other Developers I'm curious how other developers feel about this approach. Most discussions about AI focus on code generation, but I rarely see people talking about using AI as a project manager, roadmap creator, or technical planner. Do you think this is a good way to use AI in software development? Would you trust AI to organize your projects and define your roadmap while still writing the code yourself? I'd love to hear how you're using AI in your development workflow.

🚀 Why I Love Building Modern Web Apps with Django + HTMX + Alpine.js

Merdas369 — Sun, 07 Jun 2026 07:26:06 +0000

Web development has become very powerful, but also very complicated.

Today many projects start with a frontend framework, API endpoints, state management, client routing, build tools, and many packages before even building the real product 😅

Sometimes I ask myself:

"Do I really need all of this just to create a fast and interactive website?"

For me, the answer is often no.

Recently I have been building projects with Django + HTMX + Alpine.js, and this stack feels refreshingly simple. It lets me create modern applications quickly without carrying the complexity of a large SPA.

⚡ Development becomes much faster

The biggest thing I noticed is speed.

Not website speed only.

Developer speed.

Instead of creating:

Frontend project
Backend project
API endpoints
Authentication logic in multiple places
State management
Data synchronization

I can work inside one application.

Django handles the backend.

HTMX handles dynamic requests.

Alpine.js handles small frontend interactions.

Everything works together naturally.

Less setup.

Less code.

Less headaches 😄

🎯 HTMX makes HTML fun again

HTMX feels almost magical.

You can create interactions directly inside HTML.

Instead of writing many JavaScript functions, fetching data manually, and updating elements yourself, you simply add attributes.

Something like:

<button
    hx-post="/like-post/"
    hx-target="#likes"
    hx-swap="innerHTML"
>
    ❤️ Like
</button>

That is it.

Click the button.

A request is sent.

The server responds.

The page updates automatically.

No large JavaScript files.

No complex state management.

No API calls written manually.

HTMX turns HTML into something much more powerful.

✨ Alpine.js keeps things simple

Sometimes we still need small interactions:

Opening modals
Dropdown menus
Tabs
Toggles
Showing and hiding elements

For these situations, Alpine.js is perfect.

You can add behavior directly in HTML.

Example:

<div x-data="{ open: false }">

    <button @click="open=!open">
        Menu
    </button>

    <div x-show="open">
        Content here
    </div>

</div>

Very small.

Very readable.

Very easy.

Alpine.js feels like adding superpowers to HTML without building an entire frontend application.

🔒 Django already gives great security

Security is something people sometimes forget during development.

One thing I like about Django is that many security features already exist out of the box.

Django helps with:

✅ CSRF protection

✅ SQL injection protection

✅ Password hashing

✅ Authentication system

✅ Session management

✅ Security middleware

Instead of installing many packages and configuring everything manually, Django already gives strong foundations.

This means I spend more time building features and less time worrying about basic security.

🌍 Modern apps without SPA complexity

Many people think modern applications must be SPAs.

But modern user experience is not only about using huge frontend frameworks.

Users want:

Fast pages
Smooth interactions
Responsive interfaces
Good user experience

Django + HTMX + Alpine.js can provide all of that.

You can build:

📋 Dashboards

🛒 E-commerce websites

💬 Chat systems

📊 Admin panels

📝 Blog platforms

🚀 SaaS applications

And you can do this without creating API layers for everything.

Without complex frontend architecture.

Without sending large amounts of JavaScript to the browser.

❤️ Why I enjoy this stack

For me, this stack feels closer to what web development was always supposed to be:

Build things quickly.

Keep things simple.

Ship products faster.

Focus on features instead of fighting tooling.

Sometimes simpler really is better.

Maybe we don't need to make every website more complicated than it needs to be 😄

What stack are you enjoying these days?