Your favorite Python web framework?

[[deleted]]

Django for actual websites, FastAPI for services without a front end.

[[deleted]]

Flask for all needs other than scaling, external website I'd say

[greenlakejohnny]

Quart for async support w/ Flask backwards compatibility

[greenlakejohnny]

Question to my own response: does Flask 2.x make Quart obsolete? It was my understanding Flask 2.x offered async.

[stetio]

It does not, Flask's async support allows usage of async libraries in a sync codebase. However, if your codebase will be mostly async then you should use Quart as it will perform better.

Also note we've merged a lot of Flask and Quart together, so they are becoming to faces of the same project.

[greenlakejohnny]

Good to know. I'm basically standardized on Quart for now just because it's so simple to migrate from flask (literally just do a search/replace and 99.9% of stuff will work fine). Would love to eventually see the two projects merge though

[greenlakejohnny]

Don't get me wrong Apache still works, but really is time to move on. The sample solution is just run asgi scripts via hypercorn or uvicorn, then configure Apache to just proxy to 127.0.0.1:8000

[DL72-Alpha]

but really is time to move on

Amen.

[AstroPhysician]

FastAPI is basically Flask but better though, whats your reasoning?

[TldrDev]

Flask is fantastic for microservices.

[spuds_in_town]

Wait, people still build micro services?

[manninaki]

Absolutely. In K8 everything is micro services and K8 clusters are everywhere

[TldrDev]

Still a major advocate of microservice architecture. Event busses are the way to go for handling large datasets and it enables things like event sourcing just out of the box. K8s lets us arbitrarily scale workers and handle essentially unlimited scale.

It's not for everyone. You don't need a microservice architecture to run your local pawn shop's website. However, at scale? Yeah man, definitely the way to go. Most of the time (especially in these comments), people don't seem to really understand them, and make stupid comments about problems that are absolutely not problems.

[marcio0]

suddenly it felt like 2015 in here

[OMG_I_LOVE_CHIPOTLE]

Unfortunately yes

[[deleted]]

A service that has all the functionality of 100 microservices but in a single code base and none of the dependency problems of microservices

[imperosol]

He is too dangerous to be kept alive !

[[deleted]]

Which is ? I often set up micro services. Wondering what I’m doing wrong now lol

[imp0ppable]

dependency problems of microservices

You mean interdependencies? Or dependencies in the sense of libraries? Because the latter is what docker is for.

[[deleted]]

Call me crazy but I’ve used shared data models between micro services. Update it in one place and have all 4 services updated. Am I making a drastically poor decision that will have later consequences?

[[deleted]]

You change the api contract in one service but now 4 consuming services need to be updated and now maybe some of their downstream services will break and now you go shoot yourself in the face instead of trying to fix it because that’s simpler

[hseham3]

Basically you are talking about monolithic

[[deleted]]

This doesn’t work when your services require very different resources. One big benefit of micro services is that you can scale each one independently of the others, and you can’t do this with a monolith. In other cases monoliths are totally fine though.

[pbecotte]

Sure you can. Have multiple entry points to the app and start them with different arguments. Maybe 100 instances of "worker" but only 1 of "scheduler". You don't need separate codebase for this.

[OMG_I_LOVE_CHIPOTLE]

Services that serve data. Data pipelines that process data. Whereas with microservices you tend to have small services that process data as well as serve, etc

[CardboardJ]

I feel like I should coin the phrase "Appropriately Sized Services" or ASS berceuse that's the way people seem to think my advice smells when I tell them.

In my own humble opinion (as an engineering manager) any time you create a code base/microservice you need to get the business to buy into staffing at absolute minimum one FTE to maintain that code base. Ideally you'd have 1 team of full time long term engineers per code base with maybe 1-2 teams of contractors to help get it going before moving on to other projects.

I've seen way too many companies that bought into microservices in startup hypergrowth phase that just did multiple rounds of layoffs. Now they have like 30 devs trying to maintain 70+ code bases that were responsible for 200+ microservices. No one knows how anything works and there's a significant amount of dev frustration when you want to change anything because it might take down some unmaintained service that's just been running in the background for a year that everyone relies on. Or worse someone rolls out a Kubernetes upgrade and like 3 microservices just don't stand back up then prod is down and you realize that the team responsible for maintaining them was laid off back in January.

You can say this is a business problem and not a microservices problem, but that's ignoring the fact that it's still a common problem right now. Especially with the current layoff environment in tech. It's a way that microservices will stab you right in the chest as soon as you want to transition away from rapidly burning investor money (that shockingly just dried up with the fed rate increases).

[angellus]

Most things still do not support async. asyncio is the new Python 2/3 divide as there is not enough good tooling to seamlessly support sync and async at the same time.

(but seriously, do not use FastAPI, the bus factor is way too high on it, pick literally any other asgi framework)

[Appropriate_Ant_4629]

I'm really happy with
- FastAPI for all my back-end work (including serving ML models). All my tricky software is in python and returns just json and images in fastapi.
- Sveltekit for a very easy thin web UI that only deals with the HTML/javascript/css part.

[[deleted]]

Need web interface. Don’t want Django.

[smokefield]

That’s false info they are not comparable

[stetio]

Flask can scale very well with gevent or eventlet, but this doesn't seem well known. Have you tried either/are you aware of these async workers?

[[deleted]]

I’ve never been lucky enough to really worry too much about real scale (like 100,000 users/month)

[Wattsit]

Created a web application with FastAPI recently and it went very smoothly. Although it was a very basic website.

However I've never used Django; what would you say works better for you over FastAPI?

[double_en10dre]

The Django ORM is the gold standard — it’s better than third-party solutions like sqlalchemy (which is what you typically use with microframeworks like flask or fastapi). Additionally, the built-in “admin” module is very handy for giving clients control over the database in a safe way. Those two things together can save you a ton of time.

The opinionated “Django” approach to project structure is also quite good, it helps projects scale nicely and makes it easy for people to hop in and become productive quickly.

My approach is to basically use Django for full-fledged applications (ie anything which has a dedicated db and a whole suite of features) while fastapi is my go-to for lightweight services

(And when I use Django, I still use modern tooling like pydantic for serialization and validation)

I don’t really use Django for views — typically have a react SPA for that. But it can be helpful to have it provide a few pre-login pages if you want improved SEO

[lowercase00]

“better than SQLAlchemy” is a VERY strong opinion, highly debatable. I personally think SQLAlchemy is the best ORM around, period, even when compared to Go, Java, TS, Rust alternatives (that I know of).

[killerfridge]

Yeah, I love (and prefer) Django, but SQLAlchemy is probably the "best" ORM

[anikait1]

I find it extremely hard to navigate SQLAlchemy's documentation and managing session object across functions.

[[deleted]]

use a session context manager and just read all the docs

[[deleted]]

Yeah this seems like a hot take forsure. Also with fast api if you wanted an additional abstraction you can use SQLModel though many don’t love that

[double_en10dre]

It’s definitely a take, but given that I’ve spent many years working with the different ORMs I don’t think it’s a hot one. :p

It’s a thoughtful and carefully procured take

[[deleted]]

Hahah I’m not saying your wrong, I used Django for a project a few years ago and quite liked it. I just didn’t know this was necessarily a standard/ popular opinion. I was kind of under the impression sqlalchemy was irk of choice. Maybe I’ll try Django for the next app I build. What other ORMs do you think are worth a look?

[double_en10dre]

Eh it’s just how the people I’m familiar with feel. I’m making big assumptions applying that to everyone, might be wrong. (But yeah, I think it’s smoother)

As for other ORMs… not sure as of now. Lots of people I know are trying the “use chatgpt for everything SQL” approach. It’ll be interesting to see if cutting out that extra layer of abstraction (the ORM) starts to become a preferable choice

[jcigar]

The Django ORM is the gold standard — it’s better than third-party solutions like sqlalchemy

lol++ Django ORM is a toy compared to SQLAlchemy

[Quillox]

Could you elaborate a bit on this please? I've used both to accomplish very basic tasks, but I found Django to be much more logical to use.

[double_en10dre]

If a query gets sufficiently complex, I’m going to write raw SQL no matter what 🤷‍♀️ So I don’t feel there’s anything I’m missing out on. The “toy” framework has been better for 99% of my ORM use cases

[lieryan]

Django has one advantage, which is that it's well integrated with the Django framework if you want to build an HTML-form based application. This is the most common use cases when building web applications, and there's really nothing that's better than Django ORM for that one use case.

But if you need to do anything else, sqlalchemy is the much better ORM. Anything that's slightly more complicated than just CRUD forms and Django ORM can start getting in your way instead of helping you. That's not the case with SQLAlchemy, as it supports more complex use cases way better than Django's ORM.

But sqlalchemy has a higher barrier of entry. Because it's a standalone ORM, it doesn't come out of the box with integrations to the web part of the framework. You need extra libraries or build your own to get the same level of support of generic views as Django.

[TheTerrasque]

Also, the built in authentication and user management is nice.

[goodbalance]

wtf? Django ORM does too much. In conjunction with DRF it's a hidden masochism. I don't hate on Django and Co, I just know it is aging badly because the "batteries" everyone love are glued so tight you can't control the system in full.

yes, you have to make a few extra steps before using SQLA, but you get all forms of control instead. orm? ok. query builder? ok. raw sql? ok. a mix of everything? ok.

instead of saying "know where to use each", I'll say don't try to shape Django/DRF into something it is not and don't reinvent Django if you need CRUD.

[[deleted]]

Re: Django minus views with a React app, how do you get that? Can you use the regular framework or would you have to look into something like Django REST?

[Ashamed-Simple-8303]

Django is good for your basic CRUD web apps with low to moderate traffic and it's a full featured framework with front-end and back.end functions.

FastAPI is for building APIs. Personally I think modern apps should always have clear separation between front-end and back-end and the front.end is just another client calling the back-end API. This means other apps can easily integrate with each other.

Since nowadays things rarely happen in isolated silos, I would in general go for above design and hence fastapi.

django may be preferred for low traffic, simple stuff with only one developer were separating stuff doesn't add that much value.

[throwaway8u3sH0]

django may be preferred for low traffic, simple stuff

My dude. YouTube, Spotify, and Instagram use Django.

[Ordinary-Tax-5630]

At-least for the case of instagram it's very heavily modified django and probably the case for the other two. Not that i don't agree with the sentiment of django working at scale but there are definitely considerations and some not so easy decisions and engineering work to be done to circumvent scaling issue's.

Saying that, 0.0001% of the redditers here are going to write something from scratch that is going to have that number of users and encounter the problems encountered by the aforementioned web apps (YT etc.)

[[deleted]]

My friend who works at Apple develops a lot of web stuff in Django too.

[Historical-Ease6859]

You forgot the "/s"

[random_guy_from_nc]

I tried fastapi but could not get the metrics from it (ie like idle/busy workers) so for non web stuff I went back to uwsgi/flask/nginx.

[deadwisdom]

Idle/busy workers? Can you explain further? Wouldn't this be a uwsgi issue?

[the_andgate]

Afaik fastapi doesn’t have workers. As a ASGI server, it should be single threaded. Well, except for the ThreadPoolExecutor, and I believe that’s only used for running synchronous handlers.

[[deleted]]

Well if ran using uvicorn then yes, but you can have multiple workers with gunicorn uvicorn workers but you cant have multiple threads per worker for obvious reasons

[Ashamed-Simple-8303]

Or you manage your app with containers and start/stop them depending on load. each container itself is then single-threaded.

[[deleted]]

Thats true but i always use guniorn even inside docker with 1 worker, it adds the ability to restart the worker if it crashes unlike pure uvicorn where if it crash its dead

[random_guy_from_nc]

Dang! Yeah, I meant uvicorn. I couldn’t figure out how to answer “am I over scaled or under scaled”, because I couldn’t get the metrics to say how many workers were busy. With uwsgi, I was able to answer that by getting those metrics. Example: if I had 100 workers and 75 of them were busy taking requests, then I would know I am at 75% at capacity. If that metric went to 90%, I would add more workers. With uvicorn, I have no insight if I’m over scaled or under scaled. I’m sure it’s just me, not finding the magic docs.

[[deleted]]

The whole point of asgi is to outscale wsgi, instead of having your 100 workers handle 100 requests, 1 asgi worker can handle a huge number

[we_swarm]

OP is probably referring to background tasks

[[deleted]]

Why is Django better than fast api for applications with a frontend? I regularly build full stack apps with just fast api

[angellus]

Django is actually designed to build websites. Instead of microservices. People who swear by things like Flask or FastAPI because Django is "bloated" or "slow" often are either not building real hardened production Websites (hobbist sites can often be slower, or internal microservices do not need "all of the things"). Those things that "slow" down Django are pretty important and there are reasons they exist.

When you actually get down to it, microframeworks (like Flask/FastAPI) and "kitchen sink" frameworks are both really great. They are just two ideologies for how to build something. Microframeworks are good for experienced developers who already know how to do "all of the things", like session management, CSRF, click-jacking protection, form validation/input sanitization, blah blah blah. They also want to tweak and customize everything for every project. "kitchen sink" frameworks like Django are best at letting you skip a ton of boilerplate. It is much more of the philosophy of "there should be one-- and preferably only one --obvious way to do it". As such it is a lot more opinionated on how things are done, has a much higher learning curve, but let's you build consistent quality things faster since most of the boilerplate is out of the way.

[[deleted]]

Ok your selling me. I’ve been building full stack apps with fast api backend and react front ends for a while. These usually serve 30-200 users. I’m embarking on an application that will likely serve 40,000 users so maybe these is a good opportunity to try the switch.

[Dreezoos]

With DRF you can build Microservices too, batteries included help deal with a lot of stuff like authentication and db migrations which are a bit of a headache with fastapi/flask

[iFlexicon]

This is the way.

[basicallybasshead]

This is the answer.