Using Pagination, Django Signals, and Custom Middleware

In Chapter 6, we learned how to integrate Redis into the Django project and utilize Redis as a caching layer. Caching is important to get performance gains, but at times, we would want to optimize the overall response sent to the client. This can be achieved by implementing pagination.

In this chapter, we will learn how to implement pagination in Django and Django Rest Framework (DRF). Along with that, we will focus on Django signals and how they help developers decouple logic between different apps. In Chapter 5, we saw how Django authentication and authorization support using Django middleware out of the box; now we will learn how to create custom middleware in Django.

We will cover these topics in this chapter:

• Paginating responses in Django and DRF
• Demystifying Django signals
• Working with Django middleware
• Creating custom middleware

Technical requirements

In this chapter, we will learn how to implement pagination in Django and DRF. We expect you to be familiar with the term pagination and how it is advantageous. Django signals and custom middleware are also advanced topics, so we expect you to be familiar with all the concepts we have covered in the previous chapters. You are expected to be familiar with the Django request-response cycle, which we discussed in Chapter 3.

Paginating responses in Django and DRF

When a request is sent by the client to fetch records from the server, it is not recommended to send all the entries present in the database in one go. This is when the concept of pagination comes into the picture. For example, if we have 1,000 blogs saved, sending all the blogs at once in response to the client’s request would increase the page load time and add performance bottlenecks to the system. To solve these problems, we will introduce the concept of pagination.

Understanding pagination

Let us take an example to understand the concept of pagination. A client requests to get a list of blogs, and we have 1,000+ blogs published on our website. We would send a few blogs in small batches, say 10 blogs every time. This is known as pagination. The user would interact with the UI and request the next batch of blogs. Different types of pagination can be implemented by the server for the API:

• Cursor API pagination
• Keyset...

Demystifying Django signals

Django has a lot of out-of-the-box features, but one feature that is underrated and stands out is Django signals. Django includes a “signal dispatcher” out of the box that helps developers write decoupled logic. A signal dispatcher would notify a set of receivers that some action has taken place. This is useful when we want to execute multiple actions for a single event. By default, Django provides a set of built-in signals that are useful for building common applications, as follows:

• Model signals – These are database action signals that can help developers trigger actions whenever some kind of database operation is about to be performed or is already being performed. Here is the list of default Django signals that are dispatched for certain Django model operation events:
  • pre_save and post_save – These signals are triggered before and after the model’s save() method is called. Please note that these signals are...

Working with Django middleware

Django middleware is a regular Python class that is hooked into Django’s request/response cycle. Middleware can be used to modify a request before Django views process them or modify a response before sending it back to the client. Every middleware is called twice during the request/response cycle – the first time is when the request is received from the client, and then the second time is when the response is sent back to the client.

By default, Django provides a lot of middleware and we also learned, in Chapter 3, how DRF also utilizes the Django middleware framework to integrate REST APIs. The default Django middleware is mainly used for authentication and is security-related. When we create a new project, Django automatically plugs in this middleware in the settings.py file:

MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",
    "django.contrib.sessions.middleware...

Creating custom middleware

Custom Django middleware should be used to execute code that we want to run for all the requests/responses. For example, we want to add a custom header to all the requests/responses, or we want to add logging or monitoring for requests. In Chapter 6, we learned how to use custom middleware to add get user_id for each request for logging. In this section, we will learn about the core concepts of custom middleware in Django.

Let us now check how to create a custom middleware in Django:

1. Create a file called custom_middleware.py (any other name can also be given). Add the following code to the common/custom_middleware.py file:

   class CustomMiddleware:
       def __init__(self, get_response):
         self.get_response = get_response
       def __call__(self, request):
         print("custom middleware before request view")
        ...

Summary

In this chapter, we have learned about three advanced concepts in Django. We have learned about the different concepts of pagination and how Django and DRF make use of pagination to improve the RESTful APIs. Next, we learned about the concept of Django signals and how Django provides out-of-the-box signals to decouple different application logic. Django also provides the interface to extend custom signals. Lastly, we learned about the Django middleware concepts. Django middleware is used to modify request/response objects. We also learned how to create custom middleware and use it in our Django project.

In this chapter, we have learned all the advanced concepts of Django that any developer should be comfortable implementing, in order to write scalable Django applications.

In the next chapter, we will focus on learning about distributed task queue programming with Django. Celery is one of the most popular Python frameworks that is used along with Django to implement long...