Backend

REST API w Pythonie: Flask czy FastAPI?

Tworzenie aplikacji internetowych, a w tym REST API, to chleb powszedni backend developerów. Dlatego praca z frameworkiem webowym powinna być szybka i prosta. Microframeworki to bardzo dobry start dla małych projektów, MVP czy nawet dużych aplikacji, które potrzebują REST API – a do nich zaliczają się m.in.: Flask i FastAPI.

Flask jest jedną z najpopularniejszych bibliotek do tworzenia aplikacji internetowych w Pythonie. Osoby zaczynające swoją przygodę z programowaniem bez trudu znajdą na jego temat mnóstwo tutoriali i rozwiązań typowych problemów. Jest on lekki (“microframework”) i bardzo dobrze udokumentowany. Posiada wiele rozszerzeń i sporą społeczność.

FastAPI robi się coraz bardziej popularny z dnia na dzień. Jego nacisk na szybkość (FastAPI), nie tylko w kwestii ilości obsługiwanych zapytań na sekundę, ale również na szybkość developmentu oraz wbudowaną walidację danych – tworzy z niego idealnego kandydata na backendową stronę naszej aplikacji internetowej.

Napisałem aplikację do tworzenia, aktualizowania, pobierania oraz usuwania wiadomości prasowych w dwóch wyżej wymienionych frameworkach i bardzo chętnie przedstawię Wam ich porównanie.

Pierwszą znaczącą różnicą, którą możemy znaleźć przyglądając się tym dwóm bibliotekom to:

Walidacja danych

Instalując Flaska nie dostajemy żadnego narzędzia do walidacji danych. Możemy jednak poradzić sobie przy użyciu dodatków, które oferuje społeczność, np. Flask-Marshmallow czy Flask-Inputs. Minusem tego rozwiązania jest fakt, że musimy polegać na bibliotekach rozwijanych oddzielnie niż nasz główny framework i nie mamy stuprocentowej pewności, że będą one kompatybilne.

FastAPI natomiast daje nam do użytku bibliotekę Pydantic, dzięki której walidacja danych jest o wiele prostsza i szybsza niż pisanie tego z palca. Jest ona ściśle związana z samym FastAPI, więc możemy być pewni, że Pydantic będzie cały czas kompatybilny z naszym frameworkiem.

Jak wyglądają walidacje w poszczególnych bibliotekach na podstawie naszego prostego API?

Tworzymy klasy o nazwach NewsSchema / CreatorSchema, które będą klasami bazowymi do walidacji naszych wiadomości oraz autorów.

Możemy zauważyć, że NewsSchema/ CreatorSchema pochodzące z FastAPI używają BaseModel jako klasy nadrzędnej – jest to wymagane, gdyż BaseModel pochodzi z biblioteki Pydantic i posiada niezbędne funkcje do walidacji danych.

Natomiast we Flasku dziedziczymy po klasie BaseSchema, która jest zwykłą dataklasą i zawiera parę metod, z których klasy dziedziczące będą korzystać lub ją nadpisywać. W naszym przypadku sprawdzimy jedynie czy tekst, który wprowadzamy, mieści się w limicie znaków.

Sama walidacja będzie zachodzić w klasach NewsSchemaInput/ CreatorSchemaInput:

Gdy stworzymy nasz obiekt NewsSchemaInput/ CreatorSchemaInput, uruchomiona zostanie metoda __post_init__, w której po kolei wywołujemy walidację danych (sprawdzanie długości tekstu) i jeżeli jest ona niepoprawna – dodajemy błędy do zmiennej _errors, a na końcu rzucamy wyjątkiem Validation Error.

W przypadku struktur, które są zagnieżdżone ( CreatorSchemaInput), musimy manualnie tworzyć te obiekty – robimy to po skończonej walidacji NewsSchemaInput w metodzie __post_init__.

Samo sprawdzanie danych nie stanowi większego problemu – dopiero dodawanie nowych pól będzie uciążliwe, ponieważ za każdym razem musimy dodać osobną metodę _validate oraz w przypadku zagnieżdżonej struktury – tworzenie instancji tego obiektu i łapanie wyjątku.

Możemy zauważyć, że klasy, które mają za zadanie walidować przychodzące dane, stają się dosyć rozbudowane – i to tylko dla paru kluczy. Musieliśmy również dodać własną implementację dodawania błędów, dzięki czemu możemy dodawać zagnieżdżone informacje o błędach w odpowiedziach z API.

W FastAPI jest to o wiele prostsze i przyjemniejsze:

Poprzez zaimportowanie Field z Pydantic mamy dostęp do prostych deklaracji zasad, które muszą zostać spełnione, aby wprowadzane przez użytkownika dane były prawidłowe.

Również typy danych są walidowane na podstawie typów zmiennych, więc jeżeli nasza zmienna first_name posiada typ str, to musimy w danych wejściowych przekazać tekst (i analogicznie dla wszystkich wbudowanych typów danych).

Bez dodatkowego kodu Pydantic świetnie radzi sobie ze sprawdzaniem zagnieżdżonych struktur (w tym przypadku CreatorSchemaInput). I to wszystko w paru linijkach kodu!

Oprócz max_length i min_length możemy zauważyć też dwa dodatkowe parametry: title oraz example – są one opcjonalne, ale będą widoczne w automatycznej dokumentacji, którą generuje za nas FastAPI.

praca w it

Serializacja danych wychodzących

Skoro wiemy już, jak walidujemy dane, to powinniśmy zastanowić się, jak chcemy je zwracać. Wiadomość będzie posiadała nie tylko treść, tytuł czy autora, ale również swój unikalny numer (id) oraz datę utworzenia i aktualizacji. Musimy stworzyć nową klasę, która będzie odpowiadała za serializację modelu domenowego News i będzie to NewsSchemaOutput.

Klasa NewsSchemaOutput w obydwu przypadkach jest praktycznie taka sama, różni się tylko klasą nadrzędną oraz metodą serializacji do słownika (razem ze zmianą obiektu datetime na timestamp).

W FastAPI przy użyciu Pydantic mamy możliwość dodania klasy Config, w której umieściliśmy zmienną json_encoders. Pomaga ona serializować dane w sposób, którego wymagamy. W tym przypadku obiekt daty chcemy przekazać jako timestamp. We Flasku natomiast musieliśmy zmieniać dane w stworzonym już słowniku na takie, które chcemy zwrócić.

Widoki aka endpoints

Tworzenie widoków w obu bibliotekach jest bardzo do siebie podobne i wykorzystuje prosty dekorator na funkcji, której chcemy użyć. Różnią się natomiast sposoby definiowania walidacji danych oraz ich serializacji.

Tworzenie wiadomości, czyli walidacja i serializacja danych

Na samym początku mamy dekorator, który ustala ścieżkę dostępu oraz metodę HTTP, która będzie obsługiwana. Flask ustala to za pomocą parametru methods, gdzie musimy przekazać listę obsługiwanych metod, natomiast FastAPI używa atrybutu post na news_router.

Dekorator, którego używa FastAPI, nie służy jedynie do ustalania ścieżki i metod HTTP, ale również do serializacji danych ( response_model), opisania widoku w automatycznej dokumentacji ( summary), zdefiniowania statusu odpowiedzi ( status_code) oraz wielu innych, nie znajdujących się w tym przykładzie. Można powiedzieć, że nie definiuje on jedynie ścieżki dostępu i metody, ale opisuje cały widok w głębi.

No dobrze, ale co się w tym widoku tak naprawdę dzieje?

Zacznijmy od Flaska!

Pierwszą rzeczą, którą robimy, jest pobranie repozytorium bazy danych do naszej funkcji za pomocą:

db_repo = get_database_repo()

W następnym kroku walidujemy przesłane dane przez użytkownika, które znajdują się w obiekcie request:

news_schema = NewsSchemaInput(**request.get_json())

Ta linijka rzuci wyjątkiem ValidationError, jeżeli wprowadzone dane są nieprawidłowe.

Wyjątek zostanie wyłapany (w stworzonym przez nas errorhandler) i Flask zwróci odpowiedź ze wszystkimi błędami, które znajdują się w zmiennej _errors na NewsSchemaInput.

W stworzonym przez nas errorhandler – ale zaraz, zaraz, nie było o tym mowy! We Flasku i FastAPI możemy dodać własne obsługiwanie wyjątków, które zostaną rzucone w implementacji widoków. Wyglądają one tak:

Jeżeli walidacja przebiegła poprawnie, tworzymy obiekt NewsDTO, który przekaże niezbędne informacje do repozytorium bazy danych. Repozytorium wykona swoją magię (zapisze wiadomość do bazy danych) i zwróci nam obiekt domenowy News, który następnie serializujemy za pomocą klasy NewsSchemaOutput:

Na samym końcu zwracamy NewsSchemaOutput jako słownik oraz status odpowiedzi.

return output_schema, HTTPStatus.CREATED

Teraz rzućmy okiem na FastAPI.

Tym razem w widoku dostajemy dwa parametry: news_input oraz db_repo.
Zacznijmy od tego pierwszego:

Walidacja danych wejściowych dzieje się jeszcze przed uruchomieniem metody naszego widoku, a to dzięki parametrowi news_input.

Zapytacie: ale skąd FastAPI wie, której klasy użyć? Dzięki typowaniu. Parametr news_input posiada typ NewsSchemaInput, więc FastAPI przekazuje tej klasie wszystkie dane, które wysłaliśmy metodą POST. Nie musimy specjalnie tworzyć instancji obiektu NewsSchemaInput, ponieważ w parametrze news_input dostaniemy zwalidowane dane.

Odnośnie db_repo – działa on podobnie jak we Flasku – z tą różnicą, że tutaj używamy wstrzykiwania zależności. Słowo kluczowe Depends pozwala na podstawianie klas lub funkcji podczas działania naszej aplikacji. Odnośnie dependency injection troszkę później.

Gdy nasza metoda zostanie wywołana, zapisujemy wiadomość do bazy danych.

db_news = await db_repo.save_news(news_dto=news_dto)

We Flasku musieliśmy specjalnie tworzyć instancję klasy NewsSchemaOutput, żeby zwrócić poprawne dane. Tak samo ze statusem odpowiedzi, jest on również odesłany za pomocą słowa kluczowego return.

FastAPI pozwala na sprecyzowanie klasy do serializacji danych za pomocą parametru response_model w dekoratorze. Wystarczy, że podamy prawidłową strukturę, którą zrozumie Pydatnic. Status odpowiedzi również możemy ustawić w tym samym miejscu co response_model, ale za pomocą parametru status_code.

Pobieranie wiadomości, zmienne w adresie i parametry GET

Tak samo jak w przypadku tworzenia wiadomości, definiujemy widok za pomocą prostego dekoratora, lecz tym razem z metodą GET.

Aby pobrać interesującą nas wiadomość, musimy naszemu widokowi przekazać jego id. Robimy to za pomocą adresu, w którym dodajemy parametr news_id. We Flasku musimy szczegółowo podać jego typ za pomocą “ostrych” nawiasów oraz nazwę, czyli <int:news_id>. Jesteśmy zmuszeni do używania tylko podstawowych typów, które Flask zrozumie np. int, uuid, str lub float i tak dalej.

FastAPI używa używa konwencji podobnej co f-string, gdzie nazwę naszej zmiennej definiujemy poprzez nawiasy klamrowe, a jej typ ustalamy w parametrach funkcji widoku. Jest to rozwiązanie bardziej elastyczne, gdyż możemy spróbować przekazywać skomplikowane struktury w adresie. Mogliście również zauważyć nowy parametr, który pojawił się w dekoratorze widoku o nazwie responses – wrócimy do niego podczas omawiania automatycznej dokumentacji.

FIltrowanie wiadomości za pomocą parametrów GET

Gdy chcemy stworzyć widok, który nie potrzebuje zdefiniowanych zmiennych w adresie, a bardziej elastyczne rozwiązanie – używamy parametrów GET. W tym przypadku potrzebujemy zwrócić wiadomości, które spełniają kryteria przekazane do nas za pomocą tzw. query parameters. Mamy do dyspozycji dwa parametry: id oraz created_at.