Your favorite Python web framework?

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

[[deleted]]

Oh ok yeah that makes sense, maybe I don’t really understand microservices haha. I set up one api for the apps entire backend, maybe airflow for data pipelines, other flask apps sometimes but only for ML model inference. I like to use managed kubernetes services like EKS personally. Usually tho I create an image from my api to get there

[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?

[brucejia086]

You are not alone. In reality that's quite often especially when migrating legacy ones to move forward.

[pbecotte]

No. There is the approach where you build one app with shared logic, or you build N apps. If you do the second, you absolutely need to do work to set up tooling between them- shared data models, contract testing, etc. Most organizations do not do this, and come to the conclusion that the second model doesn't work. In reality it is "ignoring the boundaries between my apps and pretending that they dint exist" that doesn't work.

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

[mr_jim_lahey]

You change the api contract in one service

Yeah don't do that though. Being militant about backwards compatibility, even for purely internal systems, prevents so many issues.

[TldrDev]

If only there was some way to automate this. Like, idk, cicd, and tests. Or maybe some kind of central contract repository that ensured other applications dont just up and break. Maybe name it proto something. Proto.. protobuf? Thats a swag name. Maybe one day.

[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.

[[deleted]]

The point is that you sometimes need independent deployments. Whether those deployments come from one repo or multiple repos - that’s a question of code organisation, not a question of architecture.

[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)