Flask vs Django. Dlaczego NIE warto wybierać Flaska w 2021 roku?

Jestem byłym programistą Pythona z 10-letnim doświadczeniem w programowaniu, spędziłem 8 lat z Pythonem, oraz 6 lat kierowałem zespołami deweloperów. Na swoim koncie mam współtworzenie lub przejęcie ponad 10 dużych projektów internetowych liczących od 4 do 10 programistów. Obecnie jestem CEO firmy tworzącej oprogramowanie w języku Python. Wszystko, co przeczytasz poniżej, wynika z tego doświadczenia.

Jeśli chcesz wiedzieć, dlaczego nie jestem fanem Flaska (i Ty też nie powinieneś nim być) to zapraszam do lektury!

Przypomnijmy czym jest Flask, a czym Django

Dla porządku, Flask i Django to frameworki w języku Python. Mimo że są zupełnie inne, służą temu samemu celowi – budowaniu aplikacji internetowych, w których interfejs jest w większości oparty na protokołach HTTP, REST, GraphQL, grpc lub websockets.

Django to duży framework a Flask jest niewielki. Obydwa mają ogromne społeczności i doskonałą dokumentację, a od 2020 roku mają na oko 80% udziału w rynku aplikacji internetowych w środowisku Python.

Frameworki różnią się od siebie diametralnie, dlatego warto rozumieć jakie są najistotniejsze różnice pomiędzy nimi.

Jak porównać dwa frameworki? Metafora

Wyobraź sobie, że Twój projekt to wyprawa w nieznane. Musisz dotrzeć w określone miejsce w określonym terminie, ale do dyspozycji masz tylko kompas. Nie znasz topologii, więc do przejścia masz może 1 km, a może 100 km lub nawet 1000 km.

Aby wykonać to zadanie, możesz wybrać dowolny środek transportu: od własnych nóg po rakietę.

Jeśli na wyprawę wybierzesz Django…

Django jest jak ciężki SUV – nie najlepszy na 1 km (spacer mógłby być lepszy), ale spełnia swoje zadanie. Nie jest też najlepszy na 1000 km, ale mimo to, będzie nadal rozsądnym wyborem (samolot lub helikopter mógłby być lepszy). Na pewno nie możesz nim okrążyć ziemi, ale przynajmniej możesz dotrzeć do najbliższego brzegu, a wtedy możesz pomyśleć o kolejnych krokach, jak zakup samolotu albo łodzi.

Jest doskonały na większość wycieczek, choć dość ciężki na autostradach i dużo bardziej skomplikowany niż np. hulajnoga czy rower.

Jeśli na wyprawę wybierzesz Flaska…

To bądź gotowy się na podróż autostopem. Będzie pełna przygód, zabawna, można się wiele nauczyć i na pewno da Ci dużo wolności wyboru. Ale z pewnością jest nieprzewidywalna. Na początku wyprawy myślisz, że to będzie najlepszy moment w Twoim życiu, ale wraz z upływem czasu będzie tylko gorzej. Będziesz czekał godzinami na autostopa, uciekał przed zwierzętami lub marzł w środku nocy. Wszystkie problemy rozwiązane przy okazji posiadania SUVa.

Ok, tyle metafor – przejdźmy do rzeczy.

Do czego służy Flask?

Flask to dobry framework, jeśli chcesz dowiedzieć się, jak wszystko działa od środka, włączając samego Python. Musisz korzystać z wielu zewnętrznych bibliotek, samodzielnie je łączyć a często nawet wykodzić cześć samodzielnie.

Natomiast, jeśli myślisz o używaniu SQL, planujesz uruchomić kilka zadań w tle lub masz więcej programistów dochodzących do projektu, Flask z pewnością byłby złym pomysłem na dłuższą metę (więcej o tym później).

Według mnie Flask ma niewiele zastosowań, to co mi przychodzi do głowy to:

• Mały mikroserwis, gdy trzeba zaprojektować API dla modelu ML,
• Abstrakcja API do sterowania urządzeniami z innym protokołem, np. kamerą bezpieczeństwa,
• Proste API dla bazy danych bez SQL, takiej jak DynamoDB lub wyszukiwanie pełnotekstowe – takie jak ElasticSearch,
• Przygotowanie mikroserwisu adaptera, która tłumaczy interfejs API SOAP na łatwiejszy interfejs API JSON.

Do czego służy Django?

Django jest najlepsze do budowania czegoś co nazywamy majestic monolit, dzięki któremu możesz łatwo zbudować ogromną aplikację, nad którą może pracować jednocześnie 4-8 programistów. W pewnym momencie, gdy nasza aplikacja zaczyna żyć i mamy zweryfikowane pewne początkowe założenia. Możemy zacząć myśleć o rozbijaniu jej na mniejsze mikroserwisy, kawałek po kawałku.

To doskonały sposób na zaplanowanie przyszłego rozwoju całego systemu – zacznij od monolitu, a następnie rozbij go na mniejsze części, ale dopiero po lepszym zrozumieniu problemu, który rozwiązujemy. Nigdy na odwrót.

W przypadku niektórych mikroserwisów nadal możesz korzystać z Django lub możesz użyć bardziej elastycznych frameworków, jak Pyramid lub FastAPI.

Kompromisy frameworków

Kluczowym elementem przy wyborze technologii nie jest poznanie jej mocnych stron, ale świadomość kompromisów, na które będziesz zmuszony pójść.

Kompromisy Django

Myśląc o Django, powinieneś pomyśleć o nim jak o SQLowym frameworku webowym – jest najlepszy w przekładaniu świata rzeczywistego na SQLowe dane relacyjne (i odwrotnie). Zatem wybór Django zmusza Cię do trzymania się kurczowo SQLa.

Django ORM jest ORMem wysokiego poziomu. Poświęcasz elastyczność pisania niestandardowych, wyrafinowanych zagregowanych zapytań na rzecz doskonałego narzędzia, które mapuje obiekty na wiersze w tabeli.

W 95% przypadków użycia, tego właśnie chcesz. Ten jeden procent to zapytania analizujące czy agregujące dane (dla np. generowanie raportów), zapytania CTE, self-joiny i inne bardziej zaawansowane rzeczy.

Jednak chciałbym to jeszcze raz podkreślić, te przypadki są bardzo rzadkie, na przestrzeni wielu lat byłem zmuszony kilka razy ominąć ORMa i napisać SQLkę z palca. Ponadto, nawet jeśli użyłbyś low levelowego ORM, takiego jak SQLAlchemy, tego rodzaju zapytania najprawdopodobniej byłyby i tak bardzo wolne. Dlatego nadal musiałbyś zdenormalizować bazę danych i zagregować dane w osobnej tabeli.

Jeśli jesteś analitykiem danych lub masz duże doświadczenie w SQL, a korzystasz z Django ORM, to będziesz musiał zmienić swój sposób myślenia o pisaniu zapytań. To może być trudne i znam wiele osób, które nie były w stanie tego zrobić i znienawidziły Django ORM. To spowodowało, że osoby te wybrały inny framework + np. SQLAlchemy, co znacznie spowolniło rozwój ich projektów.

Kompromisy w ramach Flask

Przygotuj się na zdecydowanie więcej kompromisów. Co gorsza, nie są one odpowiednio sformułowane w społeczności Flask, w związku z czym wiele osób, które go wybrały boryka się później z jego architekturą w trakcie rozwoju projektu.

Co więcej, nie mogłem znaleźć żadnego krytycznego blog posta na temat Flaska ani w wątkach na ten temat na Reddicie, co powinno od razu być czerwoną flagą dla każdego, kto szuka odpowiedniego frameworka – nic nie jest idealne.

Ficzery Flaska są naprawdę prymitywne i szybko okazują się problematyczne, tylko gdy trzeba poradzić sobie z nieco trudniejszym use casem. Na przykład, weź implementację middleware w formie callbacków przed requestem i po – spróbuj określić dla nich kolejność wykonywania lub kontroluj kontekst przed i po żądaniu. Jest to niemożliwe lub wymaga hakowania przy użyciu obiektów globalnych.

Te callbacki wykonują się w odwrotnej kolejności niż zostały zadeklarowane. Więc wyobraź sobie, że robisz refaktor, przenosisz callbacki w nowe miejsce, przez przypadek zmieniasz ich kolejność i… bum. Wysadziłeś produkcję w powietrze.

Innym przykładem są oczywiście obiekty globalne (app, g lub request). Mógłbym napisać osobny artykuł o moich problemach z prostowaniem projektów we Flasku przez te obiekty. Z całą pewnością mogę powiedzieć, że nauczyłem się wszystkiego o tym frameworku. Mój mózg boli za każdym razem jak pomyślę o tych “ficzerach”.

Posiadanie obiektów globalnych jest tak niebezpieczne, że nigdy nie powinno być dozwolone. To tak, jakby dać 2-latkowi miecz świetlny, żeby pokroił marchewkę, napewno zrobi sobie krzywdę. Możesz pomyśleć – seniorzy sobie na pewno poradzą. Zaufaj mi, nie poradzą – i widziałem to zbyt wiele razy.

Mógłbym też napisać osobny artykuł o tym, dlaczego Flask ma zepsutą architekturę… a, czekaj – już to zrobiłem tutaj.

Porównanie Flask i Django

Django jest mainstreamowym frameworkiem – standardem. Wiele osób ma z tym problem i próbują użyć czegoś innego tylko dlatego, że Django jest super popularne.

Sam nie jestem bez winy, bo w 2012 roku wybierałem wszystkie inne frameworki tylko nie Django. Myślałem wtedy, że będzie mnie ograniczać. Przypadkowo wskoczyłem do istniejącego projektu w Django i otworzyło mi to oczy. Wszystko było w nim zorganizowane tak, jak powinno. Byłem o wiele bardziej produktywny i mogłem skupić się na rzeczywistych problemach klienta zamiast walczyć z frameworkiem lub pisać kod który ktoś już kiedyś napisał.

Nie bądź jak ja, zwłaszcza w 2021 roku, kiedy Django jest jeszcze lepsze.

Jeśli jesteś programistą Pythona i myślisz o tworzeniu aplikacji webowych, nieznajomość lub ignorowanie Django to strzał w stopę. Większość aplikacji można wykonać znacznie szybciej za pomocą Django.

Elastyczność

Który framework jest bardziej elastyczny, Flask czy Django? Wielu programistów odpowiada: Flask jest bardziej elastyczny niż Django i kropka. Ale czy naprawdę?

W 2012 roku różnica była naprawdę duża, wtedy we Flasku można było wybrać różne biblioteki dla sesji, formularze, templatki, niestandardowy model użytkownika itp. W 2020 roku wszystko zniknęło, większość z tych rzeczy została przeniesiona na frontend, który teraz piszemy w React/Vue/Angular. Ponadto Django jest teraz znacznie bardziej elastyczne, możesz dostosować model użytkownika, nie jesteśmy już zmuszeni do używania backendu do generowania frontendu.

Więc gdzie ta elastyczność Flaska? Prawdopodobnie tylko w konektorach bazy danych. W Django wybór bazy danych noSQL sprawia, że ​​80% frameworka jest bezużyteczne. Ale nadal masz 20% naprawdę dobrych rzeczy, których możesz użyć dokładnie tak samo, jak przy użyciu Flaska.

Oferty pracy z

Zastanawiasz się pewnie: “Czy powinienem używać Django tylko po to, aby użyć 20% jego kodu?” Myślę, że tak, a to dlatego, że 90% innych projektów i tak będziesz robić w Django, więc nie będziesz musiał uczyć się innego frameworka. Jeśli nadal chcesz poszerzyć swoje horyzonty, powinieneś rzucić okiem na Pyramid (czy FastAPI), który jest doskonałym frameworkiem i pomoże ci inaczej spojrzeć na to, jak mógłby wyglądać inny framework webowy.

Szybkość rozwoju

To jest łatwe do porównania. Mogę zademonstrować produktywność zespołu bez doświadczenia a priori w Django / Flask przy użyciu obu frameworków na poniższym wykresie:

Po pewnym czasie i wielkości projektu, produktywność zespołu Django przekroczy wydajność zespołu Flask. Wydajność zespołu Flask nawet spadnie. Dlaczego? Ponieważ pojawią się błędy związane z niewłaściwym użyciem wielu funkcji, takich jak obiekty globalne, biblioteki serializacji niskiej jakości, zawodne i powolne testy.

To jest moje doświadczenie, wszystkie projekty we Flasku, miały dokładnie ten pattern.

Wydajność

Wydajność czego? Jeśli tworzysz pełnoprawną aplikację webową, różnica w wydajności między wszystkimi frameworkami Pythona jest znikoma. W najgorszym przypadku będziesz musiał dodać kilka podów w klastra Kubernetesa.

Istnieją dwa przypadki, w których wydajność ma znaczenie:

1. Pierwsza to typ bazy danych. SQL jest wąskim gardłem w niektórych szczególnych przypadkach użycia. Jeśli masz wystarczające doświadczenie, aby znać kompromisy pomiędzy SQLowymi i noSQLowymi bazami danych i wiesz, że potrzebujesz bazy noSQLowej, wtedy Django jest bezużyteczne i warto poszukać innego frameworka (niezapomnij, że Flask nadal będzie Flaskiem).
2. Po drugie, gdy Twoja aplikacja będzie mocno asynchroniczna (jak aplikacja do czatu, bota itp.). Wtedy oczywiście ani Django, ani Flask nie są dobrym rozwiązaniem.

Bezpieczeństwo

Django jest tutaj niekwestionowanym zwycięzcą. Jako duży framework, kontroluje większość aspektów aplikacji webowej, co pozwala na egzekwowanie standardów bezpieczeństwa, nawet jeśli deweloperzy ich nie znają.

Inną rzeczą jest to, że dodatki do Django są o wiele potężniejsze niż dodatki do Flaska, a zatem mogą również lepiej kontrolować aspekty bezpieczeństwa. Weźmy na tapetę warstwę uwierzytelniania – na przykład istnieje dobrze znany dodatek Django Simple JWT: instalacja i konfiguracja zajmuje 5 minut, a do dyspozycji jest warstwa uwierzytelniania zgodna ze standardem branżowym.

Z drugiej strony Flask nie jest w stanie dać żadnych gwarancji bezpieczeństwa. Jesteś tam sam. Musisz nauczyć się wielu rzeczy samodzielnie. Czy coś zepsujesz podczas nauki? Na pewno.

Możesz myśleć, że jesteś wystarczająco sprytny (i prawdopodobnie tak jest), ale masz CEO nad sobą z wymaganiami i terminami oraz zespół, który zatrudniłeś w pośpiechu. Czy na pewno dadzą radę? Czy będziesz mieć czas, aby non stop patrzeć im na ręce?

Widziałem bardzo uzdolnionych CTO z wieloletnim doświadczeniem. Jednak przy projektowaniu od podstaw uwierzytelniania JWT opartego na SQL, mieli problemy z wydajnością. Zdarza się, szczególnie jak pracujesz pod presją czasu. Nie przeceniaj swoich umiejętności, bierz to co już jest gotowe i sprawdzone.

To który jest lepszy – Flask czy Django?

Istnieje ogromna różnica między tymi dwoma frameworkami. Django powinno być domyślnym wyborem dla 95% projektów. Flask należy używać ostrożnie przy małych projektach.

W Ulam Labs posługujemy się następującymi warunkami, aby wybrać ramy dla kolejnego projektu:

• Web API + SQL – Django, chyba że wykonujemy asynchroniczne lub bardzo złożone operacje SQL,
• 1-miesięczny projekt dla 1 osoby, w którym nie będzie używane SQL – Flask (jak developer bardzo chce), ale po upewnieniu, że projekt nie ma żadnych perspektyw na dalszy rozwój,
• baza danych noSQL – Pyramid lub FastAPI,
• duża praca asynchroniczna – FastAPI.

Jak widzisz, Flask nigdy nie jest naszym pierwszym wyborem. Dwa razy się zastanowimy (albo i trzy), zanim się na niego zdecydujemy. I Ty też powinieneś.

Autorem artykułu jest Konrad Rotkiewicz, CEO w Ulam Labs.

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