Heloł:)

Artykuł ten jest trochę kontynuacją/rozszerzeniem tego wpisu – link – więc zanim przejdziesz dalej – sugeruję przeczytać go, bo wprowadza w temat problemu który rozwiązujemy. Oczywiście część informacji powtórzę, ale jeśli masz czas – to warto tam zajrzeć.

Skoro organizacyjne rzeczy mamy za sobą, czas przejść do sedna.

Skąd pomysł na ten artykuł?

Wpis który zlinkowałem wyżej pokazuje jak możemy napisać usługę która wykorzystując technologię WebSocket pozwala na upload pliku na serwer + sprawdzenie pliku programem antywirusowym i odesłanie statusu. Wartością dodaną jest oczywiście stworzenie własnego protokołu „on top of WS”.

I jestem oczywiście zadowolony z tego wpisu:) Z jednym, małym, malutkim.. ALE.

Post tamten był pisany na początku roku 2018 co znaczy że się troszkę przedawnił – a dokładniej, rozwiązanie którego użyłem na backendzie, tj. gevent – w świetle tego że w bibliotece standardowej zagościło inne rozwiązanie które pozwala zaimplementować pętlę zdarzeń – nie już takie „sexy” ;)

Co takiego pojawiło się w bibliotece standardowej?

Po prawdzie to, asyncio, bo tak nazywa się biblioteka o której jest dzisiejszy wpis, jest w stdlibie już od Pythona 3.4, to relatywnie od niedawna nadaje się do użytku.

Asyncio to biblioteka pozwalająca na asynchroniczne programowanie w ramach pętli zdarzeń. Owa pętla zdarzeń, to w pewnym uproszczeniu, pętla która pozwala na „równoległe” wykonywanie się zadań. Schemat działania wygląda tak:

W nomenklaturze asyncio, Request który jest na schemacie, nazywany jest korutyną (ang. coroutine), natomiast w gevencie – greenletem. Warto tu dodać że istnieje tłumaczenie słowa coroutine i brzmi ono „współprogram”, z tym że nie spotkałem się z jego powszechnym użyciem, co jest powodem tego że w tym wpisie będzie spolszczone słowo – korutyna. Całość koncepcji pętli zdarzeń (ang. event loop) polega na tym że kolejne korutyny wchodzą do pętli i są wykonywane, jednakże każde żądanie I/O (input / output) np. zapytanie do bazy, zapis pliku, komunikacji via http z zewnętrznym serwerem, powoduje że korutyna taka nie blokuje całej pętli, dając możliwość wykonania się innej korutynie, jeśli wróci odpowiedź z żądania I/O, korutyna powróci do pętli i zacznie wykonywać się od momentu w którym skończyła.

Asyncio wprowadza do definicji korutyn słowa kluczowe async i await – dokładniej jest to tzw. „sugar syntax” – element składni języka który służy tylko wygodzie programisty i przykrywa, w tym przypadku, odpowiednie dekoratory. To pierwsze definiuje nam że funkcja jest korutyną a await sprawia że korutyna jest przerywana i inna przejmuje wątek. Bo cała pętla zdarzeń to jeden wątek. Przykład korutyny:

Po więcej informacji a także kilka fajnych wykresów odsyłam na tę stronę.

Wracając do naszego przykładu..

Zgodnie z tym co było w moim artykule, które zlinkowałem na początku wpisu, zaimplementujemy dziś serwer WebSocket’owy który pozwoli na zapis plików na serwer oraz sprawdzenie ich programem ClamAV. Przypominam nasz protokół:

Pisząc implementacje w asyncio zachowany ten protokół, dzięki czemu kod JSowy na froncie (pokazany w artykule z geventem) nie zmieni się :) taki oto plus konsekwentnego programowania.

Czas na kod

Nim zaczniemy sobie pisać kod, muszę dodać że wpis z geventem był pod Python’a 2.7 – dziś piszemy pod Pythona 3.7, więc poza tym że będą słowa kluczowe async/await to spotkacie się również z definicją typów, zamianą słowa kluczowego print na funkcję oraz z tym że Python 3.7 ma osobny typ – bytes.

Aby móc pisać kod należy dociągnąć dwie zależności:

pip install aiohttp aiofiles

Pierwsza do obsługi protokołu WebSocket druga do zapisu pliku na dysk. Widać tu wadę asyncio – jeśli chcemy użyć biblioteki, konieczne jest by była await’owana. Nie zawsze idzie znaleźć odpowiednio stabilne rozwiązanie. W gevencie działało to nieco inaczej – on patchował sobie bibliotekę standardową a dokładnie sockety, pliki itp. – dzięki czemu prawie każda biblioteka była od razu „gevent-friendly”.

No ale już finalnie przechodząc do kodu, stwórzmy klasę która będzie realizować serwer WS:

Schemat kolekcjonowania danych jest taki sam jak w poprzednim wpisie, więc ominę jego omówienie a skupię się na async/await. Ogólnie rozstawienie awaitów ma znaczenie, to gdzie program przerwie działanie może mieć znaczenie dla architektury jak i wydajności. Zauważ proszę że odebrania pakietu danych prawie od razu jest skazane na await:

powoduje to oddanie sterowania do pętli zdarzeń i obsługę innej korutyny – np. innego połączenia, ale też ewentualnie tej samej, jeśli nie ma innych. Kolejny await jest zależny od typu pakietu. Np. dla typu „RAW_DATA”, dane są zapisywane w pamięci i zwracana jest do klienta informacja o tym ile tych danych zostało zapisane – znów z await:

Pewnie wnikliwy czytelnik zauważył że klasa ta dziedziczy po innej, tutaj jej ciało:

Nie różni się to dużo od klasy która była w poprzednim artykule, poza formą zapisu do pliku już zebranych danych – tu używamy aiofiles no i mamy typ bytes.

I na sam koniec sprawdzanie plików programem antywirusowym:

Do pełni szczęścia brakuje tylko importów

Co dalej z asyncio?

Asyncio to rozwiązanie które nie jest odpowiednie dla każdego problemu. Zauważ proszę że nie sprawdzi się to w momencie kiedy aplikacja będzie robić skomplikowane obliczenia, natomiast super sprawdzi się jako proxy. W sumie program który napisałem to takie proxy miedzy użytkownikiem który wgrywa plik a komputerem docelowym – przerzuca dane – i do tego asyncio, ogólnie cała pętla zdarzeć, bo to technologia która jest obecna nie tylko w Pythonie, sprawdzi się znakomicie!