Flask czy Django – co wybrać? Devdebata

– Django jest kombajnem do typowych aplikacji. Flask za to wygra tam, gdzie chcemy mieć mały serwis lub jakąś konfigurację, którą ciężko osiągnąć w Django – to opinia jednego z zaproszonych do devdebaty ekspertów. Zaproszonym programistom zadaliśmy kilka pytań dotyczących tego, gdzie lepiej sprawdza się Flask, a gdzie Django. Z tego wydania devdebaty dowiecie się także, którego frameworka łatwiej się nauczyć.

Odpowiedzi na nasze pytania udzielili:

• Daniel Zuziak. Software Engineer w GrapeUp. Interesuje go tworzenie aplikacji w szeroko pojętym cloudzie. Profesjonalnie pełni rolę gdzieś pomiędzy programistą a “devopsem” – stawiając infrastrukturę i wrzucając kod na AWS. Silne zamiłowanie do dyskusji na temat rozwiązań technicznych wykazuje w roli konsultanta. Po pracy znajdziecie go przy stole snookerowym.
• Sebastian Buczyński. Expert Python Developer w STX Next. Programista “na sterydach”, ze smykałką do poszukiwania potencjalnych punktów zapalnych tak w oprogramowaniu, jak i całych procesach. Doświadczenie zbierał pracując parę ostatnich lat nad rozbudowaną platformą teleinformatyczną (ostatnio jako lider techniczny), a także zahaczając po drodze kilka startupów tak tajnych, że strach o nich mówić. Aktywnie bloguje pod adresem breadcrumbscollector.tech.
• Krzysztof Bujniewicz. Aktualnie engineering manager w Google, wcześniej m.in. country manager w Plecto, executive director w Goldman Sachs, senior software developer w Telmediq i team lead w Pulsie Biznesu. Zajmuje się głównie backendem – zarówno architekturą, jak i implementacją, najczęściej pracując w Pythonie. Wolny czas lubi spędzać z grami RPG – zarówno w roli gracza, jak i MG. Wszystkie wyrażone opinie są wyłącznie personalne i nie odzwierciedlają opinii pracodawcy.
• Wiktor Gonczaronek. Python Developer w Merixstudio. W swojej pracy (i pasji) szczególnie interesują go kwestie związane z bezpieczeństwem, które często wymagają zastosowania niekonwencjonalnych rozwiązań i kreatywnego kodowania. Aktywny członek programistycznej społeczności, który chętnie dzieli się wiedzą w ramach warsztatów, meetupów, for i grup internetowych oraz artykułów. W wolnym czasie lubi warzyć własne, craftowe piwo i “puścić dymka” na strzelnicy.

---

1. Dlaczego zaczynając przygodę z programowaniem, warto postawić na Pythona?

Daniel Zuziak, Software Engineer w Grape Up:

Jeśli mówimy o osobie nietechnicznej, to ze względu na estetykę. Osoba ucząca się Pythona jako pierwszego języka programowania odniesie wrażenie, że jest ono proste. Początkującemu programiście najbardziej potrzeba zachęty i motywacji. Prosta składnia, typowanie dynamiczne i interpretowalność sprawiają, że tworzenie pierwszych aplikacji lub ich prototypów daje większą satysfakcję niż przebijanie się przez błędy kompilatora i znaczki z górnej części klawiatury – jak to się ma w przypadku niektórych języków kompilowanych.

Nie ma konieczności używania narzędzi do budowania aplikacji, skrypt można po prostu uruchomić. Python posiada dużo wbudowanych funkcji, przydatnych w typowych zadaniach programistycznych dla początkujących.

Sebastian Buczyński, Expert Python Developer w STX Next:

Python jest niezłym kandydatem na pierwszy język ze względu na jego prostotę i wysokopoziomowe API. Adept programowania może poćwiczyć używanie podstawowych struktur kontrolnych (if-y, pętle) i struktur danych (lista, słownik) bez martwienia się o zwalnianie pamięci. Relatywnie szybko można zrobić coś, co działa i zobaczyć z czym w ogóle się je programowanie. Na przykład na tym koncentruje się tutorial Django Girls – w ciągu jednego dnia ma za zadanie pokazać nawet nietechnicznym osobom jak wygląda web development z Django.

Łatwy próg wejścia nie oznacza jednak, że opanowanie Pythona jest trywialne. Cytując Łukasza Langę, jest to język, który rośnie razem z programistą. Przez lata można odkrywać w nim nowe rzeczy.

Nawet jeżeli potem w karierze nasze drogi rozejdą się z Pythonem i nie będziemy z niego korzystać jako podstawowego języka, nadal możemy wykorzystać go do skryptowania i automatyzacji sobie nudnych zadań.

Krzysztof Bujniewicz, Engineering Manager:

Python dzięki swojej prostocie jest świetnymi drzwiami do świata programowania. Niezależnie od tego, czy chcemy przy nim pozostać dłużej, czy szybko przenieść się na inną technologię – z perspektywy tworzenia oprogramowania, Python w prosty sposób oddaje istotne koncepty, bez typowej dla języków niższego poziomu walki z na tym etapie mało zrozumiałymi oraz często nieistotnymi (podkreślam, że tylko na tym etapie) tworami oraz języków statycznie typowanych ilości boilerplate, które trzeba napisać lub wygenerować. Dodatkowym plusem jest bogactwo kursów, materiałów do nauki i bibliotek w różnych obszarach – chociażby skrypty, aplikacje webowe, analiza danych czy micropython i aplikacje wbudowane.

Wiktor Gonczaronek, Python Developer, Merixstudio:

Bo jest prosty a jednocześnie istnieje na niego zapotrzebowanie na rynku. Z jednej strony mamy więc stosunkowo niski próg wejścia, z drugiej zaś dojrzały projekt, który ma zastosowanie przy tworzeniu aplikacji internetowych, czy szeroko rozumianej sztucznej inteligencji i obliczeń naukowych.

2. Co najbardziej doceniasz we Flasku, a co w Django?

Daniel Zuziak, Software Engineer w Grape Up:

Wyznaję zasadę: małe jest piękne. Kod aplikacji powinien być “ogarnialny” przez jednego programistę; struktura projektu powinna mieścić się w głowie. W takich projektach nie ma sensu używać Django. Istnieją jednak aplikacje biznesowe, które mają łączyć w sobie wiele mocno zależnych od siebie części, w przypadku których dzielenie na mikroserwisy nie jest oczywiste i może przynieść nam więcej szkody niż pożytku.

Jeśli mamy do czynienia z takiego rodzaju projektem (większość czasu spędzona na spotkaniach i wielki schemat UML na Confluence), skierujmy się w stronę Django. Unikniemy problemów z różnicą w podejściach do implementacji funkcjonalności, ponieważ wiele z nich dostaniemy out-of-the-box.

Sebastian Buczyński, Expert Python Developer w STX Next:

Najbardziej w Django doceniam spójność, kompletność frameworka oraz niski próg wejścia. Do tego dodać trzeba wyśmienitą dokumentację. We Flasku za to najbardziej doceniam, że jako framework nigdy nie staje na drodze w implementacji funkcjonalności dzięki dużo większej elastyczności.

Krzysztof Bujniewicz, Engineering Manager:

Flask jest świetny, by pokazać różnice pomiędzy mikro-, a pełnym frameworkiem. Jest bardzo wygodny do stworzenia bezstanowej aplikacji serwującej parę widoków, chociaż w dzisiejszych czasach w tej sytuacji pewnie lepiej spojrzeć na Starlette. Gdy z jakichś względów potrzebuję do obsługi bazy danych użyć SQLAlchemy, Flask również będzie dobrym wyborem.

Każda inna sytuacja, gdy wydajność nie jest kluczowa, w moim wypadku zaowocuje wyborem Django – ze względu na szybkość developmentu, dostępność bibliotek i praktyczne zastosowanie DRY. Skoro i tak buduję coś w 80% zgodnego z Django, jest ono bliższym punktem startowym, niż Flask.

A co z sytuacjami, gdzie wysoka wydajność jest krytyczna? Pozostając w Pythonie, Starlette + uvicorn, a wcześniej gevent @ PyPy działają całkiem nieźle. Ale można też pokusić się o wykorzystanie innego języka, np. C++, go lub Rust.

Wiktor Gonczaronek, Python Developer, Merixstudio:

Flask podoba mi się wszędzie tam, gdzie muszę na szybko “sklecić” jakiś serwer, żeby pokazać jak coś działa, kiedy wymagania biznesowe są niewielkie albo w ogóle ich nie ma. Sporo przykładów do swoich artykułów, w których zależało mi na prostym pokazaniu tego, co się dzieje z zapytaniem oparłem właśnie o Flaska.

Django natomiast wygrywa tam, gdzie muszę dostarczyć duży projekt. Doceniam to, że mam dostęp do wielu gotowych bibliotek, które są aktywnie rozwijane i że nie muszę wymyślać koła na nowo. Dodatkowo jako osoba lubiąca zagadnienia związane z bezpieczeństwem doceniam to, że Django jest nudne w tym obszarze. Domyślnie dostajemy zabezpieczenie przed popularnymi atakami, dokumentacja w wielu miejscach zwraca bardzo wyraźnie uwagę na to, czego nie robić.

3. Czego łatwiej się nauczyć: Flaska czy Django?

Daniel Zuziak, Software Engineer w Grape Up:

Zależy co rozumiemy przez określenie “nauczyć się” i jakiego efektu oczekujemy. Jeśli w krótkim czasie chcemy utworzyć pełną “production ready” aplikację, sięgnijmy po Django, które w magiczny sposób zajmie się nieciekawymi dla programisty zadaniami (security, konfiguracja). Jest ryzyko, że znajdziemy się w sytuacji, gdzie potrafimy postawić gotową aplikację, jednak nie wiemy jak działają mechanizmy w niektórych jej komponentach. W tym momencie warto sięgnąć po Flaska, który nie wyręcza nas we wszystkim. Stopniowe dokonfigurowywanie podstawowych funkcjonalności, pozwoli nam zrozumieć co tak naprawdę po kolei dzieje się w kodzie, under-the-hood.

Sebastian Buczyński, Expert Python Developer w STX Next:

Odpowiadając wprost na pytanie – Flaska. Z tej prostej przyczyny, że najzwyczajniej w świecie jest mniejszy niż Django. Nie oznacza to jednak, że praca z Flaskiem wymaga mniejszych umiejętności niż z Django. Powiedziałbym, że jest całkiem odwrotnie – efektywna praca z Flaskiem od początku wymaga większej wiedzy programistycznej i większej dyscypliny niż z Django, które bardziej prowadzi nas za rękę i wymusza niejako pewien styl.

Ta cecha bywa jednak zgubna w pewnych okolicznościach. Najpopularniejsze “ściany”, z którymi można się zderzyć pracując z Django to brak przewidzianego miejsca na logikę biznesową czy ograniczenia wbudowanego panelu admina (gdy próbujemy go zbytnio naginać do naszych potrzeb). W takiej sytuacji potrzebujemy już magików, którzy znają ten framework na wylot i wiedzą np. o metodzie, którą należy nadpisać żeby uzyskać pożądane zachowanie.

Pod tym względem Django jest taki sam Python – łatwo zacząć, ale poznanie wszystkich tajników trwa lata. Z drugiej strony Flask pozwala zrobić wszystko, więc developer na poziomie regular szybciej będzie w stanie rozwiązać problem w elastycznym Flasku niż szukając sposobu na zrobienie czegoś zgodnie z filozofią Django.

Krzysztof Bujniewicz, Engineering Manager:

Moim zdaniem, zaczynając przygodę z programowaniem webowym, zdecydowanie łatwiej zacząć od Django. Podobnie jak sam Python, Django dla wielu zastosowań po prostu działa – i daje nam olbrzymią ilość wbudowanych funkcjonalności. Typowa dla wielu moich znajomych droga wyglądała tak, że zaczęli od Django, po pewnym czasie natknęli się na ograniczenia frameworka, po pewnym okresie walki zdecydowali się na użycie Flaska z wtyczkami – i po jednej lub dwóch aplikacjach stworzonych w ten sposób wracali do Django.

Nie znaczy to, że Flask jest zły, bo dzięki niemu można nauczyć się wiele o tym, co tak naprawdę musi się zadziać w Pythonowym kodzie, aby to wszystko, co dostajemy w Django, działało – chociażby autentykacja i autoryzacja, połączenie z bazą danych, sesje czy cache. Ale tworząc większe aplikacje we Flasku, często pozostaje wrażenie, że tworzy się drugie Django, tylko nieco mniej spójne. W tej sytuacji często więcej sensu może mieć wyłączanie/zamiana niepotrzebnych czy niepasujących elementów Django, niż instalowanie i konfigurowanie kilkudziesięciu wtyczek do Flaska.

Wiktor Gonczaronek, Python Developer, Merixstudio:

Wydawać by się mogło, że microframework jakim jest Flask powinien być oczywistym wyborem dla osób rozpoczynających swoją przygodę z aplikacjami webowymi: brak narzutu wszystkich narzędzi, jakie Django ma wbudowane pozwala szybciej zacząć rozwijać projekty. Dodatkowo konieczność napisania każdego kroku przetwarzania danych samemu pozwala lepiej zrozumieć co się dzieje.

Z drugiej strony w Django również możemy zdecydować się na rozwiązanie, w którym sami obsłużymy całość zapytań bez zrzucania odpowiedzialności na niewidoczne dla nas fragmenty kodu. Dodatkowo jeśli przez “nauczyć się” rozumiemy nabycie zdolności do wypuszczenia stabilnego, przejrzystego i bezpiecznego projektu, to Django będzie zdecydowanym faworytem ze względu na to, że bardziej wymusza na programiście zastosowanie pewnych narzędzi i dostarcza pewne gotowe rozwiązania. No i ostatnia rzecz, jaka przemawia na korzyść Django to szersze wsparcie społeczności, która dostarcza bardzo dobrej dokumentacji.

4. Kiedy wybrać Flaska, a kiedy Django?

Daniel Zuziak, Software Engineer w Grape Up:

Django sprawdzi się wszędzie tam, gdzie trzeba rozwiązać problem już przez kogoś rozwiązany. Chodzi mi o klasyczne aplikacje typu sklep internetowy czy magazyn. Django może jednak nie być najlepszym wyborem w przypadku aplikacji bardzo customowych. W dobie technologii cloudowych, gdzie zmiana technologii jest na porządku dziennym, promowane jest tworzenie jak najmniejszych serwisów i komponentów, aby te można było w krótkim czasie wymienić. Mnogość takich komponentów sprawia, że istnieje także duże zapotrzebowanie na aplikacje, które je integrują. Python sprawdza się znakomicie w roli narzędzia do CI / CD czy orchestracji, a Flask jako microframework do mikroserwisów.

Sebastian Buczyński, Expert Python Developer w STX Next:

Dla mnie kluczowymi czynnikami, jeśli chodzi o wybór frameworka jest po pierwsze skomplikowanie projektu, a po drugie kompozycja zespołu. Mniej doświadczony zespół z kilkoma juniorami w składzie mocno doceni Django, które wymusza spójniejszy styl i nie wymaga spędzania dużej ilości czasu na projektowanie rozwiązań. Tak samo sprawa ma się ze skomplikowaniem projektu – jeżeli jest to aplikacja na poziomie relatywnie prostej przeglądarki do bazy danych (typowy CRUD), to Django ze swoją filozofią i admin panelem będzie w sam raz.

W przypadku bardziej doświadczonego zespołu i skomplikowanego projektu z Django jest jak w za małych butach. Wymiatacze potrafią rozwiązywać problemy bardziej efektywnie niż pozwala im na to framework. Przykładem niech będzie ORM Django. Dostarcza on własną abstrakcję nad SQLa, nie zapewniając jednak pełni funkcjonalności. Za to mając do dyspozycji SQLAlchemy nie jest się ograniczonym i można wycisnąć wszystko co się da ze swojej bazy danych.

Jeżeli zaś mówimy o projektach skomplikowanych, to w ogóle nie powinniśmy myśleć w kategoriach frameworka, tylko skupić się na większym obrazku. Web to tylko jeden punkt wejścia do aplikacji, a powinniśmy większą uwagę przywiązywać do wymagań biznesowych. Takie podejście na przykład przedstawiam w swoim artykule na justjoin.it/blog – Czysta Architektura w Pythonie. Jak stworzyć czysty i elastyczny kod czy swojej książce Implementing the Clean Architecture.

Na koniec pozostaje jeszcze kwestia mikroserwisów. Nie sądzę by jeden z tych frameworków miał tutaj szczególną przewagę nad drugim – wszystko zależy od tego, co to za mikroserwis. Pamiętajmy, że mikro nie oznacza wcale mały. Liczy się autonomia.

Krzysztof Bujniewicz, Engineering Manager:

Tutaj właściwie mógłbym powtórzyć moją odpowiedź na pytanie, co doceniam w którym Frameworku. Jeśli krytyczna jest wydajność, Starlette. Jeśli potrzebuję SQLAlchemy, albo aplikacja jest bezstanowa i mała – do paru widoków, Flask. W każdej innej sytuacji, Django.

Wiktor Gonczaronek, Python Developer, Merixstudio:

Django jest kombajnem do typowych aplikacji. Kiedy chcemy szybko dostarczyć działający projekt, zintegrować go z zewnętrznymi usługami, dostać domyślną bezpieczną konfigurację, jest to optymalny wybór.

Flask wygra tam, gdzie chcemy mieć mały serwis lub jakąś konfigurację, którą ciężko jest osiągnąć w Django – np. trzymanie danych w nierelacyjnej bazie danych.

5. Jaki projekt ostatnio zdarzyło Ci się realizować przy pomocy Flaska, a jaki przy użyciu Django?

Daniel Zuziak, Software Engineer w Grape Up:

Aktualnie pracujemy nad kilkoma REST API, które mają zastąpić poprzednie, mniej nowoczesne monolityczne systemy (branża bankowości, kredytów). Aplikacje te są napisane we Flasku. Bardziej interesująca jest cała infrastruktura na AWS-ie, która integruje nowy system ze starymi (kolejki oraz kochane przez Pythonistów Lambdy). Jeśli chodzi o Django, to jego najbliższym zamiennikiem, używanym przeze mnie komercyjnie był Spring. Pisaliśmy w nim komponent dla dużej firmy ubezpieczeniowej, umożliwiający dokonywanie płatności w kilku formach.

Sebastian Buczyński, Expert Python Developer w STX Next:

W Django pracuję nad aplikacją concierge w architekturze multi-tenancy. W uproszczeniu powiedzmy, że jest to pewna forma e-commerce, gdzie mamy wiele konfigurowalnych wersji tej samej aplikacji per klient. Niestety wybór frameworka nie przeżył całkowicie próby czasu i kierunku rozwoju. W odległej przyszłości Django pozostanie jako admin panel + api, które wystawia wyklikane ustawienia dla poszczególnych wersji serwisu.

Za to w poprzednim projekcie mieliśmy dwa, nazwijmy to, mikroserwisy napisane w Django – panel admina, prosta integracja z usługą 3rd party oraz główną aplikacją w innym frameworku.

We Flasku dawniej pisałem niewielkie narzędzia do automatyzacji sobie pracy z webowym interfejsem i kilka mikroserwisów, także takich uruchamianych przez AWS Lambda, czyli w modelu serverless. Za to ostatni duży i bardziej skomplikowany projekt pisaliśmy w Pyramidzie, który ma elastyczność Flaska, jednak posiada też sporo gotowych komponentów i mniej czasu spędza się na dokładaniu paczek do projektu.

Krzysztof Bujniewicz, Engineering Manager:

W praktyce we Flasku ostatni raz działałem w 2016 roku, a w Starlette – w 2019. We Flasku był to projekt komercyjny operujący na istniejącej bazie danych, wystawiający bardzo proste API. W Starlette – mikroserwis pośredniczących w rozproszonych transakcjach, w którym wydajność miała duże znaczenie, ale nie chciałem do istniejącego stosu dodawać nowego języka.

W Django działałem na co dzień (z drobnymi wyjątkami) aż do rozpoczęcia mojej obecnej pracy. Ostatnia aplikacja, nad którą pracowałem, to system do rezerwacji miejsc na wydarzeniach.

Wiktor Gonczaronek, Python Developer, Merixstudio:

Django służy mi na co dzień. Aktualnie tworzę za jego pomocą system do pośredniczenia w sprzedaży ubezpieczeń. We Flasku zaś ostatnim komercyjnym projektem był proof of concept do projektu, który de facto miał być takim inteligentnym cachem z nietypową konfiguracją, o jakiej pisałem wcześniej – nierelacyjną bazą danych, bez konieczności pisania uwierzytelniania i innymi rzeczami, które zazwyczaj nie znajdują się w projektach.

6. Jakie polecasz alternatywy dla Flaska i Django?

Daniel Zuziak, Software Engineer w Grape Up:

Wartym uwagi stackiem jest Java + Spring. Jest to bardziej Javowy odpowiednik Django, niż Flaska, choć równie dobrze nadaje się do pisania mikroserwisów. Spring wprowadził standard tworzenia Javowych aplikacji webowych, czytaj: jeden sugerowany sposób konfigurowania aplikacji, zaczynając od warstwy webowej (REST, walidacja, Swagger), przechodząc przez warstwę biznesową (architektura heksagonalna i Domain Driven Design), a kończąc na bazie danych: Hibernate, JPA (SQL/MongoDB).

Ekosystem frameworka Spring jest bardzo spójny, a zarazem dość elastyczny, co pozwala na szybkie skonfigurowanie dodatkowych modułów. W przypadku dużych aplikacji przydaje się też typowanie statyczne Javy, czy mechanizm Dependency Injection Springa (ostrożnie :)).

Sebastian Buczyński, Expert Python Developer w STX Next:

Zakładając, że poruszamy się w świecie Pythona to rzucę jedną nazwą – FastAPI. Zestawiając Django z Flaskiem bardzo brakuje czegoś asynchronicznego. Ostatnio przeżywamy w Pythonie istną eksplozję nowych microframeworków, które natywnie wspierają asyncio i FastAPI jest spośród nich jedną z najciekawszych propozycji dzięki swojej integracji z Swaggerem.

Gdybyśmy mieli szukać szerzej, to warto jeszcze rzucić okiem na Spring Boota (JVM – np. Kotlin) lub Phoenix – Elixir.

Krzysztof Bujniewicz, Engineering Manager:

Starlette pozwala pozostać w Pythonie i wykorzystać możliwości asyncio. Ale jeśli jesteśmy otwarci na inne języki, to do małych aplikacji warto spróbować Go (full disclosure: pracuję w Google). Jeśli ostra krzywa nauki nas nie odstrasza, to warto zainteresować się C++ oraz Rustem. Albo w całkowicie inną stronę – Play framework w Javie oraz ASP.NET Core również mają swoje plusy oraz swoich zwolenników. Warto spróbować i przekonać się, co po statycznie typowanej stronie świata w trawie piszczy.

Wiktor Gonczaronek, Python Developer, Merixstudio:

Aby odpowiedzieć na to pytanie należałoby zastanowić się, w jakim obszarze Flask i Django nie spełniają naszych oczekiwań. Jeśli jest to np. wydajność, to warto pomyśleć o AIOHTTP, czy rozwiązaniach pisanych w Golangu albo innych językach kompilowanych (chociaż sposobów optymalizacji jest sporo i nawet serwis obsługujący dziesiątki zapytań na sekundę, jeśli jest dobrze zaprojektowany, powinien być możliwy do napisania w tych frameworkach). Jeśli jest to konieczność pisania w jakimś konkretnym języku podyktowana preferencjami zespołu, to należy poszukać rozwiązania w tym właśnie języku. Tak było w przypadku Ruby on Rails, który był inspiracją dla Django, i który na pewno dostarczy dobre jakościowo, stabilne środowisko do tworzenia projektów.

---

Zdjęcie główne artykułu pochodzi z unsplash.com.

Oferty pracy z