Django opnieuw leren: een leerroute die begint bij HTTP

Django opnieuw leren: een leerroute die begint bij HTTP

Aan het einde van het jaar kijken we vaak terug op het afgelopen jaar. Voor mij is er één onderwerp dat elk jaar terugkomt: “Heb ik Django echt goed geleerd?”

Ik gebruik Django en Django REST Framework (DRF) al jaren. Na talloze projecten kan ik nu met zekerheid zeggen:

“Ik begrijp beter hoe alles werkt dan vroeger.”

Er zijn nog steeds veel dingen die ik niet weet, maar ik kan nu mijn oude zelf en beginnende ontwikkelaars geruststellen: “Als je op deze volgorde leert, kom je veel minder in de war.”

Deze tekst is een persoonlijke gids over hoe je Django vanaf het begin opnieuw kunt leren. Het leest als een jaarafsluiting, maar is ook een blijvende referentie voor Django‑leren.

1. Django is uiteindelijk een HTTP‑framework

Dit klinkt vanzelfsprekend, maar bij het eerste leren van Django vergeet je dit vaak.

Of je nu een UI rendert of alleen een JSON‑API teruggeeft, het kernidee is: HTTP‑verzoeken ontvangen en HTTP‑antwoorden terugsturen.

• Een client (browser, app, andere server) stuurt een HTTP‑verzoek.
• Django verwerkt dat verzoek.
• Django stuurt een HTTP‑antwoord (HTML, JSON, bestand, fout, …) terug.

De onderdelen die we vaak associëren met Django:

• URLConf
• View (FBV/CBV)
• Template
• ORM
• Middleware
• Authenticatie / permissies
• DRF‑componenten: Serializer, ViewSet, Router, …

Allemaal zijn dat simpelweg hulpmiddelen om een HTTP‑verzoek goed te ontvangen, te verwerken en terug te sturen.

Als je deze visie mist, lijkt het framework snel een "magische doos". Je gebruikt het, maar begrijpt niet waarom het werkt.

“Ik gebruik het, maar waarom werkt het zo?”

Als dit zo lang blijft, word je uiteindelijk een pion in het framework.

2. Begrijp eerst waarom je iets doet, voordat je de functies gebruikt

Bij het eerste leren van Django vallen vaak de volgende functies op:

• Inloggen/registreren, social login
• Autorisatie
• Caching
• Asynchrone taken (Celery, …)
• Diverse middleware en instellingen

Dit zijn ongetwijfeld nuttige functies, maar het probleem ontstaat als je te vroeg erin duikt.

Je vraagt jezelf dan af:

“Waarom moet ik het zo doen?”

Als je geen antwoord hebt, stap je in een patroon van:

• Fouten oplossen, maar het blijft onduidelijk
• Structuur veranderen, maar het framework beperkt je
• Google‑en kopiëren, en dan “oké, het werkt, laten we doorgaan”

Daarom wil ik mijn oude zelf en beginnende ontwikkelaars het volgende vertellen:

“Voordat je functies implementeert, begrijp eerst de werking van het web en de HTTP‑stroom.”

3. Als je de HTTP‑stroom begrijpt, zie je ook buiten Django

Wil je Django transparant gebruiken, dan kun je de basisstroom van HTTP niet negeren.

Het is handig om de volgende zaken zelf te ervaren:

• Hoe ziet een verzoek eruit?
• URL, methode (GET/POST/PUT/DELETE…), headers, querystring, body
• Hoe wordt een antwoord bepaald?
• Statuscode (200/400/404/500…), headers, body (JSON/HTML, …)
• Wat cacheert de browser, wat moet de server overwegen?

Een eenvoudig voorbeeld: stuur een verzoek vanuit de terminal.

curl -X GET "http://localhost:8000/articles/1/" -H "Accept: application/json"

Dit verzoek bevat alle kernpunten van HTTP:

• URL: /articles/1/
• Methode: GET
• Header: Accept: application/json
• Verwachte antwoord: JSON

Als je deze stroom in je hoofd visualiseert, zie je ook buiten Django:

• Waarom proxy‑t je bepaalde routes via nginx naar Django?
• Welke rol spelen WSGI‑servers zoals gunicorn/uWSGI?
• Waar eindigt Django en waar begint een andere laag?

Op dit punt is Django geen onbekende magie meer. Je ziet dat de structuur nodig is om HTTP‑verzoeken te verwerken.

“De handige functies van Django zijn niet het fundament, maar de bijproducten. Als je de fundamenten (HTTP en web) begrijpt, volgen de bijproducten vanzelf.”

4. Begin simpel, gebruik FBV

Voor een eerste project raad ik aan om het intentioneel simpel te houden en Function‑Based Views (FBV) te gebruiken.

Probeer de volgende voorwaarden te volgen:

• Minimalistische authenticatie/autorisatie
• Geen ingewikkelde admin‑pagina of instellingen
• Eenvoudige modellen (bijv. artikel, comment)
• Focus op de flow in plaats van een “mooie” architectuur

Een voorbeeld van een eenvoudige artikel‑detail‑view in FBV:

# views.py
from django.http import JsonResponse
from .models import Article

def article_detail(request, pk):
    article = Article.objects.get(pk=pk)
    data = {
        "id": article.id,
        "title": article.title,
        "content": article.content,
    }
    return JsonResponse(data)

In één view zie je de volledige Django‑stroom:

1. request‑object als parameter
2. ORM‑query via pk
3. Python‑dict maken
4. JSON‑antwoord terugsturen

Door stap voor stap te debuggen, zie je:

• Hoe URLConf de view koppelt
• Welke informatie het request‑object bevat
• Welke SQL de ORM genereert
• Hoe het antwoord naar JSON wordt omgezet

Deze fase is cruciaal: als je de Django‑ORM onder de knie hebt, is dat een enorme troef voor elk project.

5. Ga daarna snel naar CBV en DRF

Als je de FBV‑stroom goed hebt ervaren, is het tijd om Class‑Based Views (CBV) en DRF te omarmen.

De echte kracht van Django en DRF komt hier tevoorschijn:

• Herhalende patronen verminderen via herbruikbare structuren
• Consistente patronen door het hele project
• Duidelijke verantwoordelijkheden
• Uitbreidbare ontwerpen met URL/Serializer/ViewSet/Permission

Een DRF‑implementatie van hetzelfde artikel‑model ziet er zo uit:

# views.py (DRF)
from rest_framework.viewsets import ReadOnlyModelViewSet
from .models import Article
from .serializers import ArticleSerializer

class ArticleViewSet(ReadOnlyModelViewSet):
    queryset = Article.objects.all()
    serializer_class = ArticleSerializer

En de router:

# urls.py
from rest_framework.routers import DefaultRouter
from .views import ArticleViewSet

router = DefaultRouter()
router.register(r'articles', ArticleViewSet, basename='article')

urlpatterns = router.urls

Nu werken de endpoints automatisch:

• /articles/
• /articles/{id}/

Als je de HTTP‑stroom al begrijpt, zie je dat CBV/DRF simpelweg een abstrahering is van dezelfde basis.

“Het is nog steeds dezelfde HTTP‑verwerking, maar nu is het gestructureerd in een klasse.”

Deze mindset maakt het leren van CBV/DRF veel sneller. Als iets onduidelijk is, duik dan in de Django‑broncode.

6. Herstructurering van de leerroute

Voor mijn oude zelf en voor beginnende ontwikkelaars stel ik de volgende volgorde voor:

1. Basisweb en HTTP - Browser‑server‑stroom - HTTP‑methoden, statuscodes, headers, cookies, sessies - Praktijk met curl of Postman
2. Django‑basis: één ronde met FBV - URLConf → View → Template → ORM - Een klein project zonder authenticatie - CRUD met de ORM
3. Dieper in Django‑ORM en Admin - Modellen, relaties, query‑optimalisatie - Admin‑interface gebruiken
4. Overstappen naar CBV - Generic Views, mixins, overerving
5. DRF‑API bouwen - Serializer, ViewSet, Router, Permission, Authentication - Herbouw van FBV/CBV‑functionaliteit
6. Vervolgens de “glamour‑functies” - Authenticatie/autorisatie, throttling, pagination, filtering - Caching, asynchrone taken, deployment, scaling

Belangrijk: Kun je zelf uitleggen waarom je iets doet?

“Ik doe dit niet zomaar, maar omdat HTTP en web‑structuur het vereisen.”

7. Afsluiting: onthoud het web, niet het framework

Tot slot wil ik deze boodschap achterlaten:

Vergeet het framework niet te onthouden, maar begrijp hoe het web werkt.

Django is een uitstekend hulpmiddel om die kennis te vergaren. Als je die basis niet verliest, kun je:

• Nieuwe Django‑versies volgen
• Andere frameworks (Flask, FastAPI, Node, Spring, …) leren
• Nieuwe architecturen of cloud‑omgevingen omarmen

Je kunt altijd dezelfde vragen stellen:

• “Hoe behandelt dit systeem HTTP?”
• “Waar ligt de verantwoordelijkheid?”
• “Welke patronen worden verborgen?”

Met die basis blijf je een webontwikkelaar die niet vastzit aan één framework.