Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Django Newbie Mistakes

code.djangoproject.com

Post reply on HN
Print view View original

191–200 of 225 posts

Re: Django Newbie Mistakes

#191

Post by travisjungroth »

danpalmer wrote: post #112
jnbiche wrote: post #72

Earlier quoted context omitted.

> I've had the "pleasure" of working with other large projects built on flask and ever time it gets to a certain size I wonder why we didn't just use Django. Actually, I've had the exact opposite experience. I like using Django for small and mid-sized projects, because with Flask I have to spend time adding all these extra libraries for universally required functionality on a quick app whereas, with Django it's plug…

For what it’s worth, on a Django codebase of 180k lines, 100k lines of templates, 1000 URLs, 380 “apps”, 350 models, we have a nice coherent structure across the whole codebase that makes us really productive. I haven’t seen a Flask code bass do this anywhere near as well. They all seem to end up becoming very different and tricky to onboard new devs onto because they are so custom. Django hides some complexity, but…

What does that Django project do?

Re: Django Newbie Mistakes

#192

Post by jojo64 »

thijsvandien wrote: post #100
jojo64 wrote: post #97

Earlier quoted context omitted.

We are in python 2.7 and we need to migrate the application to python 3.0 For me it's another language to learn if we want to make good python 3 code. Python/Django/DRF is a stack with very poor performance if you are dealing a lot with JSON. We already have API points in golang with very good performance. No need to deal with nginx/CGI etc. nightmare. Conclusion was that our code in golang has a lower downtime. (Typ…

The changes from Python 2.7 to 3.x are hardly so dramatic that it's like learning a new language. I'm pretty sure your performance issues can largely be addressed after proper investigation where the bottlenecks are. I do understand how nice it is to have a simpler architecture, but make sure it's worth all the work.

Well we can migrate to python 3 but this will be more investment in a stack that is more and more obsolete (Django) for SPA. Developers need also to learn the new best practices for python 3. At the end this will result in short term with python 3 code base written in python 2 style without the benefits of typing etc. Investment without benefits except keep our stack up-to-date.

Each solution for Python/Django add complexity: - async -> celery/rabbitmq - websocket -> Channels, Daphne, asgiref, channels_redis, redid.

It's quite huge to manage.

Re: Django Newbie Mistakes

#193

Post by jojo64 »

Xixi wrote: post #177
jojo64 wrote: post #97

Earlier quoted context omitted.

We are in python 2.7 and we need to migrate the application to python 3.0 For me it's another language to learn if we want to make good python 3 code. Python/Django/DRF is a stack with very poor performance if you are dealing a lot with JSON. We already have API points in golang with very good performance. No need to deal with nginx/CGI etc. nightmare. Conclusion was that our code in golang has a lower downtime. (Typ…

I love Elixir (more so than golang), so I would sincerely recommend using it. Erlang concurrency story is lightyears ahead of Python3 asyncio (despite being older by maybe 20 years). And OTP has no equivalent anywhere. But if you are migrating just to avoid spending a couple of days learning and migrating to Python 3 based on reading too much FUD I'm very saddened. Migrating from Python 2 to Python 3 is not much hard…

The goal will be to take benefits of the elixir/OTP platform and the concurrency assets. Today we have a lot of asynchronous/background task distributed with rabbitMQ. If our investment provide better stack and simplify the architecture , this could be a better ROI than keep the current stack up-to-date.

Re: Django Newbie Mistakes

#194

Post by jojo64 »

Xeronate wrote: post #147
jojo64 wrote: post #97

Earlier quoted context omitted.

We are in python 2.7 and we need to migrate the application to python 3.0 For me it's another language to learn if we want to make good python 3 code. Python/Django/DRF is a stack with very poor performance if you are dealing a lot with JSON. We already have API points in golang with very good performance. No need to deal with nginx/CGI etc. nightmare. Conclusion was that our code in golang has a lower downtime. (Typ…

I'm surprised you are worried about JSON performance and not ORM performance. It seems like if you really needed better serialization/deserialization you could just call a c module from python.

Good point. Lost of performance in the query is acceptable a as we gain support of MySQL & Postgresql. Lost of performance in JSON serialisation is more difficult to accept.

Re: Django Newbie Mistakes

#195

Post by jojo64 »

aidos wrote: post #161
jojo64 wrote: post #97

Earlier quoted context omitted.

We are in python 2.7 and we need to migrate the application to python 3.0 For me it's another language to learn if we want to make good python 3 code. Python/Django/DRF is a stack with very poor performance if you are dealing a lot with JSON. We already have API points in golang with very good performance. No need to deal with nginx/CGI etc. nightmare. Conclusion was that our code in golang has a lower downtime. (Typ…

Normally people use something like uWSGI to host python apps behind Nginx - in any case, it’s something you figure out once and pretty much never deal with again. So it shouldn’t be an ongoing nightmare. While I didn’t downvote you, I suspect the people that did have done so because it sounds like you’re making quite a naive mistake in blaming the tool for your issues. Changing language is almost certainly the wrong…

Well I don't blame python. It's just that the stack python/Django/DRF is not more efficient for us now as our requirements changed spa/ws/asynchronous tasks. Investing in this stack is more and more difficult as our requirements don't fit. But yes we can also check flask/sqlalchemy . I'm just afraid of the stuff needed for ws/asynchronous task. This will not simplify our architecture.

Re: Django Newbie Mistakes

#196

Post by rahimnathwani »

tiglionabbit wrote: post #57
tosh wrote: post #3

Django’s documentation is still the best I have worked with so far of any software project I came across to date. It not only explains, it educates.

I vastly prefer Flask's documentation ( http://flask.pocoo.org/docs/ ). It explains everything from a perspective of what your use case would be, and they've gone above and beyond in covering use cases that might otherwise have been deemed outside their scope.

I really like flask's documentation, too. But somehow the explanation of blueprints didn't work for me, even after reading it several times.

Re: Django Newbie Mistakes

#197

Post by tiglionabbit »

pure_ambition wrote: post #120
tiglionabbit wrote: post #44

A lot of these things are only common mistakes because of Django's unusual behavior. > POST to views loses POST data The middlewares shouldn't be redirecting POSTs then! They could have returned a client error instead. > Blank object names They could have provided a fallback of __class__.__name__. > Integer & NULLS If the admin interface knows the field is required, why does it even attempt to insert a null value? It…

> To me, the Django project exudes the stubbornness of the developers who maintain it because rather than fixing these problems they've decided to write this page about how it's you, the user, who is wrong. Sounds like you're doing the same thing. You have a set of expectations about how the world works that is not the exact same as Django's - which is true of any other tool anyone uses. Also I want to point out that…

Back when I was interested in Django I'd go to Python meetups and hear people complain about how the Django project would not accept their patches. They told me that third party changes never make it into Django. That "contrib" is a lie, and that it's made almost entirely by core developers.

Ultimately I found Django to be more trouble than it's worth. I only use it if my work forces me to. I find its design to be obtuse and unpleasant in many places.

Re: Django Newbie Mistakes

#198

Post by kraptor »

paulie_a wrote: post #180
mixmastamyk wrote: post #173

Earlier quoted context omitted.

There are also lengthy guides on each part ORM, Templates, etc.

The problem is they quite frankly suck. The official ones are incredibly dry and not approachable by someone wanting to get started and do anything meaningful. I've helped people learn Django and the official docs/guides are the last on the list of recommendations. there are so many better resources to look at first. I've told people to skip the polls app and go through Django girls tutorial. The polls app is a waste…

May be the django book might be the approach you are looking for...

https://djangobook.com/the-django-book/

Re: Django Newbie Mistakes

#199

Post by douglaswlance »

davzie wrote: post #27
tosh wrote: post #3

Django’s documentation is still the best I have worked with so far of any software project I came across to date. It not only explains, it educates.

I find it some of the hardest documentation (close to AWS) to understand the best way to do something. I think it's great if you know what you're doing or you have a rough idea of what to do but need more information, but for someone new to the framework it makes me want to paper cut the webs of my fingers and bath my hands in vinegar because it would be less painful.

Not trying to sound overly-pedantic, but have you tried reading them? Not skimming them. Reading them start to finish. One line at a time, in order.

Try it. You'll understand what we mean when we say they're good.

Re: Django Newbie Mistakes

#200

Post by douglaswlance »

dwaltrip wrote: post #186
douglaswlance wrote: post #41

Earlier quoted context omitted.

If that's the case, you should take a step back and think about it from another angle to make absolutely sure that you're not attacking the problem from the wrong vector.

I have heard great things about DRF, and often it is good to resist coloring outside the lines. That being said, your comment assumes that DRF has indeed thought of everything. All abstractions leak, some more than others. Clean escape hatches are very valuable.

I never said that you MUST be thinking about it wrong. I just said to make sure you're not thinking about it wrong. No framework has thought of everything.
Post reply on HN