Should I use Django for my project?

Using Django
1

It is very possible that the answer to this question is simply “rather use Flask”, but I am hoping I can get a good enough excuse to actually get it working in Django.

TLDR - Basic overview of the statistical model pre-Django:

I built a model in R which I am busy porting over to Python. The model is a financial model that analyses past behaviour of client payments in order to estimate future expected losses & repayment. The model performs a number of data imports from an existing SQL database which itself gets populated by the company’s source system. The SQL database is ever growing and contains thousands of tables with loads of financial, historic, client data. The model imports what it needs and then we perform a bit of gymnastics in order to obtain a few bespoke parameters (i.e. we calibrate the model). Once all this is done, we apply the parameters to the latest set of loans in order to estimate the aforementioned forecasts.

Purpose of the app:

The main purpose of the web app is to “white box” the model. Clients were complaining that they have no feel for the numbers and would like to see the inner workings. For all intents and purposes, it is a silly request, but the client is paying and I will oblige. So the goal is to build an app that allows the user to execute sub portions of the model and in the end do a full model run themselves.

To this end, I enrolled in a 50+ hour Django course and enjoyed it very much. However, in the end I learnt how to build social blogs from scratch, but nothing close to what I am trying to achieve of course.

Question:

Which brings me to the question of whether I should be pursuing this in Django or not.

I have been tempted to write this post for many weeks now, but I am fully aware that this is not a very ‘good’ forum question. These forums usually requires very specific singular questions that are short, discreet and solvable.

What I have attempted:

I have managed to build an app with a front-end that allows a user to make a few selections such as “Date”, “Country” etc. which is submitted via a form to a view which finally kicks off a fairly complex python script (which itself performs SQL imports and Pandas computations) and eventually returns a DataFrame which gets presented to the user.

Rant:

In this, I don’t see where I need “Django Models” and I don’t know if I even need to use Model Based Forms or Model Based anything for that matter.

One last thing:

The other thing that I can’t get clarity on is the following: As mentioned, the model uses an existing SQL database that sources massive amounts of data and then executes Python scripts which performs various statistical and data mining computations. Is it possible (or even sensible) to create “Django Models” from the existing SQL database, and perhaps the more elementary question (I am very much a noob in Django), why do I want to create “Django Models” of the SQL database. I am not persuing a social blog where I want to save posts and comments, I need to click a few buttons which execute python scripts and presents the results to the user.

I hope someone can decipher what I am trying to achieve and help me on the right road.

Thanks

1 Like
2

Been there, done that, still doing that.

While the specifics of my situation are different in scale and specifics, I would submit to you that, in nature, our use-cases are very similar.

Briefly - I’m working with some traffic control systems. These systems generate and collect data on a regular and consistent basis. We collect this data in a PostgreSQL database. One of my tasks is to present this data in a manner that is useful to traffic engineers who want to visualize the patterns in the data.

(If you don’t think this is a reasonable match to your use-case, feel free to stop reading here.)

Yes, our solution is built in Django.

Yes, we create Django Models, where managed = False, and we set the db_table to refer to the proper table name, and we have multiple DATABASE entries in the settings file to point to the different collection databases, because the core Django data is stored in its own database. (We also create Django Models to refer to views that we have created.)

Why? A couple reasons - one, so that the “application patterns” look “similar” across all our applications. A developer switching among apps is going to find similar structure and patterns across all of them. (Well, most of them - we are a work in progress.)
The other is that it’s just the best fit. Going with models makes it easier for us to create views and templates that just seem to work in ways that match how Django is intended to work.

This also allows us to create some model managers that encapsulate some queries with some required data transformations. (A lot of these systems transmit their data in non-character format - frequently in unaligned binary formats. The data needs to be decoded to make it usable in any real way.) The managers then return the data as data structures that make sense in the context of the views that will be created to display them.

(Another note - I don’t work on any large, publicly facing web sites. The average number of users of any of my sites is 2. I think my largest site right now is used by 4 people. The Django default databases for these apps with all the Django-specific data is typically in a SQLite database - it just doesn’t need to be anything else.)

Warning: Rant follows:

And this is where I have developed some strong opinions. Over the years, I’ve developed a philosophy that can be summarized as “Don’t fight the framework”. It doesn’t matter what the platform or framework is - Django, Flask, Drupal, Joomla, Liferay, Cold Fusion, dBase, whatever. You’re going to find working in them to be a whole lot easier if you learn how they approach different aspects of a problem and you adjust your mindset to theirs. Do not try to make the framework fit how you think about a solution. Trust that the people who developed these application frameworks know what they’re doing and that they have a reason for doing things the way they do.

It has been my impression that Django does have some opinions of its own - and you’re only going to be happy developing in Django if you can agree with those opinions.

Now, granted, in some cases that can be difficult to find or figure out, particularly in the absence of good, detailed, real-life examples, and that’s where a good community can help fill in the blanks. (And, IMO, Django has one of the best.)

End of Rant.

Flask will work - sure. I haven’t used enough Flask to envision where you would have any problems with using it for that. But what we discovered is that once we got beyond a certain level of complexity in our application, we reached a point where we realized that we were saying “hey, Django already does that built-in” on a more and more frequent basis - and that’s when we switched. None of our apps in this realm are particularly difficult or complex, but we’ve decided that we would do things “the Django way” for everything - and haven’t looked back.

I’ll admit, we’ve got a couple of small apps where Django feels like overkill, but it’s worth it to us to ensure that the internals are all similar.

Anyway, if I were to summarize my thoughts on this, I’d say that you’re probably going to be better off going with Django rather than Flask, not because it’s easier to get started (it’s not), but because as your app grows and accumulates more functionality, you’ll find that what Django provides makes those extensions easier.

Ken

2 Likes