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

121–130 of 226 posts

Re: Django 4.0

#121

Post by exdsq »

myth_drannon wrote: post #13
nanna wrote: post #3

I must learn Django, it's got everything I'll ever need. No, Rails will make me happy and it's better for lonely devs like me. No I must learn a Modern Web Framework (TM) to prove I'm not stuck in the past. No way, I'm not a fashionista. Have you seen that Phoenix demo where the guy builds Twitter in like 4 minutes? That's the future. Hold on a minute, enough of this magic. I need to learn to build everything in Comm…

That's me. Once a year I get burned out from all the new languages and frameworks and decide to learn Common Lisp again for the 10the time.

Hahahaha you've just described my life too

Re: Django 4.0

#122

Post by matsemann »

rlawson wrote: post #68
matsemann wrote: post #56

Earlier quoted context omitted.

It's great for getting things up and running. And can last a long time. But now that we're 40 devs or so working in the same 400k LOC codebase, I'd prefer Java/Spring (or really, Kotlin). So hard to maintain django in the long run, need to be really strict, or one ends up with each app spaghettied with other apps. Doing queries where you filter deep on other apps' models, and since it's only done as kwargs with no ty…

I can see that happening on a large codebase with a lot of devs. Being a Java guy, I organized all the business logic and db access into a service layer, added type info and wrote a decent amount of unit tests. I can't deny however that I am 2x faster cranking out crud screens in Django than in Java and the combination of ORM, migrations, templates, and access to the 3rd party app ecosystem is a real productivity boo…

Yeah, for a simple app, it's so quick to get some auth, rest endpoints, a fine admin panel etc.

Problem is when you start abusing stuff. Just hook into some signal to do something, nbd, but suddenly it's an interconnected mess. Just add some custom stuff to the admin page, and suddenly what should have been a custom made page is now a weird mess it's hard to extend. Need to do stuff async in the background, and what could have been adding a task on some queue and having a thread poll it is instead this behemoth of complexity.

A large django app can also be good, I think, but then one at some part have to realize when to stop tweaking built in django features and write custom stuff, to avoid adding hacks on top of hacks. And also early stop doing the easy communication between apps, instead take the annoying detour around services and hard boundaries.

Re: Django 4.0

#123

Post by slig »

nickjj wrote: post #107
slig wrote: post #90

Earlier quoted context omitted.

Thank you very much! I've been running my own clobbed together version of a Django + Webpack configuration, and I'm very interested in learning from your code how you manage to run only one container with both Django and Webpack on dev mode.

No problem. I have things split out where the Webpack dev server runs in its own container only in development. It uses the Docker Compose override pattern to skip it in production along with Docker's multi-stage builds to ensure production assets get built and digested with collectstatic when DEBUG is set to false. I gave a talk this year at DockerCon on a whole bunch of patterns I use with Docker Compose and my Doc…

Fantastic, thank you so much!

Re: Django 4.0

#124

Post by aniforprez »

windexh8er wrote: post #44
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…

Genuinely curious how you happened to choose FastAPI over something more in the middle, like Flask? I tried a few tools in FastAPI, and it's fantastic for those, but I think I'd still stick with Flask for something more well rounded (not just as an API server).

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 it gives you REST and form/JSON validation out of the box

That said, FastAPI seems to have a lot of issues and the maintainer doesn't seem to be responding to the numerous PRs that are piling up. I'd much rather just stick with Django at this point

Re: Django 4.0

#125

Post by Nextgrid »

bitexploder wrote: post #105
Alex3917 wrote: post #88

Earlier quoted context omitted.

> function based views Class-based views, in their most basic form, are a lot easier to read. E.g. look at the DRF CBVs I have here: https://github.com/Alex3917/django_for_startups/blob/main/dj... If you can avoid Generic CBVs (things like ListView) and inheritance, then the only difference between FBVs and CBVs is that CBVs make it easier to see what's a GET / PUT / POST / DELETE by adding some syntax highlighting t…

Class views are fine. Even just a TemplateView saves some effort, but it comes with learning some Django magic about the life cycle of the view to load data in and out and what methods to implement. I still recommend it. You don’t have to fully embrace it and it lets you avoid repeating a lot of code.

My recommendation for learning class-based views is to use a good editor or IDE that allows you to drill down into the library code easily. In PyCharm/IntelliJ I can just command-click on the TemplateView symbol and see its implementation, and do so recursively until I've unraveled the entire thing.

Re: Django 4.0

#126

Post by dralley »

_tardigrade wrote: post #42

nowadays most people use Django to create REST API. I wish Django would merge DRF into its codebase.

At this point I disagree - DRF is a verbose and somewhat dated architecture. I wish they would provide something like Django Ninja / FastAPI.

Plus it already has decent async support.

https://github.com/vitalik/django-ninja

Re: Django 4.0

#129

Post by VectorLock »

stdbrouw wrote: post #76
pantulis wrote: post #67

Before Django there was Zope in python-land. I don't think I overstate the relevance of what Django did by saying that Django almost single handledy advanced the state-of-the-art of web deployment in Python forward a decade.

Zope hails from the era when Python was trying to appeal to programmers by showing that it, too, could be a Serious Enterprise Language. Everything had layer after layer of abstraction and the code looked more like Java than Python. The Zope ORM was kind of nice in its own weird way, though.

Zope had some things like the Language Is The Database trope that sort of remind of the things described in those Bank Python blog posts that have been floating around recently.

Re: Django 4.0

#130

Post by fernandotakai »

Nextgrid wrote: post #106
clepto wrote: post #75

Earlier quoted context omitted.

At least for my team we went with FastAPI because we have other tools for everything else, and FastAPI is incredibly simple for new members to pick up. We tend to say that we made a “FastAPI application” but in reality FastAPI is only powering the REST interface for interacting with the platform. We use SQLAlchemy for database interaction, a lot of direct usage of Pydantic, Celery with RabbitMQ/Redis for task process…

> We use SQLAlchemy for database interaction, a lot of direct usage of Pydantic, Celery with RabbitMQ/Redis for task processing. FastAPI provides a really lightweight interface to gluing pieces like this together. Just wondering, why have you not gone with Django directly if you’ve essentially ended up reimplementing your own version of it?

that's how i feel about all these python "micro frameworks".

you start simple, but then you realize you need some kind of db access, some kind of caching, some kind of authentication, maybe some admin interfaces.... aaand you re-implemented django yet again.

Post reply on HN