Deployment seems to be an area a lot of Django developers struggle with. There are a ton of options out there and every tutorial seems to advocate for a specific way. The official Django docs intentionally (and perhaps wisely) does not go too deep into the topic and as a result a lot of new Django developers struggle with the topic of deployment.
Docker. What is it? What’s all the hype about? Should you learn it? Should you use it? What benefits do you get from it compared to a virtual environment? In this article we attempt to answer these questions.
Environment variables are basically variables that are loaded in the operating system on which your Django project is running.
They are often used to provide values for
settings.py variables such as
“What is the difference between Authentication and Authorization?”
A question often arises when Django projects start to grow: “Where to put all the queries?” When it comes to this question, a good concept to have in mind is fat models and thin views. This means that, as much as possible, you should try to keep business logic out of views and closer to your models.
In this article, I will explain how to programmatically populate data in a database during a migration. This technique is particularly useful when we want to add a new field to a model where the value of the new field can be determined by the other fields of the model.
In this post I will go through some common authentication mechanisms that are used in Django REST Framework (DRF). Some of these methods are included in DRF, and the others are custom authentication packages that implement popular schemes not included in DRF. We will go through how each scheme works and when it should be used. I have also included some resources for learning how to implement each.
For my recent project pyremote, I needed to run a script every night to remove old job postings from the database. I decided to implement it as a custom manage.py command so that I can easily run it from command line and add it to a nightly cron job on the server.
In this guide I show you how to run your Django app in one Docker container and your PostgreSQL database in another and make them talk to each other. We are going to manage and run these two containers using Docker Compose.
If you are here, I assume you have already embraced the merits of using Docker to set up your development environment such that it matches your staging and production environments. In this guide I show you how to run your Django app in one Docker container and your MySQL database in another and make them talk to each other. We are going to manage and run these two containers using Docker Compose.
Do you feel that learning Django was harder than you anticipated? Or that even though you have followed some tutorials, you still don’t have a grasp over what Django does? and how?
Usually instances of models (objects) are created using a
ModelForm. You know the drill: The user inputs some values in the form, hits submit and sends a
POST request with the data. In the view function, we do a model validation using
form.is_valid() and then save the object in the database. This gives a basic level of validation for the model fields.
Subscribe via RSS