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

141–150 of 226 posts

Re: Django 4.0

#141

Post by WD-42 »

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…

I think CBVs get a lot of unnecessary hate. DetailView, ListView, DeleteView, etc save so much time and repetition for basic CRUD pages. Once things get complicated and you start having to override too many methods, it's often best to write the post(), get(), put(), etc methods explicitly. At that point you are still writing CBVs but it's much more organized.

Re: Django 4.0

#142

Post by squeaky-clean »

Alex3917 wrote: post #88
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…

> 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…

I usually have a FBV handler (foo_handler) that just passes along all the required parameters to foo_get, foo_post, etc, and then takes the return value of those and wraps it in a HttpResponse/JsonResponse.

That way my actual view logic doesn't have to deal with anything http, and it makes testing them way simpler.

Re: Django 4.0

#143

Post by nickjj »

aniforprez wrote: post #124
windexh8er wrote: post #44

Earlier quoted context omitted.

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…

> 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

Do you have specific examples?

I've built a number of decently large Flask apps over the years (dozens of blueprints, 100+ models, etc.) and it was never an issue. I've used similar code organizational patterns in both small and large apps and it worked great. It was a combination of solo projects and working with small teams.

Re: Django 4.0

#144

Post by WD-42 »

Nextgrid wrote: post #54
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…

> typing I believe there's a third-party package "django-stubs" that provides type hints for Django code. For your own code, it's just Python in the end so you can type-hint it as you normally would. > Pydantic models integration There isn't as far as I know. Django has its own model layer however unlike Pydantic, Django's is purely for the DB level, it's not there to (de?)serialize JSON. In the Django world you'd ty…

Pydantic allows you to write super clean (in comparison to DRF) serializers using just type hints, as opposed to the declarative approach of DRF serializers. It's really nice and refreshing.

Re: Django 4.0

#145

Post by kaba0 »

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…

I’m sorry but I don’t buy that. Spring Boot is very highly productive — I really don’t believe any other stack would fare better by a significant margin.

Re: Django 4.0

#146

Post by WD-42 »

aniforprez wrote: post #124
windexh8er wrote: post #44

Earlier quoted context omitted.

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…

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.

Re: Django 4.0

#147

Post by WD-42 »

nickjj wrote: post #143
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…

> 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 Do you have specific examples? I've built a number of decently large Flask apps over the years (dozens of blueprints, 100+ models, etc.) and it was never an issue. I've used similar code organizational patterns in both small and large apps and it worked great. It was a combination of…

I share OP's general statement. I've been using Flask and Django on and off for near a decade.

When deciding between Flask and Django, I look at the following requirements:

User accounts

Object Relational Manager

Database Migrations

User registration/social authentication

Admin Site

As a general rule of thumb if my project is going to need 3 or more of these things I just go with Django.

You CAN do all of that with Flask, but you end up wiring together a bunch of third party dependencies just to end up with what Django would have provided you out of the box.

Re: Django 4.0

#148

Post by _peeley »

matsemann wrote: post #66
nisegami wrote: post #55

Earlier quoted context omitted.

>avoid fat models, use a service layer I had not heard the term "fat models" before so I googled it. It did not go in the direction I expected.

Another classic is "c string".

Every time I need to write up a research paper in TeX and insert a graph, I make the same mistake of searching "latex images" and getting some pretty exotic results

Re: Django 4.0

#149

Post by WD-42 »

ralmidani wrote: post #117

Django made me fall in love with programming. I built 2 decent-sized side projects with Django. They didn’t gain traction, but I loved using the framework. Then I went through a couple of (depressing) years of using Java/Spring professionally, and recently I made the choice to move to Elixir/Phoenix. It’s going great, and I don’t think I would go back to heavy OOP if I didn’t have to. Some things I really miss from D…

> - True async up and down the stack. Not a small task within the Python ecosystem, but I think for folks who are not already invested, looking at Elixir/OTP/Phoenix is too tempting. If you don’t have kids to transport with you, a Lambo looks much more fun than an S-Class Sedan.

This has been in the works for a few years. Everything in Django works with async except the ORM at this point. Which in practice, means it's not really async. But hopefully they are getting close.

Re: Django 4.0

#150

Post by bobbyi »

matsemann wrote: post #66
nisegami wrote: post #55

Earlier quoted context omitted.

>avoid fat models, use a service layer I had not heard the term "fat models" before so I googled it. It did not go in the direction I expected.

Another classic is "c string".

When I first started using the python tool/ library named fabric, I knew that putting just "fabric" into google would not get me what I wanted, so I instead searched for "python fabric". The top results were trying to sell me handbags and boots.

(These days, the library does rank first for "python fabric").

Post reply on HN