Should I use Django?

Using Django
1

I’m new in Django, and need to use it in couple with Django REST Framework.

The point of service is commands transfer between A to B services (for example B is mine) and do some actions after that

Process is:
Get data -> Validate data -> Do some action -> Save some data in DB (maybe logs, history, result of action, etc, ) -> Do Response

Problem 1:
Data format is XML. Yes I know there is XML parser for Django, but there is nuances: encoding of XML document is shift-jis and content type is multipart/form-data. It is easy to set encoding, but there is no “boundary” separator inside body, so I get error “ultipart form parse error - Invalid boundary in multipart: None”. And now I need to change MultiPartParcer or create my own one

Problem 2:
My application don’t has standard views like “List Objects and show it as is in json/xml” or “Get Object and show it…”. So if my understandings of Django is right, there is no short way to use Django benefits if my needs are non-standard. So I need to create View by myself.

Problem 3:
My response must be as weird as request (xml, shift-jis, multipart/form-data, custom body). So I can’t use default Response class as is.

Problem 4:
Data validation logic is specific and I can’t use standard Django Admin model.

After thinking about it I decide that Django features and use ways are tight. I used Flask before and it was pretty customizable for specific tasks and easy for understanding (Django has tones of code that I need to understand for deep customizing and class overriding). I prefer Flask for specific tasks

But other members like Django and don’t understand Flask, so can you recommend, what will be better and speedy: try to learn Flask or try to customize Django for my tasks?

Sorry, my question is very bad and hard to do some recommendations, but I really confusing in this situation, so any hints and thoughts will be welcome.

Maybe my undestanding of Django fundamentals is still bad…

And, sorry for my English it is still not perfect yet. :slight_smile:

2

I think there might be some misconceptions here about how Django works - I’m reading this as if you are making a number of assumptions about Django that aren’t completely accurate.

Before diving into this, remember that both Django and Flask are written in Python. If there’s a Python library available that you would use in Flask, it can also be used in Django.

Responding to some of the items you’ve listed:

What XML parser would you be using with Flask? Why can’t you use that same parser in Django? (Last time I worked with XML in Django, it was to handle SOAP requests. We used one of the regular Python SOAP libraries to handle that with no problems at all.)

You also have full “raw” access to the request body. There’s no requirement that you rely upon Django’s handling of the request - giving you all the same flexibility that Flask provides.

We’ve found Django to be amazingly flexible, being able to scale equally well in both directions scale up and scale down.

I would say that more than half of all my Django projects are “non-standard needs”.

I’ve got a couple of projects where the UI is a set of buttons, where each button causes a view to use Paramiko to ssh to a different server to run commands on those target servers.

I’ve got one Django project running on a Raspberry Pi 3B+ that transfers data to/from an Arduino Mega 256 across bluetooth for data collection.

I’ve got another Django project that doesn’t provide any web UI at all. It only exists as a set of management commands to perform some database manipulations.

Definitely not your typical UI flows - but we made the decision that it was still far more productive to use Django than the Flask system we previously had.

You can still use the standard Response class - you might not be able to use the standard render shortcut functions, but that’s a different issue. Not sure how that’s going to be any different from Flask though.

I don’t get you here. Can you be more specific as to what you think doesn’t fit?

I would disagree here. Once you’ve learned enough about Django to know where the supplied generic views don’t fit your needs, then don’t use them.

Now, none of this should be construed as bashing Flask - Flask is a wonderful framework, and does cover some use-cases that Django doesn’t.

But, about 4 years ago, we made the decision to standardize on one web framework rather than 3. (We also had some Bottle in the mix) And looking at our complete environment, we decided to land on Django. Yes, we have some apps that take very little advantage of what Django provides, but it doesn’t hurt us any to just ignore those features.
On the other hand, having one ORM / data model / command framework that everything builds on provides a degree of uniformity and consistency across our applications making it a whole lot easier for people to move between projects.

To wrap this up, I would say that it’s possible that it’s not so much that your understanding of the Django fundamental is “bad”, but that perhaps you’re thinking that those features are required instead of being components that are available for you to use - if you find them useful. They’re not constraints that limit you or prevent you from doing other things.

(Oh, and finally, please - there’s no need to apologize for your English. Your English is infinitely better than my <any language other than English>)

Ken

3

Ken, Thank you for answer.

What XML parser would you be using with Flask? Why can’t you use that same parser in Django? (Last time I worked with XML in Django, it was to handle SOAP requests. We used one of the regular Python SOAP libraries to handle that with no problems at all.)

Actually XML is okay. That was my mistake with bad request body.
Anyway, in opposite side what is reason to use Djando if I can get same behavior with Flask?
Of course I can use my python libraries at both frameworks, but flask looking less monolithic, my development costs also pretty close, because there is same libraries and same logic, and I can’t use built-in security benefits of Django (because of use lower classes and control behavior by myself).
Isn’t features of standard View class in Django pretty close to flask_restful’s Resource class?

Definitely not your typical UI flows - but we made the decision that it was still far more productive to use Django than the Flask system we previously had.

Please, can you example reasons? What means productivity in your case?

I don’t get you here. Can you be more specific as to what you think doesn’t fit?

Hm. for example, I receiving data:

<xml ...>
<auth>
  <user>AAA</user>
  <password>BBB</password>
</auth>
<data>SOME DATA</data>

If AAA/BBB matching with DB record then do action. No cookies, no sessions, no tokens needed. Can I simply customize standard auth methods for matching to my criteria?

I would disagree here. Once you’ve learned enough about Django to know where the supplied generic views don’t fit your needs, then don’t use them.

If my understandings is right there is two (three) classes of Views: view as is (or ApiView), generic view and model view (hello, DRF).
Generic and model views are really awesome. There is many out of the box features. But standard View features pretty close to Flask’s (+some libraries) features. And I little bit confusing what is better override generic class and get it features or use standard View and do what I can do with Flask?
Also I want to dynamically create openapi scheme and model Views supports annotations, comments, descriptions, etc. out of the box.

If I using Flask I know that I need to write all functionality. In Django’s case I confuse with what I can use out of the box and what I need to write, and how to write it? Try to deeply understand all Django instruments and classes or ignore that and write how I can, using another libraries.

4

When asked that question, I start by looking at that issue from the reverse angle:
Q: Why should I use Flask if I can get the same behavior by just writing it in Python?
A: Because Flask is the set of Python code that I am likely to need to write anyway if I wanted to do it in just Python.

So, do address your question, I choose Django because there is some percentage of functionality that I would need to write myself for Flask, that has already been written for Django. (An intrinsic ORM and a command line facility to name two.)

Sure you can - or, at least, you haven’t identified any reason why you can’t

At the moment, our team supports 8 - 10 different Django applications (I think - I might be missing one or two and there’s a chance that one of them has been deactivated, so I’m honestly not sure of the count off the top of my head.) People are constantly switching between them. Part of the “productivity” is understanding how the code is structured, knowing where to look in the directory structure, and remembering enough of the API to be able to make changes without having to constantly remind yourself of the differences between frameworks. So standardizing on one framework reduces the friction that comes from moving between tasks.

Absolutely. See Customizing authentication in Django Or, thinking about this some more, you probably don’t need the authentication module at all. Your view can accept the data, perform whatever validation of whatever fields necessary, then either return a response or the appropriate error code.
In fact, if this is done on every request across almost every view, you might even think about encapsulating that test as middleware.

Those are just subsets (standard components) of what Django considers a “view”. Taking the most basic concept, a view is any callable that accepts a request and returns a response. Everything beyond that are just special cases of that fundamental function.

I look at this from the other direction.

  1. I identify what it is that I want to do.
  2. I look to see if there’s a standard facility that does it
  3. I look for a third party package (usually starting from djangopackages.org) providing that functionality
  4. Otherwise, then I write it myself.

That’s part of the learning curve. Understanding Django’s architecture is an important part of being effective with Django. There’s a lot of goodness in the package - and understanding how all the pieces fit together isn’t trivial - but, in my opinion, very worthwhile.

What comes with experience is knowing what to look for in steps 2 and 3 above that might shorten your development time, and recognizing the patterns that exist across many applications. Yes, that experience takes time to acquire - and even after six years, I still miss some opportunities because I’m not aware of them.

I’d rather use other people’s code that has been carefully crafted, tested, and being supported by a number of people than rely only upon my own code. I have learned over time that they’ll typically handle edge-cases and exceptions that I wouldn’t even necessarily realize were issues.

Reading and understanding the Django source code is a Master Class in Python all by itself.

I would suggest not trying to understand in detail how those classes work - I’d suggest focusing on what they do for you, and then only worry about understanding the mechanics when you run across a situation that isn’t handled normally.

5

@KenWhitesell

I see. Thank you. There is a lot information for thoughts