Pse FastAPI është i shpejtë, dhe si e mbani atë në atë mënyrë?

Question

Accepted Answer

FastAPI është ndër kornizat më të shpejta të Python-it sepse është ndërtuar në **Starlette** (një kornizë ASGI e lehtë) dhe është **async-native**, duke trajtuar në mënyrë efikase shumë kërkesa të njëkohshme të lidhura me I/O. Por për ta mbajtur të shpejtë kërkohet përdorimi i saktë i async — gabimi më i zakonshëm është bllokimi i event loop-ut.

## Pse është i shpejtë

```text
✓ ASGI + Starlette — a modern async foundation (vs older WSGI sync frameworks)
✓ Async-native — one process handles thousands of concurrent I/O-bound requests
  by overlapping wait times, instead of one-at-a-time
✓ Pydantic v2 — validation/serialization core is now in Rust (very fast)
✓ Minimal overhead per request
```

Modeli async është çelësi: ndërsa një kërkesë pret një pyetje të bazës së të dhënave ose thirrje API, serveri trajon të tjerat — duke dhënë përqindje të lartë për punë të lidhura me I/O.

## Mënyra #1 për ta mbajtur të shpejtë: mos bllokoj event loop-ut

```python
# ❌ blocking call inside async def → freezes the event loop, serializing ALL requests
@app.get("/bad")
async def bad():
    return requests.get(url).json()       # SYNC/blocking → kills concurrency

# ✅ use an async client and await it
@app.get("/good")
async def good():
    async with httpx.AsyncClient() as c:
        return (await c.get(url)).json()  # non-blocking

# ✅ OR use a plain def — FastAPI runs it in a thread pool (safe for blocking code)
@app.get("/also-good")
def also_good():
    return requests.get(url).json()
```

Kjo është rregulli më i rëndësishëm i performancës: një thirrje bllokuese brenda `async def` bllokon të gjithë event loop-un, duke detyruar kërkesën të ekzekutohen një për një. Përdorni biblioteka async me `await`, ose një `def` të thjeshtë (ekzekutohet në një thread pool).

## Ta mbajni të shpejtë — lista e kontrollit

```text
✓ Use async DB drivers / async libraries (httpx, asyncpg) in async endpoints
✓ Run blocking code in plain def (thread pool) or via run_in_executor
✓ Avoid heavy CPU work on the event loop → offload to workers/processes
✓ Add caching (Redis) for expensive repeated work
✓ Optimize the database (fix N+1, add indexes) — often the real bottleneck
✓ Run multiple worker processes (uvicorn/gunicorn workers) to use all CPU cores
✓ Use connection pooling; paginate large results
✓ MEASURE first (profiling, load testing) — fix the actual bottleneck
```

## Pse ka rëndësi

Shpejtësia e FastAPI është një arsye parësore për të cilën ekipet e zgjedhin atë, por arritja e asaj shpejtësie në praktikë varet nga **përdorimi i saktë i async** — dhe rregulli më i rëndësishëm dhe shpesh i shkelur është **mos bllokim kurrë të event loop-ut**.

Kuptimi se *përse* FastAPI është i shpejtë (themeli async-native ASGI, paralelizimi efikas i I/O, bërthamë e shpejtë Pydantic v2) sqaron se avantazhi i performancës qëndron në punën I/O-bound të trajtuar në mënyrë të njëkohshme.

Dija se si ta *mbajmë* të shpejtë është aftësia praktike kritike: shmangja e gabimit shkatërrues të vendosjes së thirrjeve bllokuese në `async def` (e cila serializon të gjitha kërkesën pas një event loop-u të ngrirë), përdorimi i bibliotekave async në endpoints async (ose `def` të thjeshtë për kod bllokues), largimi i punës CPU, cache-imi, optimizimi i bazës së të dhënave (shpesh bava e vërtetë), dhe ekzekutimi i punëtorëve të shumtë për disa kernela.

Kjo kombinim — përfitimi i async si duhet dhe matja për gjetjen e problemeve të vërteta — është ajo që ju lejon të realizoni potencialin e performancës të FastAPI, duke e bërë të rëndësishme njohuritë e nivelit të lartë për ndërtimin e API-ve vërtetë të shpejta dhe të shkallëzueshme në vend të atyre që duken async por përsëritin si kod bllokues.