Request-Response Flow
Django tl;dr
It handles request-response patterns between the client, usually a browser , and an http server
It sources data from auto-generated sql
queries, each called a Queryset
.
Server-side Views
are templates, built with html
, css
, and js
, rendered via browser response.
It goes further by including the kitchen sink, i.e.
orm-sql
for many sql enginesdtl/jinja
templating language,seo
rss
, etc.
flowchart LR
subgraph request
url
end
subgraph server
django
subgraph batteries
orm
dtl
seo
rss
end
end
subgraph response
html
css
js
end
request--url endpoint--->django--route to view-->response
request to server
We start with a url.
runserver
gives us: http://127.0.0.1:8000/.
Opening this url in the browser initiates an HttpRequest
to a server.
Dissect Runserver Prompt
Let's parse lines 8 and 9:
config.settings
implies that, for this particular Django instance, the main project folder is namedconfig
.- Django's local development server is running at a specific URL:
http://127.0.0.1:8000/
- While this is running, I can type the said URL in a browser and hit enter.
- I can expect that a
HttpRequest
will be sent to this running server. - The server receives the request and returns, to the requesting browser, some
html
,css
, andjs
as anHttpResponse
. - This pattern is known as the request-response cycle.
- Django will now look for an appropriate
urlpattern
route that matches the URL.
In local environments, the server is django's runserver
. In production environments, a popular choice of server is gunicorn.
server to router + view
Django matches the url endpoint to a developer-defined UrlPattern
route.
What is the endpoint? Well, it's the tip of the url. So the router's matching process goes something like this for url http://127.0.0.1:8000/:
- does the endpoint of http://127.0.0.1:8000/ match
/about? No. - does the endpoint of http://127.0.0.1:8000/ match
/contact-us? No. - does the endpoint of http://127.0.0.1:8000/ match /? Yes.
Dissect URL Routing
More technically, if the requested url is http://127.0.0.1:8000/, this represents an empty string ""
following the backslash "/". How do we find the matching pattern in the code?
If we look inside the config.settings.base
module, there are many variables but our interest is in:
This declares Django's routing system to be controlled by a urls.py
file found in the config
folder:
server sends response containing a view
The endpoint / is typically the homepage of the website.
It's up to the developer to construct how this View
looks like, typically by combining html
, css
, and js
with data that is persisted in a database.
So the route to / represents a pre-constructed homepage View
.
Dissect View Templating
Django offers some class-based views to make displaying content simpler. In this case, we're using a minimal TemplateView
(which inherits from View
) relying on a certain "home.html". Where do we find this "home.html"?
In our Django config.settings.base
module, we determine where to source templates:
Templates Directory | |
---|---|
The content of home.html
is what the browser will receive as a response. Although this doesn't look like much, it can contain subtemplates as implied by the very first line. If we look at the refernced "base.html" in Line 1,
we can see the full page of "home.html"
In the /templates
directory, we see "home.html" which contains the following content:
{% load static %}
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="description" content="Sample description "> <!-- # Customize content for search -->
{% block title %}<title>Test site sample</title> {% endblock title %}<!-- Enable title changes -->
{% include './_favicons.html' %}
{% block custom_css %}
<link rel="stylesheet" href="https://unpkg.com/@picocss/pico@1.*/css/pico.min.css">
{% block extra_css %}
{% endblock extra_css %}
{% endblock custom_css %}
</head>
<body class="container">
{% include './nav.html' %}
{% include './_messages.html' %}
{% block body %}
{% block content %}
<!-- This is what "home.html" populates -->
{% endblock content %}
{% block base_js %}
<script src="https://unpkg.com/htmx.org@..."></script>
<script src="https://unpkg.com/hyperscript.org@..."></script>
<script>document.body.addEventListener("htmx:configRequest", (e) => {e.detail.headers["X-CSRFToken"] = "{{ csrf_token }}";});</script>
{% block extra_js %}
{% endblock extra_js %}
{% endblock base_js %}
{% endblock body %}
</body>
</html>
Summary
We started with a requesting url http://127.0.0.1:8000/ and retrieved a viewable response.
- The url's endpoint / made an
HttpRequest
to the server. -
server pinged routing and it replied with:
"Yes, I have a
View
representing request to endpoint /" -
This
View
is packaged into aHttpResponse
for rendering in the browser. - Since the
View
will likely contain other urls... we can expect more request-response cycles.