There are so many programming languages, but one that has caught my eye for a pretty long time has always been Python. The first time I heard about Python, I remember being like, why would you name something after a snake unless it was deadly.

Python is an interpreted, high-level, general-purpose programming language. Its design philosophy emphasizes code readability with its notable use of significant whitespace. It is used to build websites but not as itself but while using frameworks like Flask or Django. My main focus in this article is Django.

Django is a free and open-source web application framework written in Python. Before we start the deep dive, you need first to understand what a framework is. It is a collection of modules that make development easier. They are grouped and allow you to create applications from an existing source, instead of from scratch. To make this relatable a framework is like a piece of cloth that you buy say a pair of pants, then add a few tweaks to it like add Ankara pieces to the pockets, rag it a bit, and spray some paint in it, you do all this to customize it to your taste.

An interesting fact about Django is that it is named after a famous guitarist, a legend of his time, Django Reinhardt. You have the right to listen to any type of music while using it, including bragging rights. Being a Django developer is being an artist.

In terms of architecture, we have two designs MVT(Model View Template) and MVC(Model View Controller). The main difference between this is that in MVC, you have to write all the control specific code while in MVT, the controller part is taken care of by the framework itself.

Django uses the MVT. Let’s dig deeper into what MVT means.MVT separates the code into three parts. Model, View, and Template. The Model contains the system responsible for dealing with data and databases; View deals with the design pattern; that is, it decides what data should be displayed, Template specifies a structure for output. Data can be populated in a template using placeholders. It defines how the information is presented. An example is a Generic list view that we can use to display a set of records from the database. MVT separates client and server code, which leads to low coupling hence the reason why Django refers to as a loosely coupled framework. Coupling is the degree of interdependence between modules.

To exemplify all that, think about this, Imagine you have to display a pair of several pairs of jeans you have in your closet, stored in a table called jeans. In MVC architecture, you have to write code to fetch the list of jeans from the database, Then, write the presentation layer that is HTML and CSS, Map in a URL(Universal Resource Allocator) then send it to the user. In Django, the only thing that you have to do is inform the framework of what data to display to the user (Jean’s table). It will create a view based on the data and send it to the user. That is why we say that Django is the web framework for perfectionists with deadlines.

A project is an entire application, and an application is a module inside the project that deals with one specific requirement. E.g., if the whole project is an e-commerce site, it will have several apps, such as the retail site app, the buyer site app, and the shipment site app. There can be many apps in a project; each app may have some URLs that it responds to. Rather than registering all URLs for all apps in a single urls.py file, each app maintains its urls.py record, and in the project’s urls.py file, we use each urls.py data of each app by using the include function.

Another perk of Django is it entirely automates the creation of admin interfaces for models. The interface allows us to see and change data in the database of registered apps and models. To use a database table with the admin interface first and foremost, you need to register the Model in the admin.py file.

Moreover, the response cycle of this framework is pretty neat too. The Django server receives a request. The server looks for a matching URL in the URL patterns defined for the project. If there is no matching URL found, it responds with a 404 status code. In a situation where the URL matches, the corresponding code in the view file associated with the URL executes to build and send a response.

Migration, in our context, is a Python file that contains changes we make to our models so that they convert into a database schema in our DBMS. Therefore instead of manually making changes to our database schema by writing queries in our DBMS (Database Management Systems) shell, we just make changes to our models. Then, we can use Django to generate migrations from those model changes and run those migrations to make changes to our database schema. Its cousin close to the English definition of migration, which is movement.

ORM (Object Relational Mapper) allows us to interact with the database using objects of our model class Instead of interacting with the database by writing raw SQL(Structured Query Language) queries and converting the data returned from the query into a Python object.ORM translates these changes into SQL queries based on the database we are using, for example, SQLite.

A middleware is a layer in Django’s Request/Response processing pipeline. Each middleware is responsible for performing some specific functions on the request and response, e.g., AuthenticationMiddleware, that associates users with requests using sessions.

DRF (Django REST Framework) is a Django app and a framework that lets us create RESTful(Representational state transfer) APIs(Application Programming Interface) rapidly. DRF is a way to transfer information between an interface and a database. It separates user interface and data storage. Besides that, it communicates to the user and database by sending a .json file, as illustrated.

Also, DRF is advocated due to its structure, and we only need a few lines to do anything. To add to this, we can feed it to any platform which removes duplicity of code and helps to escalate it quickly. The image below shows what three lines of code can accomplish.

The Sessions framework in Django stores arbitrary information about the user on the server in the database. This is because HTTP is a stateless protocol, meaning it does not store information between subsequent requests.

A cookie is a small piece of information stored in the client’s browser. It saves the user’s data in a file permanently or at the specified time. It has an expiry date and time and gets removed when it’s expired. Django uses a cookie containing a unique session ID to identify each browser and its associated session with the site.

The pros of using Django is it has better CDN(Content Delivery Network) and content management. Companies like Netflix and Amazon prime use it since servers are located near the client, they can serve the content more rapidly and thus, increasing client satisfaction.

It is Scalable and made in such a way that it will be able to handle any kind of hardware additions. Not only is it secure in that the Get Method is used to transmit the data, but also the passwords and all the essential information automatically encrypts with a long security key, that even in the Django database, we cannot see the password.

As much as we have so many highs, we also have a few downsides. It is monolithic, meaning it has a particular set of files and predefined variables that you need to learn about before you create any project. Not for smaller projects, the functionality comes with lots of code, hence it takes server’s processing and time, which poses some issues for low-end websites that can run on even very little bandwidth.

The pros outweigh the cons. On your next project, shoot your shot with Django.