DEV Community: CH S Sankalp jonna

Managing concurrency in Django using select_for_update

CH S Sankalp jonna — Sun, 18 Jul 2021 02:37:39 +0000

If you ever plan to run multiple processes for the same server code, it is inevitable that you have to deal with the age-old problem of managing concurrency.

The Django ORM is no different. If you call the save() method on an object, there is a good chance that two different instances of your server call this method on the same object at the same time causing your data to get corrupted.

Consider the example of an account model that is responsible for storing how much bank balance somebody has in their account:

from django.db import models

from django.contrib.auth.models import User
from django.db import models, transaction

class Account(models.Model):
    balance = models.IntegerField(default=0)
    user = models.ForeignKey(User)

    def deposit(self, amount):
        self.balance += amount
        self.save()

    def withdraw(self, amount):
        if amount > self.balance:
            raise errors.InsufficientFunds()
        self.balance -= amount
        self.save()

As you can see, there are two methods included in this model to deposit and withdraw money into the account.

Seems straightforward enough right? Nothing could go wrong here right? Its basic addition and subtraction right? WRONG!

The classic concurrency problem

Let’s say there is an account with a Balance of $1000 in it which is accessible by 2 different users. Think of it as a joint account.

Now let’s say User1 is the earner and User2 is the spender. User1 deposited 100$ into the account and therefore the server invoked account.deposit(100) but at the exact same time, User2 withdrew $100 thus invoking account.withdraw(100).

What should happen in this case? Ideally the balance at the end of these two transactions should remain 1000$ right? If you are running a single instance of your server, this would indeed be the case because these two transactions would always run one after another.

But if these transactions are run by different instances of your server in parallel, there is a good chance that the balance at the end of it would be $900. Why does this happen?

Here are the steps that occur in these transactions

Step 1: User1 retrieves the account

Balance is $1000

Step 2: User2 retrieves the account

Balance is $1000

Step 3: User1 deposits $100

Balance is $1000 + $100 = $1100

Step 4: User2 withdraws $100

Balance is $1000 - $100 = $900

In step 4, the balance that the server has loaded into memory is stale because it was already updated to $1100 in step 3 which the other server instance was not aware of and hence it thinks that the current balance is still $1000.

This is the classic concurrency problem and thankfully this age-old problem has an age-old solution.

Solution to the concurrency problem

The solution is quite simple. When a database operation is in progress, the object or the set of objects that are being updated must be locked until the operation is complete so that no other process can access this object/objects.

This will prevent multiple instances of a server from loading stale data into memory and corrupting the database.

The best place to lock an object is to do it at the database level as opposed to the application level. This will protect your data from getting corrupted by other processes such as cron jobs as well.

Besides, when you run multiple workers of your Django application, it can be a pain to maintain locks at the application level because you would need to use some other 3rd party tool that stays in sync across all your workers to achieve a global lock.

What is select_for_update in Django?

The select_for_update method offered by the Django ORM solves the problem of concurrency by returning a queryset that locks all the rows that belong to this queryset until the outermost transaction it is inside gets committed thus preventing data corruption.

Here is how you can modify the Account model to use select_for_update and lock the account object:

from django.db import models

from django.contrib.auth.models import User
from django.db import models, transaction

class Account(models.Model):
    balance = models.IntegerField(default=0)
    user = models.ForeignKey(User)

    def get_queryset(self):
        return self.__class__.objects.filter(id=self.id)

    @transaction.atomic()
    def deposit(self, amount):
        obj = self.get_queryset().select_for_update().get()
        obj.balance += amount
        obj.save()

    @transaction.atomic()
    def withdraw(self, amount):
        obj = self.get_queryset().select_for_update().get()
        if amount > obj.balance:
            raise errors.InsufficientFunds()
        obj.balance -= amount
        obj.save()

To acquire a lock, we need to fetch the object from the database using select_for_update. Operating on the self object will not work since it has already been fetched. This is why the above code has a method defined called get_queryset where we fetch the object that is being operated on at the time of withdrawal/deposit.

Do keep in mind that for this to work, the database that you are using must support transactions and locks. If you are using SQLite, select_for_update is pretty much useless. My personal recommendation would be to use PostgreSQL.

Database operations after introducing select_for_update

The steps that have been defined in the concurrency problem above will now change to this:

Step 1: User1 raises request to deposit $100

User1 acquires a lock on the account
Balance is $1000

Step 2: User2 raises request to withdraw $100

User2 attempts to acquire a lock which fails because the account has already been locked by User1
User2 waits for the lock to be released

Step 3: User1 deposits $100 into the account

Balance is $1000 + $100 = $1100
Lock on the account by User1 is released
User2 acquires the lock on the account soon after.

Step 4: User2 withdraws $100 from the account

- Balance is $1100 - $100 = $1000

- Lock on the account by User2 is released.

Step 5: Balance is $1000 and the data is free of corruption.

Conclusion

When you run multiple workers of your Django application, you will run into concurrency issues when the same queryset is updated by different processes at the same time.

To prevent this, use select_for_update inside a transaction block to fetch your queryset so that it is locked until the transaction is completed.

Originally posted on my blog

Use get_object_or_404 in Django to write lesser code

CH S Sankalp jonna — Sun, 27 Jun 2021 02:49:32 +0000

Django has a few nifty shortcuts that can be used to make your life easier. The get_object_or_404 method is one of them.

I always believe that as a software developer, one should write as little code as possible and this method helps you do the same.

What is get_object_or_404 in Django?

To put it simply, it is a shortcut that can save you the trouble of writing redundant code every time you need to query a particular object from the database.

An API that needs to retrieve an object from the database usually works in this way: If the object exists, return it and if not, return a 404 status code.

For the sake of an example, let us consider a model called Record that is defined as follows:

from django.db import models

class Record(models.Model):
  # id will be created automatically
  name = models.CharField(max_length=255)
  created_at = models.DateTimeField(auto_now_add=True)
  is_deleted = models.BooleanField(default=False)

If you had to write an API to fetch a particular Record object using the id field. It would look something like this:

from rest_framework import generics
from .models import Record
from django.http import Http404


class RecordRetrieveView(generics.RetrieveAPIView):
    serializer_class = RecordSerializer

    def get_object(self):
        try:
          return Record.objects.get(id=self.request.query_params['id'])
        except Record.DoesNotExist:
          raise Http404()

These 4 lines of code can be converted into a single line of code using get_object_or_404:

from rest_framework import generics

from django.shortcuts import get_object_or_404

class RecordRetrieveView(generics.RetrieveAPIView):

    serializer_class = RecordSerializer

def get_object(self):
    return get_object_or_404(Record, id=self.request.query_params['id'])

TL;DR

To retrieve objects from a database, use get_object_or_404 as opposed to getting the object using the ORM way and throwing an exception if it does not exist. This method pretty much does the same thing under the hood.

Save your Django models using update_fields for better performance

CH S Sankalp jonna — Sun, 13 Jun 2021 03:11:57 +0000

The Django ORM is designed to turn the rows of your database tables into objects that can then conform to object oriented principles. This makes it very easy to create, update and delete entries from your database.

However, there are certain advantages to using raw queries instead of an ORM. For instance when you update a row in your table, you might want to update only a subset of the columns in that row and not all of the columns.

Saving a Django model object updates all your columns every single time you call a save() method. To prevent this from happening you must be explicit.

What save() does internally

Consider a Django model called Record which has the following fields:

from django.db import models

class Record(models.Model):
  # id will be created automatically
  name = models.CharField(max_length=255)
  created_at = models.DateTimeField(auto_now_add=True)
  is_deleted = models.BooleanField(default=False)

If you would like to update the name of a record you might do something like this

>>> record = Record.objects.get(id=1)
>>> record.name = "new record name"
>>> record.save()

If you turn on logs in the underlying database that you are using which in my case is Postgres, the query that actually runs is this:

UPDATE "record"
SET    "name" = 'new record name',
       "created_at" = '2021-06-12T15:09:05.019020+00:00' :: timestamptz,
       "is_deleted" = FALSE
WHERE  ""id" = 1

This may not seem like a big deal, but what if your model consisted of 20 fields and you run a save() operation on it very frequently?

At a certain scale the database query that updates all of your columns every time you call save() can start causing you some unnecessary overhead.

Why is the overhead unnecessary? Because it can be prevented with a simple tweak.

Use update_fields in save()

If you would like to explicitly mention only those columns that you want to be updated, you can do so using the update_fields parameter while calling the save() method.

>>> record = Record.objects.get(id=1)
>>> record.name = "new record name"
>>> record.save(update_fields=['name'])

The underlying query now becomes

UPDATE "record"
SET    "name" = 'new record name'
WHERE  "record"."id" = 1

You can also choose to update multiple columns by passing more field names in the update_fields list.

This is clearly a more efficient way to run your queries and will save you some database overhead.

TL;DR

If you use the save() method with the intention of updating some specific columns in your database row, explicitly mention those fields by using the update_fields parameter and calling the save() method like this:

obj.save(update_fields=['field_1', 'field_2']) as opposed to just obj.save()

This will save you some database overhead by making the underlying query more efficient.

Write better queries using values_list in Django

CH S Sankalp jonna — Sun, 30 May 2021 02:42:23 +0000

The Django ORM is great but it may not always be a good idea to use it in its most primitive state as it could lead to inefficient queries.

For instance, consider a database model called Record that consists of id, name, created_at and an is_deleted flag indicating whether it has been deleted or not.

from django.db import models

class Record(models.Model):
  # id will be created automatically
  name = models.CharField(max_length=255)
  created_at = models.DateTimeField(auto_now_add=True)
  is_deleted = models.BooleanField(default=False)

When you query using Record.objects.filter(is_deleted=False), the underlying database query looks something like this:

SELECT id,
       name,
       created_at,
       is_deleted
FROM   records
WHERE  NOT is_deleted;

Not only is this querying all fields of the table but it returns a queryset of model instances like this:

>>> Record.objects.filter(is_deleted=False)
<QuerySet [<Record: Record object (1)>, <Record: Record object (2)>, <Record: Record object (3)>]>

In most cases you do not require all of the fields of your model. What is even worse is that if your Record model consists of 10 fields, this query will end up fetching all of them from the database making your query significantly slower.

Fortunately there are two very straightforward ways to make this query efficient. You could either use values or values_list.

Using values() to retrieve specific DB columns

Let’s say you want to display the names of all the records that have not been deleted. You can retrieve only the name column from the database by making a slight modification to the ORM query:

>>> Record.objects.filter(is_deleted=False).values('name')
<QuerySet [{'name': 'First record'}, {'name': 'Second Record'}, {'name': 'Third Record'}]>

As you can see, instead of returning a list of Record objects, this queryset returns a list of dictionaries that consist of just the name field. The underlying query now becomes:

SELECT name
FROM   records
WHERE  NOT is_deleted;

You can fetch more columns if you wish by providing the list of columns that you need in the values() method.

>>> Record.objects.filter(is_deleted=False).values('id', 'name')
<QuerySet [{'id': 1, 'name': 'First record'}, {'id': 2, 'name': 'Second Record'}, {'id': 3, 'name': 'Third Record'}]>

Using values_list() to retrieve specific DB columns

This works pretty much the same way as values() except that it returns a tuple instead of a dictionary:

>>> Record.objects.filter(is_deleted=False).values_list('name')
<QuerySet [('First record',), ('Second Record',), ('Third Record',)]>
>>>
>>> Record.objects.filter(is_deleted=False).values_list('id', 'name')
<QuerySet [(1, 'First record'), (2, 'Second Record'), (3, 'Third Record')]>
>>>

The nifty thing about values_list() is that if you only need to pass in a single field, you can use the flat=True parameter to return a list of single values instead of tuples.

>>> Record.objects.filter(is_deleted=False).values_list('name',flat=True)

<QuerySet ['First record', 'Second Record', 'Third Record']>

Closing notes

In terms of performance, there is no difference between values() and values_list().

They are both intended as optimizations for retrieving a subset of data while avoiding creation of model instances and making the database query more efficient by only selecting specific fields.

The decision of which one of these to use depends on what kind of data structure you prefer to work with.

I usually find a dictionary more intuitive than a tuple and hence prefer values() over values_list(). However if I only need one field from the query I prefer to use values_list() with flat=True.

Originally posted on my blog

Using abstract models in Django

CH S Sankalp jonna — Sun, 23 May 2021 03:26:36 +0000

One of the principles of Python is “Do not repeat yourself”. Abstract models in Django are meant to do exactly that.

If you are designing a database for a school, there would be database models representing all types of people who attend this school which includes the students, teachers, cleaning staff, cafeteria staff, school bus drivers, etc.

However, all of these folks have some common information such as name, date of birth, date of joining, address and contact information, etc.

It doesn't seem right to repeat all of these fields for each database model while writing the code, and this is where abstract models work great.

How to create an abstract base model?

All you have to do is create a base model with all the common fields and set abstract = True in the meta class.

This will ensure that there is no actual database table created for this base model and it is meant only for being inherited by other models that actually become tables in the database.

from django.db import models

class Person(models.Model):
    name = models.CharField(max_length=255)
    date_of_birth = models.DateTimeField()
    date_of_joining = models.DateTimeField()
    address = models.TextField()

    class Meta:
        abstract = True

class Student(Person):
    roll_number = models.IntegerField()


class Teacher(Person):
    compensation = models.CharField(max_length=255)

After running migrations, there will be a student table and a teacher table created in your database while the person model stays in your codebase ready to be inherited in another model if you chose to.

Abstract as much as possible

The “Do not repeat yourself” principle does not have to end here. For instance, even though the folks belonging to the cleaning staff and cafeteria staff are also persons, they both have shift timings which students and teachers do not.

from django.db import models

#======= Abstract models =========#
class Person(models.Model):
    name = models.CharField(max_length=255)
    date_of_birth = models.DateTimeField()
    date_of_joining = models.DateTimeField()
    address = models.TextField()

    class Meta:
        abstract = True

class SchoolEmployee(Person):
    compensation = models.CharField(max_length=255)

    class Meta:
        abstract = True

class HiredHelp(SchoolEmployee):
    shift_timings = models.JSONField()

    class Meta:
        abstract = True
#--------------------------------#

#======= Actual models ==========#
class Student(Person):
    roll_number = models.IntegerField()

class Teacher(SchoolEmployee):
    qualifications = models.JSONField()

class CafeteriaEmployee(HiredHelp):
    pass

class CleaningStaffMember(HiredHelp):
    pass
#--------------------------------#

Depending on your requirement you can have further abstract models that inherit from other abstract models.

Closing notes

It is important to keep in mind that abstract models by themselves are quite useless. There is no database table created for them and hence they are of no consequence.

Abstract models are only useful if you intend to create other models which inherit from the abstract ones.

Abstract classes are a good example of how the concept of inheritance can be used to write reusable code.

Originally posted on my blog

Representing foreign key values in Django serializers

CH S Sankalp jonna — Sun, 09 May 2021 03:36:00 +0000

The primary purpose of a serializer is to convert a Django model or rather a database table into a format that can be transferred over the internet such as a JSON output or an XML output.

This becomes slightly tricky when you have two models that are related to each other through a foreign key or a many to many relationship.

Serializing a model that contains a foreign key to another model can be done in various ways depending on what you plan to do with this data. Most widely used method is to use a nested serializer.

Using a nested serializer

Consider the relationship between a song and an artist. There could be multiple songs each of which may belong to the same artist thus requiring the need for a foreign key.

from django.db import models

class Artist(models.Model):
  name = models.CharField(max_length=255)

  def __str__(self):
    return self.name

class Song(models.Model):
  name = models.CharField(max_length=255)
  artist = models.ForeignKey(Artist, related_name="songs", on_delete=models.CASCADE)

  def __str__(self):
    return self.name

Let’s say that we want to present the Artist model in a way that it includes all the songs recorded by that artist. This can be achieved using a nested serializer.

from rest_framework import serializers
from .models import Song, Artist


class SongSerializer(serializers.ModelSerializer):
    class Meta:
      model = Song
      fields = ('id', 'name', 'artist')

class ArtistSerializer(serialisers.ModelSerializer):
  songs = SongSerializer(many=True)

  class Meta:
    model = Artist
    fields = ('id', 'name', 'songs')

Upon using the ArtistSerializer, the response that is returned will look like this

{
  "id": 1,
  "name": "Beatles",
  "songs": [
    {
      "id": 1,
      "name": "I am the walrus"
    },
    {
      "id": 2,
      "name": "Come together"
    }
   ]
}

By default, a nested serializer is read only. To use this serializer for validating an input and write data into the DB, one must explicitly override the create() or update() methods as shown below:

from rest_framework import serializers
from .models import Song, Artist


class SongSerializer(serializers.ModelSerializer):
    class Meta:
      model = Song
      fields = ('id', 'name', 'artist', 'duration_in_seconds')

class ArtistSerializer(serialisers.ModelSerializer):
  songs = SongSerializer(many=True)

  def create(self, validated_data):
    songs_data = validated_date.pop("songs")
    artist = Artist.objects.create(**validated_data)
    for song_data in songs_data:
      Song.objects.create(artist=artist, song=**song_data)
    return artist

  class Meta:
    model = Artist
    fields = ('id', 'name', 'songs')

Using default serializer relations

Writing nested serializers can usually be avoided by using the various types of serializer relations provided by the Django REST framework that you can find here.

In this tutorial, we will be covering PrimaryKeyRelatedField and SlugRelatedField. The rest of the serializer relation types are pretty similar and can be used interchangeably with these depending upon your use case.

In each of these types, you can create read only serializers by setting read_only=True or you can also use these to write data by validating inputs.

If you wish to make them writable, you simply have to include a queryset parameter in the serializer along with read_only=False which will be used to validate the inputs.

Let’s take a look at the most commonly used serializer relation to explain this further

PrimaryKeyRelatedField

If you already have the individual objects of the related fields, you can only serialize the primary key in order to identify the objects.

from rest_framework import serializers
from .models import Song, Artist

class ArtistSerializer(serialisers.ModelSerializer):
  songs = serializers.PrimaryKeyRelatedField(many=True, read_only=True)

  class Meta:
    model = Artist
    fields = ('id', 'name', 'songs')

This would get serialized as follows:

{
  "id": 1,
  "name": "Beatles",
  "songs": [
    1,
    2
   ]
}

To make this serializer writable, use the following arguments:

from rest_framework import serializers
from .models import Song, Artist

class ArtistSerializer(serialisers.ModelSerializer):
  songs = serializers.PrimaryKeyRelatedField(
    many=True, 
    read_only=False,
    queryset=Song.objects.all()
  )

  class Meta:
    model = Artist
    fields = ('id', 'name', 'songs')

SlugRelatedField

If the target of the relationship needs to be represented using a field other than the primary key, you can specify the field you would like to use.

from rest_framework import serializers
from .models import Song, Artist

class ArtistSerializer(serialisers.ModelSerializer):
  songs = serializers.SlugRelatedField(
    many=True, 
    read_only=True,
    slug_field="name"
  )

  class Meta:
    model = Artist
    fields = ('id', 'name', 'songs')

This would get serialized as follows:

{
  "id": 1,
  "name": "Beatles",
  "songs": [
    "I am the walrus",
    "Come together"
   ]
}

Closing notes

If you need complete control over how objects and relationships are created/represented at the time of serializing data or if you need to display the entire object at the time of serialization, using nested serializers is a better approach.

However if you are building an application where you already have access to the related models and you only need an identifier to reference them, I would recommend using one of the inbuilt serializer relations.

The above methods of handling foreign key relations in serializers are not just for ForeignKey fields. They also apply for ManyToManyField and OneToOneField.

Error handling for Django applications using email

CH S Sankalp jonna — Sun, 18 Apr 2021 05:01:35 +0000

When you deploy any application to production, there is always this inherent anxiety - what would happen if there are unhandled exceptions?

When an unhandled exception occurs in your Django application, it leads to an internal server error and returns a 500 error code to the client. Completely avoiding such exceptions is usually not possible.

What you can do though is have eyes on your application. A mechanism to get alerted whenever such an exception occurs so that you can take action immediately.

There are several ways to do this. You could use a tool like Sentry which gives you a very comprehensive stack trace along with the offending request that caused the error.

However, the simplest way to do this is to send an email to yourself with the stack trace of the exception.

Fortunately, Django already thought of this and has a pretty straightforward mechanism to email yourself with exceptions using the ADMINS setting. Whenever an error occurs, if DEBUG is set to False, Django will email all the IDs mentioned in ADMINS.

Format of the error email

Before we get into what settings need to be configured to send the email, let us look at what the email looks like.

I am currently building an app called DailyHabits and I will emulate an error by adding a line of code that divides a number by zero.

This will make sure that the server throws an error when this code is invoked. I will then fire an API call that invokes this particular code and and receive an email that contains this in the body:

Traceback (most recent call last):
  File "/Users/sankalpjonna/habbit_tracker/venv/lib/python3.8/site-packages/django/core/handlers/exception.py", line 47, in inner
    response = get_response(request)
  File "/Users/sankalpjonna/habbit_tracker/venv/lib/python3.8/site-packages/django/core/handlers/base.py", line 179, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/Users/sankalpjonna/habbit_tracker/venv/lib/python3.8/site-packages/django/views/decorators/csrf.py", line 54, in wrapped_view
    return view_func(*args, **kwargs)
  File "/Users/sankalpjonna/habbit_tracker/venv/lib/python3.8/site-packages/rest_framework/viewsets.py", line 125, in view
    return self.dispatch(request, *args, **kwargs)
  File "/Users/sankalpjonna/habbit_tracker/venv/lib/python3.8/site-packages/rest_framework/views.py", line 509, in dispatch
    response = self.handle_exception(exc)
  File "/Users/sankalpjonna/habbit_tracker/venv/lib/python3.8/site-packages/rest_framework/views.py", line 469, in handle_exception
    self.raise_uncaught_exception(exc)
  File "/Users/sankalpjonna/habbit_tracker/venv/lib/python3.8/site-packages/rest_framework/views.py", line 480, in raise_uncaught_exception
    raise exc
  File "/Users/sankalpjonna/habbit_tracker/venv/lib/python3.8/site-packages/rest_framework/views.py", line 506, in dispatch
    response = handler(request, *args, **kwargs)
  File "/Users/sankalpjonna/habbit_tracker/venv/lib/python3.8/site-packages/rest_framework/mixins.py", line 19, in create
    self.perform_create(serializer)
  File "/Users/sankalpjonna/habbit_tracker/venv/lib/python3.8/site-packages/rest_framework/mixins.py", line 24, in perform_create
    serializer.save()
  File "/Users/sankalpjonna/habbit_tracker/venv/lib/python3.8/site-packages/rest_framework/serializers.py", line 205, in save
    self.instance = self.create(validated_data)
  File "/Users/sankalpjonna/habbit_tracker/habbits/serializers.py", line 28, in create
    print(100/0)

As you can see, the email contains a full stack trace of the exception which you can use to find the exact line in your codebase which is causing it.

This is the simplest form of error handling and is quite nifty because you most likely receive email notifications on your phone and therefore you will be immediately notified when there is an error in your application.

You now have eyes on your application's health.

Using gmail to send error emails

In order to send the email, there are a few settings that you need to configure in settings.py. You can send the emails using your own gmail account by setting up the smtp credentials as shown below.

ADMINS = [
    ('Your name', 'your-alerts-email@provider.com'),
]

EMAIL_USE_TLS = True
EMAIL_PORT = 587
EMAIL_HOST = 'smtp.gmail.com'
EMAIL_HOST_USER = 'yourmail@gmail.com'
EMAIL_HOST_PASSWORD = 'gmail-password'

You can get more details about this in the Django error reporting section

However, for this to work you would have to allow gmail to let you access it via a non gmail app. You can do this in the security settings.

Click on your account profile on top right -> Manage your Google Account -> Security -> Less secure app access -> Turn on access

However, this method is not recommended. It leads to security vulnerabilities, not to mention the fact that you have your gmail account password somewhere in your codebase.

You can protect the password by not using it directly in your codebase and setting it up in the environment variables instead.

You can further strengthen security by creating a new gmail account whose sole purpose will be for sending error emails. This way, even if this account gets compromised it won't really affect you much. It is more of a burner email.

If you are wondering if it’s worth going through so many hoops and leave yourself open to security issues, you are right. Which is why I recommend using mailgun instead of your personal gmail account to send error emails.

Using mailgun to send error emails

I recommend mailgun for three reasons:

They have comprehensive APIs that let you send all kinds of emails.
You can send upto 6k emails a month in their free plan.
It is relatively easy to set up.

To send emails using mailgun, signup for an account on mailgun, and create a new domain. I have already set up a domain called dailyhabits.xyz which I own.

The process will involved setting up a few DNS records in my domain provider to prove to mailgun that I own the domain.

Once this process is complete, you can create a new SMTP user for sending error emails.

You can do so by going to Domain settings -> Add new SMTP user in the mailgun dashboard.

After a credential is created, you will be allowed to copy the password to the clipboard post which the password will no longer be available to you unless you explicitly reset it.

Make sure you copy the password and save it somewhere.

The smtp credentials to configure in settings.py will be as follows:

ADMINS = [
    ('Server Alerts', 'hello@dailyhabits.xyz'),
]

EMAIL_USE_TLS = True
EMAIL_PORT = 587
EMAIL_HOST = 'smtp.mailgun.org'
EMAIL_HOST_USER = 'server-alerts@mg.dailyhabits.xyz '
EMAIL_HOST_PASSWORD = '---password copied earlier from mailgun-----'

And that’s it. We are all set up.

Closing notes

Error handling requires two things.

Getting notified when there is an error in your server.
A way to trace the line of code which is causing the error.

Both of these requirements get solved with this simple mechanism of sending an email to yourself.

It functions as a notification that is hard to miss since email notifications are received on the phone and the stack trace given inside the email will help you find the offending line of code quite easily.

You can now rest easy knowing that your application is performing well and in case it is not, you will find out immediately.

Originally posted on my blog

Overriding the save method in your Django models

CH S Sankalp jonna — Sun, 11 Apr 2021 04:03:56 +0000

The Django ORM ensures that whenever an object of a database model is created or updated either via the admin interface or somewhere in the code, the save() method is called.

This means that if one wants to perform any action that needs to run before or after saving an entry in the database, this can be achieved by overriding the save method and performing the actions.

However this is usually not recommended unless you know what you are doing because any exception caused in the save() method will prevent the entry from getting created in the database.

So the recommendation is to perform these types of functionalities in your forms, views or serializers instead.

If you would still like to proceed, here is how you can achieve this:

Perform action before database operation

Let us assume that you have a database of blogs and each blog requires a slug which has to be kept read only and should be automatically created when a blog is created.

This can be done by overriding the save method and setting the value of this field before calling the parent save method:

from django.db import models
from django.utils.text import slugify 

# Create your models here.
class Blog(models.Model):
    title = models.CharField(max_length = 50)
    description = models.CharField(max_length = 200)
    slug = models.SlugField()


    def save(self, *args, **kwargs):
        # set the value of the read_only_field using the regular field
        self.slug = slugify(self.title)

        # call the save() method of the parent
        super(Blog, self).save(*args, **kwargs)

Perform action after database operation

Consider a case where you are building an appointment creation software. You would want to send an email to your users every time they create a new appointment with details of that appointment.

This operation needs to be performed only after the appointment is saved in the database for better resilience and it can be done by sending your email after the super method is called:

from django.db import models
from django.contrib.auth.models import User

# Create your models here.
class Appointment(models.Model):
    title = models.CharField(max_length=100)
    description = models.CharField(max_length=255)
    appointment_time = models.DateTimeField()
    user = models.ForeignKey(User, on_delete=models.CASCADE)

    def save(self, *args, **kwargs):
        super(Appointment, self).save(*args, **kwargs)

        # send email to the user for setting the appointment
        send_email(self.user.email, self.title, self.description, self.appointment_time)

Using signals

Overriding the save method can be very nifty, however there is a disadvantage of doing this.

If you have to perform multiple business logics that are independent of each other at the time of saving the object, all of this has to be done inside the save method.

This will make the save method quite cluttered and the code unreadable. It will also make it difficult to isolate the function that is failing when you need to fix bugs.

A better approach is to use Django signals instead. Django has many inbuilt signals which will notify a particular method that an action has taken place and the method can execute some business logic.

The above functionality of performing actions before or after saving an entry in the database can be achieved by using the pre_save and post_save signals respectively.

Using pre_save signal

The above example of creation of a slug before saving a blog entry into the database can be achieved using a pre_save signal as shown below:

from django.db import models
from django.utils.text import slugify 

from django.db.models.signals import pre_save
from django.dispatch import receiver


# Create your models here.
class Blog(models.Model):
    title = models.CharField(max_length = 50)
    description = models.CharField(max_length = 200)
    slug = models.SlugField()


@receiver(pre_save, sender=Blog)
def create_slug(sender, instance, *args, **kwargs):
    instance.slug = slugify(instance.title)

@receiver(pre_save, sender=Blog)
def other_pre_save_actions(sender, instance, *args, **kwargs):
    # perform a different kind of pre save action here
    pass

As you can see, we did not have to override the save method at all and this makes the logic of creating a slug decoupled. You can have any number of receivers for the pre_save signal and perform different actions in each of them.

Do note that this signal is called before the save method is fired and if there is an exception in any of these signals, the object will not get saved.

Using post_save signal

This is pretty much the same as a pre_save signal, except that it is called after the save method finishes running.

Here is a demonstration of its use by referencing the previous example of sending an email on confirmation of the appointment.

from django.db import models
from django.contrib.auth.models import User

from django.db.models.signals import post_save
from django.dispatch import receiver

# Create your models here.
class Appointment(models.Model):
    title = models.CharField(max_length=100)
    description = models.CharField(max_length=255)
    appointment_time = models.DateTimeField()
    user = models.ForeignKey(User, on_delete=models.CASCADE)

@receiver(post_save, sender=Appointment)
def send_appointment_confirmation_email(sender, instance, created, **kwargs):
  if created:
    send_email(instance.user.email, instance.title, instance.description, instance.appointment_time)

@receiver(post_save, sender=Appointment)
def other_post_save_actions(sender, instance, created, **kwargs):
   # perform a different kind of post save action here
   pass

This signal also lets us know whether the object is being created for the first time or not using the created flag. This will enable us to send the appointment confirmation email only once when the appointment is created for the first time.

Since this signal is called every time the object is saved, we have to ensure that the email does not get sent multiple times.

Closing notes

In conclusion, using pre_save and post_save signals is more elegant than overriding a save method.

In general one must be careful while performing these type of actions whether or not you choose to override the save method or use signals.

For instance, in the above examples of a Blog model, the slug is saved again and again on each update of the blog entry.

This means a new slug is created every time and this could negatively impact your search engine ranking. You might want to prevent this by checking if a slug already exists before creating a new one for a particular blog post.

To sum it up, do not override the save method or use signals until you are sure that you have handled all of these edge cases.

Originally posted on my blog

Running a 'bulk update' efficiently with Django

CH S Sankalp jonna — Sun, 04 Apr 2021 04:51:08 +0000

Updating a bunch of database entries together can be tricky compared to updating a single row. This is because there are two things that need to be kept in mind.

The operation needs to be atomic. You cannot have another process updating the same set of rows while running a bulk update on them.
The operation needs to be efficient. Running multiple queries on the database for updating multiple rows should be avoided.

Another factor at play here is whether you want to update these entries with the same values or different ones.

For instance, you might want to mark a bunch of old rows in your database as deleted. In this case you need to update all the rows with is_deleted = true.

But what if you want to update each row differently based on a certain condition?

Suppose you have a python dictionary where keys are existing user ids and values are scores to be updated for those users.

The dictionary would look like this - {1: 150, 2: 200, 3:500 …….}. Each entry in the “User” table would have to be updated with their corresponding score without running multiple update queries.

There are a couple of ways to achieve a bulk update efficiently. We will go through each of them, but first let's start with the most inefficient way to do this.

The inefficient way

Let us take the example of a table representing cake recipes where you want to delete all recipes older than March 1st 2021.

The most layman way to achieve this is as follows:

from datetime import datetime
starting_date = datetime.strptime("2021-03-01", "%Y-%m-%d").date()

for obj in Recipe.objects.filter(created_date__lt=starting_date)
  obj.is_deleted=True
  obj.save()

This operation will not be atomic because while this loop is running, there could be other processes trying to update the same rows.

This operation will not be efficient either because it will make an update query to the database for every single iteration of this loop.

Therefore, using this method should be avoided at all costs.

The efficient way

The same thing can be achieved by making a single update operation to the database while making sure this operation is atomic and no other operations run while this is in progress.

Here is how you do it:

from datetime import datetime
starting_date = datetime.strptime("2021-03-01", "%Y-%m-%d").date()

Recipe.objects.filter(created_date__lt=starting_date).update(is_deleted=True)

As you can see, not only is this efficient but it also takes a lesser amount of code. This is the best way to achieve a bulk update when you want to update all the rows with the same value.

Using bulk_update

As you may have noticed, the above example does not work for cases where you want to update different rows with different values.

Thankfully there are ways to do this with a single operation using the bulk_update method that Django provides.

Let us take the example of having to update scores of each user with a different value. This can be done so as follows:

user_ids_dict = {
  1: 100,
  2: 150,
  3: 500
  # this dict can contain n key value pairs.
}

# create a list of user objects that need to be updated in bulk update
user_bulk_update_list = []

for key, value in user_ids_dict:
  user = User.objects.get(id=key)
  user.score = value

  # append the updated user object to the list
  user_bulk_update_list.append(user)

# update scores of all users in one operation
User.objects.bulk_update(user_bulk_update_list, ['score'])

There is a problem with this approach though. You are running a select query on the database for each user ID before running the bulk update operation.

This can be avoided using an atomic transaction instead.

Using an atomic transaction

There is another way to achieve the problem of updating multiple rows with different values. You can do this by running each update operation inside an atomic transaction block.

Doing this will ensure that all the update operations performed in the loop will be executed in the database as a single transaction as opposed to performing each of these operations separately.

Code looks something like this:

user_ids_dict = {
  1: 100,
  2: 150,
  3: 500
  # this dict can contain n key value pairs.
}

from django.db import transaction

with transaction.atomic():
  for key, value in user_ids_dict:
    User.objects.filter(id=key).update(score=value)

As you can see, with this method there are no select queries being run at all. We are simply running multiple update queries in a single transaction.

This method is the most efficient way to achieve bulk update when your requirement is to update different rows with different values.

Closing notes

To bulk update rows with the same values based on a particular condition, use ModelName.objects.update() instead of running a save operation on each row separately.

To bulk update rows where each row has to be updated with a different value, use an atomic transaction where you run update queries for each row within a transaction block.

Originally posted on my blog

API permissions made easy using Django Rest Framework

CH S Sankalp jonna — Sun, 21 Mar 2021 02:32:18 +0000

Building APIs is not a straightforward job. One has to not only write the business logic but also have a permission layer to protect an unauthenticated user from accessing APIs that are public.

Restricting unauthenticated access alone is not enough though, there are cases where a user need not be authenticated for read permissions but should not be given write permissions.

For instance, if I am building a website for cake recipes, I would want anybody to view all the recipes but only an authenticated user should be able to edit the recipes.

What we essentially need to accomplish is role based access. This is where Django Rest Framework shines.

Handling all of these cases should be a separate module that you can just plug in at the end once your business logic is complete.

Guess what? It is actually that simple if you use Django Rest Framework. So before we go any further please install DRF in your django app.

Authentication classes

As mentioned earlier, there are two distinct concepts that need to be applied here.

The first one being identifying a user that is making a request based on various authentication backends that can be configured in settings.py of your django project.

This can be done by using DEFAULT_AUTHENTICATION_CLASSES. You can configure this using just a couple of lines of code.

REST_FRAMEWORK = {
    'DEFAULT_AUTHENTICATION_CLASSES': (
        'rest_framework.authentication.TokenAuthentication'
    )
}

‍This setting will ensure that if a API request contains a header called Authorization with a value that is equal to Token <auth_token>, request.user will automatically be set to the current user.

You could also use SessionAuthentication or any of the other authentication backends that are available that can be found here.

Use token based authentication

I usually prefer TokenAuthentication because the auth token is fixed and as long as it is present in the headers, one does not have to worry about saving anything in cookies and deal with making API calls to a domain that is different from the one where your frontend is hosted.

To generate an auth token for a Django user, simply include the below apps in your INSTALLED_APPS section and use this code to generate a token.

INSTALLED_APPS = [
    'rest_framework',
    'rest_framework.authtoken'
]

If you prefer not to apply the TokenAuthentication backend globally to all your APIs and only want to apply it to a few APIs, you could define a base view where the authentication class can be set explicitly and inherit this view wherever needed

from rest_framework.authentication import TokenAuthentication
from rest_framework.views import APIView

class BaseView(APIView):
    authentication_classes = [
        TokenAuthentication,
    ]

class MyAuthenticatedView(BaseView):
    # This view will automatically apply TokenAuthentication
    def get(self, request):
        pass

    def post(self, request):
        pass

class MyNonAuthenticatedView(APIView):
    # This view will not be authenticated
    def get(self, request):
        pass

    def post(self, request):
        pass

Permission classes

Now that we have taken care of authenticating a user, let us look at how we can perform role based access in the quickest possible way.

This can be achieved by using the DEFAULT_PERMISSION_CLASSES setting.

REST_FRAMEWORK = {
    'DEFAULT_AUTHENTICATION_CLASSES': (
        'rest_framework.authentication.TokenAuthentication'
    ),
    'DEFAULT_PERMISSION_CLASSES': (
        'rest_framework.permissions.IsAuthenticated'
    )
}

This setting will ensure that any user who is authenticated has permission to use all your APIs. But this obviously won’t work in most cases since we discussed earlier that we would require role based access.

You can achieve this by explicitly defining permission classes in your base view or individual views just like the authentication classes that were defined above.

DRF provides a bunch of permission classes out of the box which can be found here. For the sake of an example let’s use the IsAuthenticatedOrReadOnly permission.

As the name suggests this permission allows an API to be accessed only if you are an authenticated user unless the API you are trying to access is read only in which case anybody can access it.

This solves the problem of the cake recipes example given earlier and can be translated to code in the following way.

from rest_framework import viewsets
from rest_framework.permissions import IsAuthenticatedOrReadOnly

class RecipeViewSet(viewsets.ModelViewSet):
    serializer_class = RecipeSerializer
    permission_classes = (IsAuthenticatedOrReadOnly,)

    def get_object(self):
        return get_object_or_404(Recipe, id=self.request.query_params.get("id"))

    def get_queryset(self):
        return Recipe.objects.all()

If you try to access this API via the GET, HEAD, OPTIONS methods, you will get a response, but if you try to make a POST, PUT, PATCH call you will get a 403 forbidden response.

Custom permissions

In most cases, role based access would involve some specific business logic. For instance, you might have roles such as user, editor and admin.

To restrict access based on custom parameters like these. You can write a custom permission class by inheriting the BasePermission class and overriding the has_permission method.

from rest_framework.permissions import BasePermission

class IsAdmin(BasePermission):
   def has_permission(self, request, view):
      return request.user.is_admin

class IsEditor(BasePermission):
   def has_permission(self, request, view):
      return request.user.is_editor

class IsUser(BasePermission):
   def has_permission(self, request, view):
      return request.user.is_user

You could then chain these permissions together in views to determine which users will have access to which views.

from rest_framework.views import APIView
from .custom_permissions import IsAdmin, IsEditor, IsUser

# only admins are allowed to access this view
class APIView1(APIView):
  permission_classes = (IsAdmin,)

# Admins or editors are allowed to access this view
class APIView2(APIView):
  permission_classes = (IsAdmin | IsEditor,)

# all types of users are allowed to access this view
class APIView3(APIView):
  permission_classes = (IsAdmin | IsEditor | IsUser,)

Closing notes

In conclusion, the quickest way to authenticate users and give them role based access is to use the TokenAuthentication class globally and then custom permission classes for your individual views.

Alternatively you could write a base view and give it some authentication classes as well as permission classes that cover most of your cases and inherit all your views from this base view.

I prefer the latter method as it gives me more control and I can choose not to inherit this base view in some cases where I want to set custom authentication and permissions.

Originally posted on my blog

How timezones work in Django

CH S Sankalp jonna — Sun, 07 Mar 2021 11:23:41 +0000

There was a joke floating around the internet that if Elon Musk figures out how to get to mars, software developers won't be happy because there would be more time zones to support.

If you’re building an application that is going to be used by folks all around the world, they will be interacting with the application in their own local time zone.

This means that whatever records they see on their browsers or phones should have timestamps in their local timezone.

But we cannot store these timestamps on the backend in their local time zone because that would conflict with records of other users on different time zones.

I suppose timestamps can be stored along with the time zone information, but this makes it very hard to build software.

For instance what if you want to query all users who installed your app during a certain period of time? Getting this data will be next to impossible if all records are stored in their respective time zones.

So how do we keep every user in sync? And more importantly how does Django handle this?

Coordinated Universal Time (UTC)

Before we get into how to handle this problem in Django, let's talk about how the world handles it.

A time zone is nothing but a section of the earth where everyone observes the same time. But even a particular time zone may not follow the same time throughout the year due to something called daylight savings time which is too big of a topic in itself to get into right now.

Because of all these complexities, the world agreed to use a common standard for time that remains the same no matter where you are or what time of the year it is. This is known as the coordinated universal time or UTC.

UTC is maintained using an atomic clock that is very precise. All time zones are a positive or negative offset of UTC.

For instance I live in India which is 5 hours and 30 minutes ahead of UTC, so at the time of writing this post, the time was 10:32:10 PM UTC+5:30.

This can also be written as 10:32:10 PM GMT+5:30. In terms of time, there is no difference between GMT and UTC, however GMT is a time zone whereas UTC is a standard against which time is measured.

Timezone support in Django

At this point, it is quite obvious that our application should always deal with UTC time regardless of where the user is from.

In order to make sure this happens, you just need to configure a couple of things in the settings.py of your Django application.

TIME_ZONE = 'UTC'
USE_TZ = True

This will ensure that using a datetime.now() anywhere in your application always creates time in UTC. If USE_TZ is set to False, Django will assume that your application does not care about time zones and will create timestamps in the local time zone.

Local timezone here would be wherever you are hosting the Django application, so if you are running it locally on your computer it will use your computer's time and if you are running it on the cloud on a United States server, it will use that time.

I am sure you can see how this can result in chaos, so I would highly recommend using these two settings.

Displaying local time in browsers

To do this, simply convert your UTC time to this format: %Y-%m-%dT%H:%M:%SZ.

For more clarity on what this format means, consider the time at which I was writing this blog post which was 10:32 PM in Indian Standard Time on the 27th of Feb 2021.

This will be translated to 2020-02-27T05:02:00Z. This is because we have modified it from IST to UTC and used the format shown above.

The javascript that is rendering the timestamp on the browser will understand from this that the time is set in UTC and needs to be converted to whatever time zone the browser is running on before displaying it to the user.

You can verify this by pulling up the developer console on your chrome browser and running this line of code.

new Date("2020-02-27T05:02:00Z")

You will notice that even though you invoked the Date class using the time format in UTC, it automatically converted it to IST or whatever time zone you are running this on.

But what does this time format mean exactly? The “T” is meant to separate date and time while the “Z” is meant to indicate that the timestamp is in UTC.

Easy peasy right? Indeed it is!

Using the DateTimeField in your Django models.

It is generally a good practice to have fields in your models to determine when an object was created and when it was last modified.

Apart from these two fields you might need other fields that store timestamps based on your use case.

This can be achieved using the DateTimeField offered by Django models. As shown in the example below, one can have a created_at field and a last_updated_on field that get updated automatically when an object of this model is saved.

class TestModel(models.Model):
    created_at         = models.DateTimeField(auto_now_add=True)
    last_updated_on    = models.DateTimeField(auto_now=True)

auto_now_add will ensure that the value of this field is automatically set to datetime.now() when the record is created for the first time.

auto_add will ensure that the value of this field is automatically updated to datetime.now() every time this object is saved.

If you followed the previous time zone settings in your settings.py, these fields will ensure that they are always being set in UTC.

Closing notes

To sum it up, make sure that time is always stored in UTC and things should be fine.

If you want to handle issues pertaining to daylight savings time, I highly recommend using the pytz library which is built to handle these kinds of edge cases.

I hope you have a good “time”. Sorry, I could not resist :)

Originally posted on my blog

Flask vs. Django: Which framework to choose in 2021?

CH S Sankalp jonna — Sun, 21 Feb 2021 03:35:35 +0000

Being two of the most popular web frameworks in the python ecosystem, most python backend developers would have at some point encountered the question of whether to use Django or Flask to build a webapp.

Both of these frameworks have a common goal, but the way they achieve it is what makes them different.

Django is like a frozen pizza. You get the pizza base, the sauce, the toppings and the grated cheese in one package and all your need is a microwave to satisfy your pizza craving.

Even though this is super convenient, a frozen pizza could hardly beat the flavour of making a pizza from scratch using nothing but a pizza base.

With a pizza base, you have the option to choose your own sauce and toppings along with the quantity of cheese. This is much more tailored to your palette and food preferences. It is more more "flavourful" if you will and this is what Flask does.

Depending on the context you are currently in, either of these pizzas might be the right choice.

Core principles

Both of these frameworks were created for the purpose of building web apps. They are both open sourced and have a pretty sizable and active community that is backing them and constantly improving the projects.

Django comes with a lot of built in functionality which includes certain design patterns, features and tools. This means that a developer's job is only to focus on the core business logic and write as little code as possible.

Flask on the other hand does not make any assumptions on how you like to build your application and only provides the basic features which include things like a template engine, url routing, cookies, a development server, etc.

Django provides all of these as well and so does any other web framework, but building an application requires more like having an ORM that forms an abstraction layer between the application and a database.

Flask allows you to build this out yourself either by using existing extensions and libraries or by writing your own code. Flask is therefore a lot more flexible and this could be important if you have a specific use case which does not get solved in an elegant way using Django.

Which one to use?

It entirely depends on what you are trying to accomplish and how you want to accomplish it. But there are few factors to keep in mind while choosing your framework.

Database of choice

Django works great for relational databases and it has support for MySQL, PostgresSQL, SQLite and Oracle.

As mentioned earlier Django comes with an elegant ORM (Object-Relational Mapping) which makes it very easy to build CRUD capabilities. The ORM also has support for database migrations and no raw queries would have to be manually written to update your schema.

Flask on the other hand let’s you store your data in any form that you see fit. You could write raw queries if you wish or you could use an extension like SQLAlchemy to add ORM capabilities to your application.

Flask is generally a good choice to go with when you are working with non relational databases such as MongoDB or Redis.

Django has pretty bad support for non-relational databases and even if you manage to get it working, you won’t be able to take advantage of a lot of features that Django offers as they only work for relational databases.

Speed of development

Django enables super fast development. You could potentially have a working web application in a day or two and take it to production.

Since most of the functionality is already built in, the only development time is spent on writing business logic and choosing the right Django modules to include.

Flask on the other hand requires quite a bit of upfront setup time before you can actually start working on your business logic.

Complexity of the app

Django should be used if you anticipate your application to scale into a huge project with a lot of moving parts, user interactions and high volumes of content. For instance, Instagram is built using Django.

While flask could also be used to achieve the same, it would not be recommended unless you really insist on doing things your own way.

Flask is generally used for building small scale applications that have a predetermined set of functionality and are expected to do only one particular thing correctly such as a personal blog.

Design patterns

Django uses the Model-View-Controller (MVC) architecture which does a good job of separation of concerns and enabling reuse of components. This makes it highly scalable.

Flask does not follow any particular design pattern and you are free to use whatever you like. You can choose to make your application scalable or a throw away app that only does one thing and is not touched again.

Authentication requirements

Django comes with an inbuilt User model that can be used to authenticate all your APIs as well as control the permission of those who log in to the admin panel.

This can be used for account and session management and you can keep a record of which account is performing what actions.

Flask does not have support for account management. You can use cookies which are provided out of the box to establish sessions but for account management, a 3rd party extension such as Flask-Login would have to be used.

URL based routing

Perhaps the most important feature of any web framework is the ability to configure a URL route and a corresponding function/class to be called when that URL is invoked.

In Django, URLs are defined in urls.py and the function to be called on hitting those URLs are defined in views.py.

When a HTTP request is made, a request object is explicitly passed to the view and this object must be passed around to access it anywhere.

In Flask, URL routes are defined in the views itself in the same file using a decorator pattern. The request object is global and can be accessed anywhere if imported. You can virtually have just one file handling your entire application.

Support for RESTful APIs

I spent a good part of my career writing REST APIs and doing it in Django is an absolute breeze because of the Django REST framework. APIs can be built quite rapidly using DRF and it provides everything including generic views that you can import, serializers, request validation and auth.

Flask also has good extensions to achieve this but all the above mentioned features are offered by different extensions. For instance you could use Flask-RESTful alongside Flask-Marshmallow for serialization and Flask-JWT for auth.

Security requirements

Django provides out of the box support to handle common security threats such as cross site scripting, clickjacking and SQL injections.

With Flask you would have to once again rely on 3rd party extensions to achieve this and since security is a sensitive issue, a thorough evaluation of the extension and constant updation of the extension would be needed.

This is a good piece on how you can secure your Flask applications.

Performance

In my opinion, there is not much difference in performance between the two frameworks. Both of them can be used for high traffic websites with no problems.

One could argue that Flask has better performance because there is less surface area to cover in terms of the code that is invoked due to being a smaller framework but I find this difference practically negligible.

Closing notes

Neither of these frameworks are a “one size fits all”. If you cannot compromise on flexibility and customization I would recommend using Flask. For all other intents and purposes, Django is probably a better choice.

Having said that, another reason I would recommend flask is if your intention is to learn web development.

Flask has one of the cleanest python code I have ever seen and a beginner would find it a lot easier to use Flask than Django because of its lightweight nature and no overhead.

If you start learning web development directly with Django, you run the risk of learning more about django itself than actual web development because of the overhead involved in setting it up.

If you prefer to solve this Django vs. Flask debate by looking at what code looks like in either of these frameworks, I would recommend checking out this article.

In conclusion, whether you choose to eat a frozen pizza or a pizza made from scratch, the fact remains that you managed to satisfy your hunger and that’s what matters at the end of the day.

Happy coding!

---

originally posted on my blog