Realworld usage of Django

Using Django Getting Started
1

Hi!

I’m a Java Spring developer for several years and I wanted to learn something new in a completely different language - so I chose python and since I enjoy backend development, I chose Django as an framework after some time spent on learning python. The thing that is not exactly clear to me is how Django is actually used in real world apps. Dont’ get me wrong, I don’t doubt the importance or complexity of Django.

Me as an Spring developer I am used to having Controller (views in python) and then having controller call some method in service. Services are the place where the whole backend logic happens. I work as a backend developer in a local company and we do some smart home management. One of your product is that we install a smart meter which sends data to our system and show them to user in hourly based consumption. Now, when data from meter hit our system, it needs to go through hundreds of thousands of lines, services and logic. It has to validate, decypher, map to real world value channels, etc.

I don’t seem to understand where would you put the whole logic in python. Most of the logic in small projects that I’ve seen was in the views itself, but when you have large scale application with thousands of lines, views are gonna get messy and complicated. My friend told me about having whole logic in models - that’s kind of a weird solution as well.

So, this gets me to my whole question - is Django made for large scale applications? Or is it just for some utils, easy applications?

Thanks for your understanding and answers!

2

Absolutely. Our internal flagship project was a Java Spring system completely rewritten in Python/Django. This project is more than 100,000 Lines of code (about 10,000 automatically generated as migrations and inspectdb output), manages about 250 models, and our primary deployment services about 5000 registered users on a weekly basis.

As a result of this re-architecting, re-engineering rewrite, we’re much more quickly able to support requested enhancements with a much-more robust security infrastructure.

(This is not saying that this couldn’t have been done in Java/Spring, just that it would have been significantly more work for our small team of 3 to have done so. I’ll acknowledge that the original wasn’t all that well designed to begin with. It was a typical “enterprisey” project and everything that that implies.)

The total amount of code for this system is only about a third of the size of the code for the original project. Python’s greater flexibility in terms of its object usage allowed for a lot of excess code to not be needed compared to the Java counterpart.

Yes, Python is not Java. If you examine Django through a Java lens, it probably won’t look good. But when you really learn Python to understand the expressiveness of the language, you learn quickly that a lot of the things you need to do in Java simply go away because of the fundamental differences in the language.

I once was employed by a company that was seriously invested in Java for about 10 years. My original position at my current employer was as a Java developer - but I was able to demonstrate a clear superiority of the Python/Django combination for our small team for developing web apps, and so we have effectively abandoned it as a platform. (We still have one production Java app, but it’s a system built within LifeRay, so that’s not going to go anywhere soon.)

So at this point I have at least 10 years of solid Java experience. (I also have about 10 years of COBOL experience from the 70’s & 80’s. At this stage, I’d rather work in COBOL than Java.) But, fortunately, I’m now working in Python, and will continue to do so for the remainder of my career.

None of this is written to imply that I think Java, as a platform, is “bad”. I just think it addresses a different category of issues than Python. But those differences do not “enhance” or “inhibit” the use of either of those platforms for applications large or small.

2 Likes
3

Thanks for your answer, it was really helpful. And yes, I don’t want to sound like I’m trying to hate python or django, definitely not. The only reason why I “compare” it to java is because java is the only language and spring is the only framework that I have experiences in.

You’re saying that your team managed to rewrite code into python after doing it for several years in java. First of all - great job :smiley:

But I just wanted to make sure - the thing I described that we do in my work is just a small part of the whole “ecosystem” like we like to call it. Then you have whole subject (person) management, object (as in building) management, ticketing to report issues in the flat/building, etc. We use microservice structure to keep every module in a separate project and keep it some what cleaner. This means that every change in our system has to go through various processes and logic that it’s almost impossible for single developer to know everything about the system.

So, is Django able to deal even with this large of a system? Are microservices a thing in Django?

Additionally, what is the best way to handle business logic? Some sort of managers/service classes?

4

<opinion>
My gut reaction to this type of description is that your system is probably “overengineered”. (That’s my standard reaction whenever anyone starts talking about “microservices”. I’ve never had any direct involvement with any system where they have actually proven to be valuable - and that includes 30+ years in Fortune 500 companies handling thousands of transactions per day across millions of customers, including a major health insurance firm.)

But yes, I’m well used to working with large systems across multi-national corporations performing line-of-business work with more than 50,000 employees and systems where any one individual can only know a small part of the overall picture.

Look at it this way - Instagram is built on Django. Are you in Instagram’s class? If so, great. Django can handle it.

I hope not. At least not a prevalent choice.

Some people have tried. Again however, my experience has been that it’s a waste of time and effort to move in that direction. All you’re really doing is moving some degree of complexity from one department (development) to another department (operations). In theory, there are scalability advantages to that.

However, “The difference between ‘theory’ and ‘practice’ is that in ‘theory’ there is no difference but in ‘practice’ there is”.

Yes, there are classes of problems where microservices make sense. However, I’ve yet to personally encounter one, and again, this is across a career where the smallest company that has employed me had more than 25,000 employees.

The problem is that some Enterprise Architects (of which I was one for 5ish years) see someone like Amazon go in the direction of microservices, thinking that “if it’s good enough for Amazon, it must be good for us”, when that’s exactly the wrong conclusion to draw.

System architecture is not a “silver bullet” exercise. The selection of a solution architecture outside the context of the specific environment is almost always the wrong choice.

(Side note: I’ve also lived through the SOA and ESB fads as well. I look at “microservices” as being just a relabeling of that same old snake oil in a new bottle. What I think as the major problem with the SOA / microservice deployments that I have seen is that they tend to be too granular. They try to chop things up too much in the name of “flexibility”, adding unnecessary complexity to the environment.)

So unless you’re really in the FAANG class (and not just a FAANG-wannabe or the pipe dreams of a startup), you’ll never convince me of the value of a ‘microservice’ based architecture.

Nope - you’re thinking Java structure here. With very few exceptions, the standard views / models structure of Django work extremely well.

</opinion>

2 Likes
5

We’ve used Django for most of our services in a “microservice architechture” at my place of employment, although I am also suspicious of the value that type of architecture really brings.

It has worked fine, although we’ve missed an easier way to have SSO for all the various Django-admins our operators have to log into.