Context processors vs middleware in django

Middleware acts as a hook into Django's request/response processing at a low level and it is light. The hooks are available for request, response, view, template_response, and exception processing. The hook might need to modify the request before the view handles it, it might need to log information about the request for debugging purposes, check a cookie to set the local, and so on.

Read more on Middleware.

Context processors just modify the context. Context is a key value mapping with variables passed to a template. A context processor takes a request object as its argument, and returns a dictionary of items that get merged into the context. The context gets rendered to your template as per your view and it attaches whatever else your context processors merge in. You can think of it as a global context variable(s), available to you at all your templates.

Read more on Context Processors.

Both are fairly simple to write and have their purpose. Here is a diagram that shows where middleware and context fit in in a typical django flow:

Django Flowchart

1. User requests a page

2. Request reaches Request Middlewares, which could manipulate or answer the request

3. The URLConffinds the related View using urls.py

4. View Middlewares are called, which could manipulate or answer the request

5. The view function is invoked

6. The view could optionally access data through models

7. All model-to-DB interactions are done via a manager

8. Views could use a special context if needed

9. The context is passed to the Template for rendering

Context processors are used to provide the templates with extra data. Middleware is for intercepting the request/response objects, and modifying them (or triggering other behaviour) in some meaningful way.

They work in different level of stack for different context. Its normally hard to keep stacks of a framework to be absolutely orthodox, especially the only thing a web framework like Django processing are request and response. Yes, we could use request.user, instead of context.user by context_processor when rendering template. But you might don't want attributes which are only used in template, are set on every request.

Also, decorator is flexible than middleware for view-level operation, but its hard to say middleware is a decorator-lite. I'd like to treat context processors as assignment template tags but loaded automatically, by the way.