ph_piter April 27, 2019 at 17:54

In which cases it is worth using Django (and in which it is not necessary)

Transfer

Let's help developers figure out if the Django framework is suitable for their next project. It is likely - suitable.

Do not grab onto a particular programming language or framework just because you used it in your previous project, or simply because you are familiar with it. So things are not done.

Before embarking on a new project, you should evaluate which language or framework is best for you to achieve the desired result. What is most important to you? Security, development speed, scalability, versatility, support?
It is better to make an informed decision before starting work than to repent in haste later (or, worse, hang crutches on the project in the process of implementation - due to the fact that you did not care about its support in advance).

I have worked with various technologies for many years, dealt with both mobile and web development, and I believe that Django offers such a complete set of features that are not found in any other web framework.

I understand this is a loud statement. Let me justify it.

“Django has a lot of sites that are used most actively, in particular Instagram and Pinterest. Even Facebook uses Django for many of its utilities. Django originated in the publishing environment, so it is not surprising that this framework is used on sites such as The Washington Post and Smithsonian Magazine. ”- Amit Ashvini , Vice President of Marketing @ Zibtek

General view: when to use Django

If at least a few of the points below are about you (and there are no points on the list that you strongly disagree with), then Django is likely to be a good fit for your project.

You need to develop a web application or backend API.
You need to work quickly, quickly deploy and make changes to the project as you work.
By default, the application should be protected from the most common vulnerabilities and attacks, in particular: CSRF, SQL injection, XSS, clickjacking, etc.
At any time, scaling may be required in the application: both scaling up and shrinking.
In the future, you plan to integrate the latest technologies, for example, machine learning.
You need to use a reliable framework that is being actively developed, used by many top companies and leading websites around the world.
Both the web application and the server side of the API are required to be in the same code base, consistent with the “single source of truth” (DRY principle)
You do not want to work directly with database queries, and you need ORM support.
You are going to use free software.
If you get stuck, you will have to look for a solution yourself, so you will need good documentation and a responsive developer community.

In addition to the above factors, you need to consider what skills you (or your team) have.

If you are a web developer and already know how the web works, then working with Django will work for you relatively smoothly. You need to understand how Django is structured, and some other things, of course, too - and consider that you are ready.

When not to use Django

You are dealing with a colossal application, and it simply does not fit in one code base. It might be better to split your application into microservices. Each of its levels is better handled by a dedicated team. For each specific use case, other technologies are suitable. In some of these scenarios, Django may come in handy, but it would be impractical to fully develop such an application in Django (as well as in any other separate framework).
You need to write a simple application in which you do not need to work with a database, perform file operations or do anything at least a little complicated.
Microframes are best suited for such situations. One of the most popular microframes - Flask, like Django, it is written in Python. Similar microframes are available in other technologies, for example. Slim in PHP, Apache Spark in Java, Express.js in Node.js, etc.
You want to write everything yourself from scratch and you know what you are doing.
You or your colleagues are completely unfamiliar with Django / Python, and you do not have the time and resources to develop the necessary skills.
The best solution in the latter case is to work with what you know best. If you take on a new technology or framework, then the chances of screwing up increase many times over.

If all of the above is not about your project, then Django is likely to suit you.

Reasons to use Django

The Django framework is written in Python:
I know, you know that.

Therefore, I will take this opportunity and emphasize some of the key advantages of Django that he inherited from Python. I will be brief.

Python is one of the most popular and fastest growing programming languages in the world.

Sources:

TIOBE index
Indeed.com Jobs' data analysis by Coding Dojo
GitHub Octoverse Learning

Python is really easy. Usually, modern developers are the first to learn this particular language.

The above does not mean at all that this language is only for beginners. Python is also used in cutting edge technology. Python is actively used in the technological stack of many giant companies, including Google.

Python is great for developing web scraping tools.

It interacts well with other languages.

Python development does not mean that you will be forced to write everything in Python only.

You may well be able to use libraries for many other languages, including C / C ++ / Java.

Python is portable, easy to read.
Python can even run on the JVM. Get to know Jython .
Python is widely used in such popular technologies as Big Data and Machine Learning.
You get access to the huge PyPI library.

Django's All Inclusive

“All inclusive” means that Django is out of the box equipped with most of the libraries and tools needed in common practical situations. I will list: Django ORM, middleware, authentication, HTTP libraries, multisite support, i18n, Django Admin, template engine, etc. - And that's not all". No other framework known to me provides such wide support at once.

Some consider this a “minus”, while others consider it a “plus”. Each side of law is different in its own way, and to some extent I agree with both.

This is a minus, because in such a situation the framework turns into a monolith.

I believe that if you need these features that lead to the formation of a monolith, then one way or another you will have to use some other library (or write it yourself).

Why, then, not use a tool in which all this is already there, tested in battles, operates on the largest sites, is actively developed and provided with community support?

If you don’t need most of the features offered by Django, then it’s better to stay on some microframework.

Do not reinvent the wheel - do you remember? Spend your time on what's really important, and let Django do the rest.

Django admin

Although, I mentioned this element in the previous section, it deserves closer attention. In many frameworks, in particular, Laravel, Yii, etc., attempts have been made to simplify the work with the admin panel. I have managed to develop many projects in different frameworks, but not one of them can be compared with Django in the convenience of working with the admin panel.

Some believe that Django Admin is not flexible enough, and to fine-tune any part of it to your needs, you need to make a lot of effort. At first, working with Django, I was inclined to agree with this, but over time, having figured out the framework, I became convinced of this. Yes, there is its own learning curve, but not a second that you devote to it will not be wasted.

In fact, Django Admin is very well structured. In some of my projects, I used the Django admin panel “as is”, and in others I completely replaced it with my own templates, which I developed from scratch. In any case, this took no more time than development with any other framework I knew.

The main plus? You get access rights and authentication out of the box. It would take weeks (or at least a few days) to develop all of this from scratch.

DRY Principle (Do Not Repeat)

I know many frameworks whose proponents claim that they really comply with the “DRY” principle. I have worked with many such frameworks, but in none of them the principle of “DRY” is implemented as it should.

Unfortunately, in most frameworks, the “DRY" principle is simply not given enough attention. In my opinion, if you are writing an application that you intend to regularly update (and this can be said about most modern applications), then you should follow the DRY principle in order to avoid problems.

So, in Laravel, you have to write validation for each procedure separately. The situation is the same with most other frameworks. To make your code comply with the DRY principle, you need to work hard. It’s hard to keep track of it, especially if you work as a team.

In turn, the Django framework is designed in such a way that violating the DRY principle there usually comes out only on purpose.

That shouldn't be, right? Consider an example.

Here's how Django works with database validation and migration

Create a class Modelwith the required fields. We indicate all the additional validations and restrictions that we need.

Migrations are generated by a single CLI command: `python manage.py makemigrations`.
Changes are made to the database with a single CLI command: `python manage.py migrate`.
Validations and restrictions are automatically checked during each CRUD operation - whether it is a Django Admin or a Django REST Framework. You do not have to write validations again.
The same model class is used to generate Django Admin CRUD views. No custom HTML / CSS required.

Compare these conditions with any other framework - and, I think, you would never be able to do anything like this in just the following few lines of code:

class Employee(models.Model):
    name = models.CharField(max_length=127)
    email = models.EmailField(null=True, blank=True)
    created_at = models.DateTimeField(blank=True, null=True, auto_now_add=True)
    updated_at = models.DateTimeField(blank=True, null=True, auto_now=True)

This is not just about “not repeating”. This approach saves you from bugs in the future. We all found ourselves in situations where we happened to change something in one place and forgot to replace in another place - and this became clear only after many users started having problems.

In Django, returning to the above code, if you ever have to replace the `max_length`fields with something else - just do it here. The change will automatically apply to the validation of all routes and to the database.

Object Relational Mapping in Django

Django provides a full-featured out-of-box ORM engine.

I worked with many ORM tools in various technologies, including Eloquent, greenDAO, Yii AR, etc. In all of them, the simplest requests are handled quite well, but sooner or later I had to write these or those requests from scratch, since the ORM mechanism could not cope with a specific practical case.

With Django ORM, I have not yet been in such situations. It worked so well that you just might forget that you are working with database queries. This is exactly what the object-relational mapping should be. The following are some examples of Django ORM:

# получает 5 верхних результатов, где rank = 10 и age <= 30
top_young_employees = Employee.objects.filter(rank=10, age__lte=30)[:5]
# вставляет запись с указанными значениями
employee = Employee.objects.create(name=’John Doe’, age=35, country=’IN’)
# выводит на экран значение поля
print(employee.name)

Rapid development

The creators of almost any web framework love to brag about this, and, perhaps, they are all really right - depending on what meaning we put into the word “swift”.

True, with Django some things are done hilariously fast. You have already seen how easily we were able to determine the admin UI, database table, and validate.
It was just the tip of the iceberg.

In principle, rapid development is not a feature as such, but only an organic consequence of Django DRY, ORM, the template engine and the all-inclusive philosophy.

Django Framework Security

Let's admit, sometimes developers are lazy. I am so sure. From time to time I procrastinate, putting off the solution to critical tasks. This is where various vulnerabilities can arise.

I especially like the fact that Django does not make security indulgences to speed up the pace of development. Security features are activated by default, so it doesn’t matter if you are lazy or not.

Open source, excellent documentation, huge community, etc.

Since Django is an open-source and insanely popular framework, a responsive community has formed around it. I think you are aware of the advantages of free software - and so, they are all inherent in Django.

The official Django documentation is more than enough for any developer. If you get stuck, finding a solution is not difficult.

You might already have the impression that Django has created a lot of its own libraries, so you might be surprised that there is no special library for testing here. No, don’t think that the Django framework doesn’t support testing - it supports, even like that. It’s just that following the “Don't Repeat” principle, it would be pointless to develop a library for testing when an excellent library of this kind is already in Python itself. Django interacts well with her. In addition, it combines very well with third-party libraries, such as pytest.

Current state of Django and other popular frameworks

So, I tried to the maximum extent possible to highlight the problems that I encountered when working with other frameworks and compare these frameworks with Django. After working with Yii, CodeIgniter, WordPress, CS-Cart, Laravel, etc., I came to the conclusion that Django is much better than any of them.
However, this is just my opinion.

If you like statistics, then here is the annual Stack Overflow study, where Django is among the most popular and sought-after frameworks:

Frameworks, Libraries, and Tools
Most Loved, Dreaded, and Wanted Frameworks, Libraries, and Tools

In addition to the above experience with PHP, I also developed Android applications in Java, client applications in React.js. In all these cases, I spent a fair amount of time refactoring the code base, looking for the best architecture, after a couple of months linking in problems with scalability and again taking up refactoring.

I recently rewritten from Laravel to Django one application that I had in production for over a year. I managed to deploy a new code base in less than 10 days, writing the minimum amount of code for this (I say the same: complexity decreases!) In the opposite direction, such an operation would definitely take more than a month.

If you try to directly compare other frameworks with Django, this will not give you anything.
Performance monitoring may show that the Java framework is faster than Django. You can be good at PHP, so maybe developing your application in Django will be faster than with the familiar PHP framework. In the case of a very simple application, setting up Django may seem a little tedious to you - of course, it is much easier to write a script file. Survey results may vary depending on which audience they were conducted.

However, here we are not only discussing frameworks related to other technologies. Even if you are familiar with Python, you may find the Flask microframework more convenient and desirable. We’ll have to think about which one to stop at.
My advice is simply not to compare them.

Conclusion

In my opinion, Django managed to perfectly balance performance, architecture, development complexity, security and scalability.

If you are starting to write a project from scratch, I highly recommend trying to make it with Django.

Tags: