... | ... | @@ -65,8 +65,23 @@ Django advertises itself as coming with "batteries included". By that meaning th |
|
|
|
|
|
The fact Django comes with a lot of functionalities doesn't mean you do have to be using all of those features to take advantage of the framework itself.
|
|
|
|
|
|
On the other hand we have minimalist frameworks that come with very few features other than routing. With this type of framework, if you ever need to perform a common action such as connecting to a database or providing authentication, you will have to either write those functionalities or resort to some third party library.
|
|
|
On the other hand we have minimalist frameworks that come with very few features other than routing. With this type of framework, if you ever need to perform a common action such as connecting to a database or providing authentication, you will have to either write those functionalities or resort to some third party library. The biggest risk here being for developers to decide on using homemade code for solving problems they might have underestimated, one of the few things that come to mind right away are authentication or date management.
|
|
|
|
|
|
Even if it's not perfect, I'll try to go with a car analogy here.
|
|
|
If you were to fix a car, would you rather have access to a fully-equiped garage (at no extra cost) even though you know you won't be using half of the tools available in said garage or would you rather do that in the parking-lot in front of your house, knowing that you have very few tools at your disposal but that there is a DIY store nearby where you will be able to find most tools you'll need and that are not included in the service kit you received with your car?
|
|
|
Some of you might decide to go with the second solution, arguing that if you do that often enough you will start building up your own supply of tools and that it might be beneficial. This is the minimalist framework route.
|
|
|
I would imagine most of you would rather go for the fully equipped garage though. This is the Django route.
|
|
|
|
|
|
## Is Django really too bloated?
|
|
|
|
|
|
"Django is too bloated for micro-services" is an argument I have seen or heard several times. Not being able to question the person who said that at the time, I tried to understand what they meant by that.
|
|
|
|
|
|
First, I looked at memory usage. It is true that Django, running with `DEBUG=True`takes at least 200Mb of Ram which can be scary if you want to try to run it on a small node that only has 256Mb available. Once you set `DEBUG=False` though (ie: in production), the amount of Ram used goes down drastically and is similar, even sometimes smaller than the same functionality running on another framework.
|
|
|
|
|
|
Since the claim is not Ram-related, I then ran test to compare CPU load between Django and other frameworks, thinking that maybe Django would be using more CPU either at low or higher request rates. Once again Django performed similarly to other frameworks.
|
|
|
|
|
|
As a last resort, Django having its own ORM (Object Relational Mapper), I wondered if that claim might have to do with the database layer of Django and went ahead to test that. Once again, the results were similar to other framework.
|
|
|
|
|
|
In summary, if someone wants to make the claim that "Django is too bloated for micro-services", I would like to know what exactly they mean by that and if they have evidence to support that claim. Until that happens, I will claim that "Django **is not** too bloated for micro-services"
|
|
|
|
|
|
## Storing extra batteries safely (configuring Django for micro-services) |