Live data from Hacker News

Django 3

docs.djangoproject.com

141–150 of 196 posts

Re: Django 3

#141
post #136

Zulip has been powered by Django since the very early days of its development with Django 1.4, back in 2012. As a reasonably mature web application with significant scale, we're at the stage in many companies' development where one starts to rip out more and more of the web framework to optimize things or just make them work the way we want. (E.g. while I was at Dropbox in early 2016, we discovered we only had about…

If you don't mind: what are the key things that make Django useful for a project like Zulip? How much does the framework help you, and where? What are the places where you have to go against the grain, if any?

I'd say the big thing is helping us avoid reinventing the wheel. There's a lot of problems that every webapp has, and Django provides a system for solving most of them. I particularly enjoy their migrations and automated testing systems. When we need to integrate something that a lot of other people have, whether it be 2FA or SAML or LDAP or webpack, there's generally a reasonable library for it (or often, a reasonable way to do it built in, and Django's documentation is great so it's easy to figure that out).

While there are some land mines with any ORM, the Django ORM does allow us to write the vast majority of our database operations with clean Pythonic code, rather than going to raw SQL. We need SQL in a few performance-intensive code paths, but it's the exception, rather than the rule, and the ORM is constantly getting better.

And in contrast with some other ecosystems I've worked with, the libraries generally are well-written, well-tested, and stable, so even if they're not well-maintained because the old maintainer changed jobs or got busy or whatever, it doesn't feel like a burden to fork or adopt the library.

I'm not particularly happy with Django forms or Django REST framework with how they organization validation code. For the former, I think the problem is just kinda messy; we mostly solve it by only using Django forms for the authentication code paths where we can reuse its libraries. For the latter, we have a framework we built that I'm very happy with and we plan to spin out for other projects to use when we have a bit of time. There's some documentation here: https://zulip.readthedocs.io/en/latest/tutorials/writing-vie... for those curious; though that doesn't cover cool details like the mypy integration we did more recently.

Re: Django 3

#142
post #38

I have been using FastAPI for the last two months (which also is an ASGI server and makes full use of annotations and type hints with mypy) and the experience has been incredible. ( https://fastapi.tiangolo.com/ ) If Django can now also support annotations and async code I dream of an scenario where apis can be built using this two elements. Does anybody know a good resource to learn/catch up with this release?

I liked this (and other!) episodes of Django Chat, https://djangochat.com/episodes/django-30-preview

Re: Django 3

#143

Zulip has been powered by Django since the very early days of its development with Django 1.4, back in 2012. As a reasonably mature web application with significant scale, we're at the stage in many companies' development where one starts to rip out more and more of the web framework to optimize things or just make them work the way we want. (E.g. while I was at Dropbox in early 2016, we discovered we only had about…

One of my favourite things with Django has been their mature approach to changes. Want to be guaranteed a stable upgrade? Step 1: Fix deprecation notices. Step 2: Upgrade. (If you're upgrading over a few releases, return to step 1). Coming from other frameworks it's a delight :) At least that's been my experience with smaller projects. I'm curious, does that line up with your experience with Zulip, too?

I've personally never had a painless Django upgrade (except for patch releases). I always seem to fall into that grey area where I'm relying on undocumented behaviour of documented features (e.g. not using framework internals per se). I remember one Django release which changed the behaviour of views that returned files to download (it was probably Django 1.4), but there was no mention of that in the release notes.

Sometimes I've knowingly relied on framework internals in ways I expected to eventually break, but those situations don't represent the bulk of my experience with painful upgrades.

Re: Django 3

#144
The community built around Django, coupled with the sheer amount of documentation and the stability of their APIs has done enough to forever ruin my expectations for any other coding project out there. Ostensibly everything else feels disorganized, poorly documented or rushly released.

But the most commendable value of the DSF – which I believe is a model to be replicated – is how effectively it has managed to both attract new developers and also mentor them so well that they have gone on to become core developers who maintain the framework later on.

I'm still subscribed to the django-developers mailing list, even if I have had no free time to contribute with more than a couple patches over many years, simply because I enjoy watching how incredibly smart and efficient developers collaborate.

Kudos to all of you guys, and congrats on achieving this big milestone!

Re: Django 3

#145

Having worked with Asynchronous python since the days of twisted, tornado - I haven't really found any real reason to switch to asyncio. Generally speaking the old forms of async syntax (@coroutine, @inline_callback) make it incredibly clear that you are executing code well outside of a sequential paradigm - they force you to think a little more about what is going on. The idea of Django throwing errors when you try…

> I also am very weary to mix asynchronous code with other primitives like threading, multiprocessing. If I am going the route of async programming - I usually just intend to optimize a single thread - and then I leave it up to the OS to optimize across multiple processes.

A lot of the time you simply can't not have another thread or process, for example, when you have a blocking library call or CPU intensive task.

Re: Django 3

#146
post #136

Earlier quoted context omitted.

If you don't mind: what are the key things that make Django useful for a project like Zulip? How much does the framework help you, and where? What are the places where you have to go against the grain, if any?

I'd say the big thing is helping us avoid reinventing the wheel. There's a lot of problems that every webapp has, and Django provides a system for solving most of them. I particularly enjoy their migrations and automated testing systems. When we need to integrate something that a lot of other people have, whether it be 2FA or SAML or LDAP or webpack, there's generally a reasonable library for it (or often, a reasonab…

Ooooh, I'd be very interested in seeing that spun out. I also find DRF borderline infuriating from a design standpoint.

Re: Django 3

#148

Zulip has been powered by Django since the very early days of its development with Django 1.4, back in 2012. As a reasonably mature web application with significant scale, we're at the stage in many companies' development where one starts to rip out more and more of the web framework to optimize things or just make them work the way we want. (E.g. while I was at Dropbox in early 2016, we discovered we only had about…

Hey, if you ever want to do a podcast episode that goes into your tech stack (why you made certain choices, how it's been going, deploying, etc.) let me know.

I'd love to have you on as a guest for a podcast I recently started called Running in Production.

Dan from https://realpython.com and I just did one recently. That site runs Django too. You can check that out here: https://runninginproduction.com/podcast/4-real-python-is-one...

Click the "Become a guest" button to get started if you want.

Note: If you're reading this and you're not from Zulip and you are running Django in production (or any stack) hit me up too.

Re: Django 3

#149
post #97

Earlier quoted context omitted.

I've replied to the post on the forum, but if this is the default way Jupyter runs then we're going to have to figure something out longer-term. Calling the Django ORM from an async thread just isn't safe...

Thanks for the reply and all of the great work. Using django in a notebook is definitely not a typical use case so I wouldn't worry about it too much. Ideally the ORM would be a standalone package that could be used outside of the web server context. (I know sqlalchemy is an option but then you lose all of the benefits of django)

Our developers love to work in notebooks running Django, it lets you iterate extremely fast.

Re: Django 3

#150
post #149
post #97

Earlier quoted context omitted.

Thanks for the reply and all of the great work. Using django in a notebook is definitely not a typical use case so I wouldn't worry about it too much. Ideally the ORM would be a standalone package that could be used outside of the web server context. (I know sqlalchemy is an option but then you lose all of the benefits of django)

Our developers love to work in notebooks running Django, it lets you iterate extremely fast.

Andrew already has a PR to fix this issue https://github.com/django/django/pull/12172
Post reply on HN