Django wybierz do pełnych aplikacji z bazą danych, logowaniem i panelem administracyjnym, Flaska do małych projektów i nauki, a FastAPI do budowania API, zwłaszcza gdy potrzebujesz walidacji danych, automatycznej dokumentacji i streamingu odpowiedzi z modelu językowego. Przy samym czekaniu na zewnętrzny serwis wszystkie trzy mogą obsłużyć setki równoległych zapytań, ale tylko przy odpowiedniej konfiguracji serwera.
Wybór frameworka w Pythonie często wygląda jak wybór drużyny, a w praktyce to pytanie o to, co chcesz zbudować. Poniżej porównujemy trzy najpopularniejsze: Django, Flaska i FastAPI. Dołączamy własny pomiar, który nie potwierdził jednej z popularnych opinii.
Czym różnią się Django, Flask i FastAPI?
| Cecha | Django | Flask | FastAPI |
|---|---|---|---|
| Filozofia | „wszystko w zestawie” | minimalny rdzeń, resztę dobierasz | skupiony na API |
| Główne zastosowanie | pełne aplikacje webowe | małe aplikacje, proste API, nauka | API i usługi backendowe |
| Baza danych | wbudowany ORM i migracje | osobne biblioteki | osobne biblioteki |
| Panel administracyjny | wbudowany | brak | brak |
| Logowanie użytkowników | wbudowane | osobne rozszerzenia | do zbudowania samodzielnie |
| Walidacja danych | formularze i serializatory | ręcznie lub biblioteka | wbudowana (Pydantic) |
| Dokumentacja API | osobne rozszerzenie | osobne rozszerzenie | generowana automatycznie |
| Asynchroniczność | obsługiwana (serwer ASGI) | ograniczona | domyślna |
| Wejście dla początkującego | więcej do nauki na starcie | najmniej na starcie | niewiele na starcie, ale wymaga typów |
Dwa wnioski z tabeli. Po pierwsze, im więcej gotowych elementów, tym więcej do nauki na początku, ale mniej decyzji później. Po drugie, FastAPI i Flask zostawiają Ci wybór bazy danych, logowania czy migracji, co daje swobodę, ale wymaga większej wiedzy o tym, jak te elementy łączyć.
Który framework jest najszybszy przy wielu zapytaniach?
To pytanie pada najczęściej, a odpowiedź jest mniej oczywista, niż sugerują poradniki. Sprawdziliśmy ją prostym testem. Każdy framework dostał widok, który odpowiada po 2 sekundach (udaje oczekiwanie na zewnętrzny serwis, na przykład model językowy). Wysłaliśmy 20 i 200 zapytań naraz do jednego procesu serwera na laptopie:
| Konfiguracja | 20 zapytań | 200 zapytań |
|---|---|---|
FastAPI, async def z await (uvicorn) | 2,0 s | 2,8 s |
FastAPI, zwykłe def (uvicorn) | 2,1 s | 10,2 s |
Django, widok async (uvicorn, ASGI) | 2,0 s | 2,7 s |
| Django, zwykły widok (uvicorn, ASGI) | 2,0 s | 2,7 s |
| Django, zwykły widok (gunicorn, 40 wątków) | 2,1 s | 10,1 s |
| Flask, zwykły widok (gunicorn, 40 wątków) | 2,0 s | 10,1 s |
Flask, widok async (gunicorn, 40 wątków) | 2,0 s | 10,3 s |
| Flask lub Django, zwykły worker gunicorna | 40,1 s | nie dokończył się w minutę |
Jak to czytać:
- Serwer ma większe znaczenie niż framework. Django uruchomione na serwerze asynchronicznym (ASGI) osiągnęło praktycznie ten sam wynik co FastAPI: 200 zapytań w niecałe 3 sekundy. Zwykły widok Django też, bo przy ASGI każde zapytanie dostaje własny wątek.
- Wątki mają granicę. Konfiguracje z 40 wątkami obsłużyły 20 zapytań w 2 sekundy, ale 200 zapytań zajęło 10 sekund, bo kolejne „fale” po 40 czekały na wolny wątek.
- Zwykły worker to najgorszy przypadek. Jeden worker obsługuje jedno zapytanie na raz, więc 20 zapytań po 2 sekundy dało 40 sekund. Dlatego na serwerze nigdy nie zostawiamy domyślnych ustawień.
async defwe Flasku pod WSGI nic nie zmienia. Widok asynchroniczny nadal zajmuje wątek serwera, więc wynik jest taki sam jak dla zwykłego widoku.
Zastrzeżenia: test dotyczy jednego procesu, symulowanego czekania i naszych ustawień serwerów, które wybraliśmy sami. Nie jest to test „ustawień domyślnych” ani przepustowości przy prawdziwym obciążeniu CPU, a wyniki na innym komputerze będą inne. Proporcje powinny się jednak powtórzyć. Ten sam wynik uzyskaliśmy dla Django 4.2 i 6.1.
Czy FastAPI jest najlepszy do pracy z modelami językowymi?
To, co pokazał pomiar, nie wspiera hasła „tylko FastAPI obsłuży tysiące równoległych zapytań”. Jeśli Twoja aplikacja głównie czeka na model, Django na ASGI poradzi sobie podobnie. Mimo to FastAPI często jest wygodniejszym wyborem do takich projektów, z kilku innych powodów:
asyncjest tu domyślne. Nie wybierasz serwera ani trybu, piszeszasync defi działa. W Django musisz pamiętać o uruchomieniu na serwerze ASGI.- Streaming jest prosty.
StreamingResponsei generator asynchroniczny wystarczą do odsyłania odpowiedzi modelu token po tokenie. Jak to zrobić, opisaliśmy w artykule FastAPI i LLM. - Pydantic pasuje do ustrukturyzowanych danych. Odpowiedzi modeli często mają określony format, a modele Pydantic opisują go i walidują. Więcej w artykule o modelach wejścia i wyjścia.
- Wątków nie trzeba liczyć. Przy bardzo wielu połączeniach pętla zdarzeń jest lżejsza niż wątek na każde zapytanie. Tego akurat nie mierzyliśmy, więc traktuj to jako zasadę ogólną, a nie wynik.
Niezależnie od frameworka pojawi się inne ograniczenie: limity dostawcy modelu i koszt. Zanim zaczniesz optymalizować serwer, ustaw limit równoległych wywołań i timeout.
Który framework wybrać na start?
| Twoja sytuacja | Proponowany wybór |
|---|---|
| Chcesz zbudować aplikację z użytkownikami, bazą i panelem admina | Django |
| Uczysz się, jak działa serwer WWW, i chcesz widzieć wszystkie elementy | Flask |
| Budujesz API dla frontendu lub aplikacji mobilnej | FastAPI |
| Piszesz backend dla modelu językowego | FastAPI (lub Django na ASGI, jeśli już go znasz) |
| Szukasz pierwszej pracy jako programista Pythona | Django lub FastAPI, zależnie od ofert w Twoim mieście |
W naszym kursie Python online uczymy Django, bo daje kompletny obraz aplikacji: bazę danych, modele, formularze, API i wdrożenie. Znajomość Django ułatwia potem naukę pozostałych, ponieważ zasady (routing, widoki, walidacja, baza danych) są wspólne.
Czy trzeba znać wszystkie trzy?
Nie. Zasady, które poznajesz w jednym z nich, przenoszą się na pozostałe.
Uwaga mentora: nie ucz się trzech frameworków naraz. Wybierz jeden, zbuduj w nim kompletny projekt z bazą danych i testami, a dopiero potem sprawdź, co zmieniłoby się w pozostałych. Zasady (routing, widoki, walidacja, baza) są te same.
Jeśli chcesz wykorzystać projekt w portfolio, rozważ dodanie do niego funkcji z modelem językowym, jak w artykule o API OpenAI w Pythonie.
Podsumowanie
- Django to najlepszy wybór do kompletnych aplikacji i do nauki całości backendu.
- Flask sprawdza się w małych projektach i do zrozumienia podstaw.
- FastAPI jest wygodny do API, walidacji i streamingu, także dla modeli językowych.
- Wydajność przy czekaniu na zewnętrzny serwis zależy bardziej od serwera i konfiguracji niż od samego frameworka.
Jeśli chcesz uczyć się backendu z mentorem, który ocenia Twój kod, sprawdź kurs Python developer.
