The Django Signals is a strategy to allow decoupled applications to get notified when certain events occur. Let’s say you want to invalidate a cached page everytime a given model instance is updated, but there are several places in your code base that this model can be updated. You can do that using signals, hooking some pieces of code to be executed everytime this specific model’s save method is trigged.
Since version 1.7, Django counts with the built-in
JsonResponse class, which is a subclass of
Its default Content-Type header is set to application/json, which is really convenient. It also comes with a
JSON encoder, so you don’t need to serialize the data before returning the response object.
The Django migration system was developed and optmized to work with large number of migrations. Generally you shouldn’t mind to keep a big amount of models migrations in your code base. Even though sometimes it causes some undesired effects, like consuming much time while running the tests. But in scenarios like this you can easily disable the migrations (although there is no built-in option for that at the moment).
Django models API offers two similar options that usually cause confusion on many developers:
I first started working with Django I couldn’t tell the difference and always ended up using both. Sometimes even using
The Django’s built-in authentication system is great. For the most part we can use it out-of-the-box, saving a lot of development and testing effort. It fits most of the use cases and is very safe. But sometimes we need to do some fine adjustment so to fit our Web application.