When onboarding a few new team members (all with Rails backgrounds) onto our well-established Django project, a few questions kept coming up: * How do I change the value of this variable I'm passing down to the template? * Why does this particular method get called when a user visits a particular URL? * How does a request get from the server into the Django process? * I haven't set this variable, and yet it's showing up fine in my template - why? After helping out answering these, it became evident that what I thought was a cleanly and obviously laid-out framework with a clear path in an out...wasn't, at least to people new to the project. With that in mind, this talk will address a few fundamental components in the pathway on which a request turns into a response. Specifically, it will discuss: * A brief history of WSGI - how we ended up with that as a standard, and what problems it's solving (and opportunities it's opening up) for us as a language. * The role of middleware as a cross-cutting plugin system that hooks into the request/response cycle, but without a context. Unlike most other things, why it get runs (in different ways) on both the request- and response-sides, and what this makes it easy to do. * URL dispatching from the prespective of someone who's never used routes before, and how it makes sense to separate the external and internal representations of a resource. * What precisely it is that makes up a view function, and how we can have two structures - class-based views and function-based views - which look totally differernt, but work out being the same effective thing. * Context processors, and their role as the middleware of templates. In the process of that discussion, this talk will weave together all these concepts into a streamlined walk though Django's request system, and how a GET from your browser ends up returning meaningful content.