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

Django 4.0

djangoproject.com

Post reply on HN
Print view View original

211–220 of 226 posts

Re: Django 4.0

#211

Post by jimnotgym »

abdusco wrote: post #34
jimnotgym wrote: post #27

Earlier quoted context omitted.

I was checking out Express...how do I get user logins, oh just npm in 50 other projects, adding 50000 dependencies. Back to Django then!

The difference between Django and Express.js is that one is a fully-fledged web application framework, while the other is a micro framework that just gives you a simple request -> response abstraction over `http.createServer`. I find Flask is more comparable to Express.js in that regard. Need auth? You need to: 1. Install a lib for persistence 2. Set up cookie sessions, or install another lib for JWT 3. Set up auth m…

I guess my surprise came from asking around about what framework to use and being told it was Express. I guess it might be 'Sails', but it's been a week or two so that is probably obsolete now.

Re: Django 4.0

#212

Post by tiangolo »

Majestic121 wrote: post #14

We went all in on FastAPI with my team, but we're hit the issue that the projects of Tiangolo (FastAPI, SQLModel, Typer) seem to be turning pretty much unmaintained : https://github.com/tiangolo/fastapi/discussions/3970 We've already been hit by multiple bugs with fixing PR opened, but left to rot, and missing documentation : the 'tutorial' documentation is great, but if you want a reference you have to go read the c…

Hey! FastAPI author here. I do have a bunch of issues and PRs to review across the projects. But as I personally review and in most cases fine-tune and update each one of the PRs (if you check the history, almost no PR is directly merged, most of them require updates) it's taking me a bit to handle them all, but I'm on it. I even changed my working structure to optimize for more open source. Sadly, new issues and new discussions like that one linked asking why the other issues are not solved, don't really help, as they just add another issue for me to read and take care of. I'm also prioritizing the work that can have the most impact. For example recently I was helping a bit with AnyIO and Trio, as they are used underneath by FastAPI. And now I'm working on something for Pydantic, that would be used by SQLModel and FastAPI.

If you want to see faster progress, there are several ways to help, they are all documented here: https://fastapi.tiangolo.com/help-fastapi/

One of the things that consumes time the most is handling issues by others. If you go and help them and they close those issues, that's a lot of minutes (in some cases hours) that you save me, and that I can then dedicate to review the other issues and PRs.

Re: Django 4.0

#213

Post by robomartin »

reducesuffering wrote: post #201
robomartin wrote: post #198

Earlier quoted context omitted.

Not sure that your link is an answer to my comment. Whatever the case may be, I can take a single VPS and multi-host a bunch of domains, each with it's own Wordpress installation, DB, etc. Virtual hosts makes this possible. It's stupid simple. Getting a single Django application running under a single domain on a VPS is a nightmare. Particularly when you consider everything you have to do to migrate from the developm…

I agree, although as my other comment states, the most frictionless way I’ve found is to make a quick docker-compose, and run maybe 5 Dokku commands on the server. Then from dev environment just ‘git push dokku’. That’s the level of friction we should also expect from Django built in.

I missed that in your prior comment. Yes, I think you are right. Docker --which I kind of hate to admit-- seems to be the only low friction solution at this stage.

This is why I insist that the Django dev team ought to put some thought and effort into fixing this issue. If Django installed in a realistic baseline production configuration (not a toy DB, runserver, etc.) and came out of the box with a super simple mechanism to deploy to the average VPS the framework could become 10x more popular than it is today.

Nobody could blame a developer looking that the Digital Ocean deployment tutorial you linked to and thinking "f-ck this!". I can even see said developer using that as an argument against Python/Django if management was involved in making a platform decision.

There are dozens of articles just like that one that are multiple pages long. To me that constitutes absolute proof that deployment in Django is seriously flawed, if not broken. I hate to say that because I love the framework, but c'mon, the fact that such articles exist pretty much says this is ridiculous.

Re: Django 4.0

#214

Post by lowercase00 »

tiangolo wrote: post #212
Majestic121 wrote: post #14

We went all in on FastAPI with my team, but we're hit the issue that the projects of Tiangolo (FastAPI, SQLModel, Typer) seem to be turning pretty much unmaintained : https://github.com/tiangolo/fastapi/discussions/3970 We've already been hit by multiple bugs with fixing PR opened, but left to rot, and missing documentation : the 'tutorial' documentation is great, but if you want a reference you have to go read the c…

Hey! FastAPI author here. I do have a bunch of issues and PRs to review across the projects. But as I personally review and in most cases fine-tune and update each one of the PRs (if you check the history, almost no PR is directly merged, most of them require updates) it's taking me a bit to handle them all, but I'm on it. I even changed my working structure to optimize for more open source. Sadly, new issues and new…

Totally understand your point, makes sense, and indeed if the community were to be more supportive with issues/PR it would be very helpful for the project.

Seeing this kind of topic fairly frequently, it would be great to understand the short/mid/long term plan for the project in terms of governance.

I guess we can all agree that having a single maintainer on a +40k stars project with huge adoption (amazing stuff btw) is unsustainable and extremely difficult, and can drive people away from adopting it in big corporations (I've seen a few comments on Github that mention this), and can make early adopters eerie.

I honestly have no idea on how to do that, but some other projects have been able to (fairly) successfully descentralize the development to be able to keep pace with the development.

It's obviously fair and understandable if the long term will still depend entirely on you, being the creator, you obviously have 100% right to do things the way you want, and nobody can argue against that.

I guess it could be helpful to give the community some guidance on what's the idea for the future of project, and whether it will have a more distributed governance or if it will continue being centralized.

Any of those paths is fine of course, I guess it would just help people deciding the framework choice for the future.

Re: Django 4.0

#215

Post by lambdadmitry »

rlawson wrote: post #45

Django has allowed me to enjoy some side entrepreneurship. I have released three products as a solo part time dev that I would never have been able to do in a reasonable time using Java/Spring (my strongest stack). My first project went nowhere, but the second generated 1k+ a month and sold for 50k, and the third one is following a similar trajectory. My advice - keep it simple - function based views - centralize acc…

Ideally try to avoid using Celery at all. It's the most consistently buggy, poorly documented, worst quality major Python project I have used so far.

Here is a fresh example: they deprecated CELERY_ prefixes in Django settings for some reason, which makes zero sense [1]. But because it's Celery, they only warn on a few properties but not others, and the tool they ship inexplicably renamed completely unrelated settings for me [2]. And yes, apparently the new way doesn't work either [3].

It's very characteristic of what I've seen from Celery over the last few years of working with it. If you are doing anything greenfield, it's best to avoid it altogether.

[1] https://stackoverflow.com/questions/65554242/celery-imports-...

[2] https://twitter.com/lambdadmitry/status/1468337594358546435?...

[3] https://github.com/celery/celery/issues/7140

Re: Django 4.0

#216

Post by regularfry »

samwillis wrote: post #86
regularfry wrote: post #77

Earlier quoted context omitted.

The argument is that Active Record is itself a bad pattern that you should not use. And it may be. But it might be a long way down the runway before you run into the bad effects.

Yes, exactly, I agree there are valid arguments against active record, partially at scale. However, I believe, certainly when starting out on a new project/startup, sticking with the standard recommendations and patterns provided in the docs for Django and DRF you make life much easer for on boarding new people to the project later on - they will have seen it all before. If you get big enough where the standard patte…

The problem I tend to see is that the refactoring never happens. Instead the system becomes the legacy mess nobody wants to work on and eventually it gets replaced. If you get lucky, it'll be replaced by the people who wrote the first version, but it's more likely to be replaced by a team who weren't there when the first one was built, who will build it in this-year's-shiny, without learning the fundamental lessons of why the first version ended up that way so doom the next version to a similar fate.

Re: Django 4.0

#217

Post by hda111 »

rlawson wrote: post #45

Django has allowed me to enjoy some side entrepreneurship. I have released three products as a solo part time dev that I would never have been able to do in a reasonable time using Java/Spring (my strongest stack). My first project went nowhere, but the second generated 1k+ a month and sold for 50k, and the third one is following a similar trajectory. My advice - keep it simple - function based views - centralize acc…

+1 for trying to avoid celery. Too much complexity for simple asynchronous tasks. You should use it however if you are instagram (I think they use a customized Django and Celery).

Re: Django 4.0

#218

Post by tfehring »

rowanseymour wrote: post #195
tfehring wrote: post #98

Earlier quoted context omitted.

I can't recommend using Poetry in production - I've had massive headaches with it due to https://github.com/python-poetry/poetry/issues/697 Basically if you have two dependencies that depend on the same package, but depend on different versions or non-overlapping ranges of versions, Poetry's only solution is "tell the maintainers of your dependencies to update their pyproject.toml" - building your package will just f…

But doesn't even pip take that strict approach now?

Yes, and that's probably the right default behavior. But with pip I think you can still work around it, e.g. by installing the sub-dependency manually and then installing with --no-deps.

Re: Django 4.0

#219

Post by ac130kz »

WD-42 wrote: post #151
ac130kz wrote: post #40

Earlier quoted context omitted.

Any change you make has to be atomic, or it is unable to detect the change, and you have to rely on manual migrations.

What do you mean by this? Auto migrations detect changes in your models. I'm not sure what atomic means in this context.

Let's say you change some attribute and the name of a model, Django simply does not recognize it, nuking the whole attribute

Re: Django 4.0

#220

Post by bluewalt »

WD-42 wrote: post #146
aniforprez wrote: post #124

Earlier quoted context omitted.

I would say Flask is genuinely really difficult to use. It's very easy to start with but the moment your project becomes non-trivial, it's a mess of wires and plugs that resembles something like Django anyways but all maintained by you or your team. FastAPI seemed like something that's in a solid middle ground between something beefy like Django but something light like Flask and it's much easier to start with since…

Check out Django Ninja: https://django-ninja.rest-framework.com/ It's like a FastAPI inspired Django Rest Framework. In comparison to DRF it feels very lightweight and modern, but it's still Django underneath so you get to keep the ORM, admin, etc. Speaking of the ORM, once Django's is async Ninja will really be amazing.

I must +1 this, Django ninja is outstanding.
Post reply on HN