Django comes equipped with a powerful feature known as signals. Signals provide a way to allow various parts of your application to communicate asynchronously, enabling modular and extensible behavior. In this blog post, we'll take a closer look at some of the built-in signals Django offers, along with their usage and significance.

1. Model Signals: One of the most frequently used types of signals in Django is related to models. These signals are emitted by the Django ORM before or after certain model-related operations. For instance, the pre_save and post_save signals are sent before and after saving a model instance, respectively. Similarly, signals like pre_delete and post_delete are dispatched before and after deleting a model instance.

By connecting receiver functions to these signals, developers can perform additional tasks or execute custom logic when specific model-related events occur. For example, you might want to update related records in the database after a certain model instance is saved, or trigger notifications when a model instance is deleted.

• pre_save: Sent just before a model's save() method is called.

• post_save: Sent just after a model's save() method is called.

• pre_delete: Sent just before a model's delete() method is called.

• post_delete: Sent just after a model's delete() method is called.

• m2m_changed: Sent when a many-to-many relation is modified.

2. Authentication Signals: Django's authentication system also emits signals during user authentication-related events. Signals such as user_logged_in and user_logged_out are sent when users successfully log in or log out of the system. These signals are invaluable for implementing additional functionality, such as recording login/logout timestamps, updating user activity logs, or sending email notifications upon user login.

• user_logged_in: Sent when a user logs in.

• user_logged_out: Sent when a user logs out.

• user_login_failed: Sent when a login attempt fails.

3. Request/Response Signals: Django provides signals that allow you to hook into the request/response cycle of your web application. Signals like request_started and request_finished are dispatched when HTTP requests begin and end processing, respectively. These signals can be useful for tasks such as logging request metadata, capturing performance metrics, or implementing custom request/response middleware.

• request_started: Sent when an HTTP request begins processing.

• request_finished: Sent when an HTTP request finishes processing.

• got_request_exception: Sent when an exception occurs while processing an HTTP request.

4. Management Signals: Additionally, Django emits signals during the execution of management commands, which are used for administrative tasks like database migrations, collecting static files, and running tests. Signals such as pre_migrate and post_migrate are sent before and after database migrations are applied, allowing developers to perform setup or cleanup tasks as needed.

• pre_migrate: Sent before a migration is applied.

• post_migrate: Sent after a migration is applied.

• setting_changed: Sent when a Django setting is changed.

5. Other Signals: These are miscellaneous Signals that dont fit on above 4 categories, There is no further difference between them.

• class_prepared: Sent when a model class has been prepared.

• template_rendered: Sent when a template is rendered.

• setting_changed: Sent when a Django setting is changed.

• connection_created: Sent when a database connection is created.

Conclusion:

In conclusion, built-in signals in Django provide a flexible and powerful mechanism for extending and customizing the behavior of your web applications. By leveraging signals, developers can decouple different parts of their codebase, promote reusability, and maintain clean, modular architecture. Whether you're working with models, authentication, request handling, or management commands, Django's signals offer a robust toolkit for implementing advanced functionality and responding to various events within your application.