Frameworks
Post #7216 · source on Telegram
FastAPI Disappointment: Look Inside and Find No Fast
Description
A meme featuring a close-up photo of a grey and white cat staring directly at the camera with wide, disappointed eyes. The greentext-style text above reads: '> fastapi / > look inside / > no fast'. The joke plays on the name 'FastAPI' (the popular Python web framework) and the disappointment of discovering it isn't actually 'fast' in the absolute sense -- it's fast for Python, but still Python. The cat's bewildered expression perfectly captures the developer's realization
Use J and K for navigation
Comments
27Comment deleted
FastAPI: the 'fast' refers to development speed, not runtime speed. It's like calling a Honda Civic 'FastCar' because you bought it quickly at the dealership
FastAPI is fast until your ORM makes a synchronous call in the middle of an async route. Then it's just an API with extra steps
FastAPI is like that consultant résumé with ‘10x’ in the headline - you only discover the multiplier applies to response time once it’s in prod
After 15 years of optimizing microservices, you realize FastAPI's 'fast' is like MongoDB's 'web scale' - technically true if you squint hard enough and ignore the 500ms of Pydantic validation on your deeply nested DTOs while your k8s cluster autoscales into bankruptcy
After years of optimizing database queries, implementing caching layers, and fine-tuning connection pools, the senior architect finally discovered the real bottleneck: the framework literally named 'Fast' was just really good at marketing. Turns out 'FastAPI' refers to how quickly you can write the code, not how quickly it runs in production - a distinction that becomes painfully clear around 3 AM during a load test incident
FastAPI: Blazing benchmarks on idle, 'no fast' once Pydantic chews through your nested schemas
Open the repo: FastAPI behind Gunicorn sync workers, async def routes calling requests, SQLAlchemy doing N+1, Pydantic v1 models - congrats, you shipped WSGI with better type hints
FastAPI isn’t slow - our stack is: async routes calling a sync ORM, one uvicorn worker behind an Nginx that kills keep‑alives, stdlib json dumps, and zero profiling; the only fast thing was the naming meeting
It is fast tho Comment deleted
slowapi Comment deleted
Its fast outside too (fast prototyping) Comment deleted
It is fast in not responding Comment deleted
yeees. python slow. have you seen how slow a loop in a loop in a loop in python compared to C++ is? and that's exactly what we do in every our program, that means it's a proper metric, right? right? Comment deleted
in CPython*, PyPy would show you a very different performance Comment deleted
from my experience I've never had any performance improvements from PyPy, only the opposite, despite the promises of improvement 🤷♂️ Comment deleted
As with anything, it depends on the code. Enterprise-ready®™ code would crawl with it, for sure. Comment deleted
I try it from time to time. but only get lower performance and library incompatibilities Comment deleted
In competitive programming, PyPy (as opposed to Python) is often the only way to ensure your algorithm meets the time limit with large input sets. I also got a 3-4x boost in the performance after switching to PyPy for my game bot, which was bottlenecking on BFS for pathfinding. Comment deleted
Fast to build Comment deleted
It's fast for slow programmers 👍 Comment deleted
is that quote from the dev team of fastapi? Comment deleted
nah random redditor, but it sounds Comment deleted
Didn’t “Fast” refer to dev time? Comment deleted
Now we got granian to have it running even faster, python is slowly becoming rust (but at least we don't shoot ourselves in the leg unless we actually really really want to)😌 Comment deleted
python has plenty of footguns too Comment deleted
It's an interpreter written in RPython (subset of Python), compiler of which was written in Python. And it uses similar to CPython bytecode. And yeah, it might be a Monty Python reference Comment deleted
I mean, at least it has API in it Comment deleted