Even though these two tools seem to be mutually exclusive, they are not. There is possibility to omit Django’s http server and relay all HTTP traffic to FastAPI’s ASGI application. These are the goals of the new package Django FastAPI Bridge

Wait, isn’t Django too old for FastAPI?

If you type “Django and fastapi” into Google you will get results that are simply misinformation. Speaking gently - they’re outdated or written by persons without an experience (a real plague these days):

O kiepskim podejściu do migracji schematów baz danych w Django pisałem już w 2014r. Co jakiś czas jednak temat do mnie wraca, gdyż w niektórych projektach używam (niestety) tego rozwiązania. Powody są różne, a główny to “oszczędność czasu”. No bo trudno zaprzeczyć, że automatyczne wygenerowanie plików z migracjami jest wolniejsze od klepania XML-i Liquibase lub plain SQL , prawda? Sam z tego przecież korzystam…

Jednak bywają takie momenty, gdzie zostaję z tymi migracjami w “czterech literach”, gdzie nawet nie dochodzi ani jeden promyk światła. I taką sytuacją jest m.in. usuwanie atrybutu z modelu, co generuje operację RemoveField.

Nie tak dawno temu wielu zarzucało Django , że w przeciwieństwie do Railsów nie posiada wbudowanego rozwiązania umożliwiającego wersjonowanie i modyfikowanie struktur bazodanowych. Niedługo po tym pojawił się South - dosyć obiecujące rozwiązanie, które oczywiście szybko przygarnąłem do projektów. Z czasem jednak okazało się, że architektura tego rozwiązania ma szereg wad.

Na południe

Podstawowym problemem a zarazem zaletą South jest związek migracji z aplikacjami Django . To poszczególne aplikacje są “dostawcami” migracji. Ma to na celu umożliwienie łatwiejszego utrzymania reusable apps, których upgrade w projektach był bez South bardzo trudny - wymagał poznania zmian struktury i własnoręcznego przygotowania skryptów SQL . O ile było to mozolne ale do zrobienia, to ustalenie migracji danych nie sposób było odtworzyć. Dzięki South sprawa się uprościła.

Prowadziliśmy swego czasu dyskusje o logice biznesowej i szukaliśmy rozwiązania starając się znaleźć jej miejsce w MVC . Stosując bowiem ten paradygmat logika naturalnie “rozmywa się” po kontrolerach i modelach (ekstremiści wstawiają ją nawet do widoków). Typowy przykład złego podejścia to kiepskie implementacje ORM (Propel - PHP , DjangoORM - Python ):

class User(Model):
    def save(*args, **kwargs):
        pass

W tym przypadku Model jest jednocześnie persistance managerem i wykonuje operacje, których nie powinien. Prawidłowe podejście to

class UserManager:
   def save(self, user):
       pass

Który kod łatwiej przetestować? Gdzie znajduje się logika zapisu stanu encji?

Even though these two tools seem to be mutually exclusive, they are not. There is possibility to omit Django’s http server and relay all HTTP traffic to FastAPI’s ASGI application. These are the goals of the new package Django FastAPI Bridge

Wait, isn’t Django too old for FastAPI?

If you type “Django and fastapi” into Google you will get results that are simply misinformation. Speaking gently - they’re outdated or written by persons without an experience (a real plague these days):

ReactJS to moje odkrycie 2019/2020. Po gruntownej analizie plusów dodatnich i ujemnych Angular i ReactJS wybrałem ten ostatni. AngularJS 1.x znałem dosyć długo i doskonale zdawałem sobie sprawę z jego minusów, a te są najważniejsze. Przecież to od nich zależy szybkość developmentu i długofalowe utrzymanie projektu. AngularJS poległ pozostawiając nieczytelny i opuchnięty kod, a two-way bindingiem i watcherami doprowadzał do wysokich temperatur podczas debugowania.

Klasyczny development aplikacji webowych oparty jest o renderowanie części klienckiej przez serwer, a właściwie jego fragmentów. MVC (lub jego jakaś inkarnacja) w części serwerowej tworzą totalnie nieczytelny i niespójny generator klienta, z którym obcuje użytkownik i zespół załamanych developerów. Zarządzanie klienckimi assetami przez serwer (taki jak Django ), mimo dobrej implementacji, też nie należy do najprzyjemniejszych. Łatwo o chaos, szczególnie gdy czas developmentu jest krytyczny. Niech serwer robi to, do czego służy najlepiej - niech świadczy usługi za pomocą ustalonego interfejsu. REST , czy też HTTP +JSON , to droga która powinna być standardem.

Wersja 6

Wersja 6.0 ElasticSearch jest dla mnie szczególna - twórcy wprowadzają zmiany ułatwiające zarządzanie, ale też rezygnują z dawnych błędów, które krytykowałem na łamach tego bloga.

Każdemu polecam migrację do wersji 6.x. Służę pomocą w migracji z wersji 2.x oraz 5.x.

Aktualizacje ElasticSearch - jak wykonać?

Nie można zaprzeczyć, że ElasticSearch jest rozwijany dynamicznie. Tak szybki rozwój produktu nie zawsze jest oczekiwany, bo albo wdrożenie zostaje (z przyczyn obiektywnych) oparte o zamrożoną (i nie wspieraną) wersję, albo konieczne staje się przeprowadzanie migracji do nowszych wersji. Takie operacje trzeba zaplanować, zabudżetować, a na dodatek nie obejdzie się bez downtime i sukcesem jest, gdy przerwa techniczna jest relatywnie krótka.

Oryginalny tekst datowany jest na 4.11.2015, a uzupełniony w lipcu 2016

ElasticSearch jest takim samym systemem wyszukiwania, jak każdy inny powstały w przeciągu ostatnich kilkudziesięciu lat. Indeks ma sztywną strukturę i nic tego nie zmieni. Jedyna różnica polega na tym, że tenże indeks jest modyfikowany w locie / w tle, co niesie za sobą sporo, czasem przykrych konsekwencji, choć na początku może wydawać się to świetnym pomysłem.

Nie-typy, czyli “mappingi”

ElasticSearch posiada tzw. “mappingi” . Niektórzy mogą uważać, że są to typy indeksowanych dokumentów. Słowo “typ” z resztą pada w dokumentacji. Ale to nie są typy. Są to elementy grupujące kolumny indeksu w pewne logiczne klasy , które mogą posłużyć jako dodatkowy filtr lub zbiór definicji o analizerach i tokenizerach, oraz mogą mieć znaczenie wydajnościowe (operujemy na jakimś podzbiorze). Można je porównać do widoków znanych z [RDBMS].

Próbowałem restful.js, próbowałem jQuery REST client, aż ostatecznie dałem sobie spokój. Dla mnie były jakieś trudne/ciężkie w użyciu. A czym powinien być REST client? Cienkim wrapperem na dowolnego klienta HTTP, który gada z dowolnym url-em.

Na własne potrzeby założyłem, że:

• interfejs ma być banalnie prosty w użyciu
• wystarczy obsługa tylko content type application/json
• ma być obsługa nagłówków, także defaultowych (żeby się nie powtarzać)
• dozwolona jest zależność od jQuery (można się tego względnie łatwo wyzbyć)

Powstał prototyp:

Znalazłem ostatnio dwa ciekawe wpisy traktujące o architekturze REST. Pierwszy z nich jest autorstwa niezastąpionego Martina Fowlera, który ciekawie przedstawił drogę od prostych usług typu RPC aż po podstawy RESTful (ale nie samego REST-a). Zdecydowanie ułatwia przejście od jednej do drugiej koncepcji:

Z kolei drugą perełką jest wpis Ryana Tomayko , programisty GitHuba i Heroku, który wytłumaczył idee RESTful (wirtualnej?) żonie. Niestety środowisko zwolenników ideologii ponad rozsądkiem zaatakowało Ryana i autor usunął artykuł-wywiad (a obecnie cała jego strona nie działa), ale na szczęście (w tym wypadku) Internet zachował jego kopię. Znajdziecie takową wyrenderowaną do PDF oraz na archive.org .

Celery

Celery był obiecującym pakietem umożliwiającym kolejkowanie i asynchroniczne wykonywanie zadań, oraz w pewnym stopniu rozproszenie systemu. Kiedyś udało mi się nawet pracować z w miarę stabilną wersją, lecz wskutek błędu związanego z task.retry zostałem zmuszony poszukać rozwiązania w upgrade pakietu. Obecnie major release Celery nosi numer 3 i niestety niewiele się zmieniło w kwestii stabilności.

Autor pakietu, Ask Solem, ma łeb na karku ale wziął sobie na niego za dużo projektów. Mam wrażenie, że facet już nad tym nie panuje. Celery opiera się na jego dwóch innych produktach: Kombu i Billiard . Kombu zastępuje kilka starszych pakietów (również jego autorstwa). Billiard zastępuje standardowy multiprocessing (autor chciałby, aby kiedyś znalazł się w dystrybucji Pythona). Niestety Billiard również jest delikatnie zmaszczony .

Na GitHub i PyPI wrzuciłem implementację prostego automatu skończonego https://github.com/marcinn/dsm

Instalacja

pip install dsm

Przykład 1: Stany zamówienia w sklepie

Załóżmy, że mamy do oprogramowania automat stanów zamówienia w sklepie:

Deklaracja

Wystarczy zdefiniować przejścia za pomocą listy krotek ([stan], [wartość], [nowy stan]), aby automat spełniał swoją rolę.

Deklaracja automatu z przykładu wygląda następująco:

import dsm

class OrderFSM(dsm.StateMachine):
    class Meta:
        transitions = (
            ('new', 'accept', 'accepted'),
            ('new', 'cancel', 'cancelled'),
            ('accepted', 'mark_ready', 'ready'),
            ('accepted', 'cancel', 'cancelled'),
            ('ready', 'send', 'sent'),
            ('ready', 'cancel', 'cancelled'),
            ('sent', 'finalize', 'finalized'),
        )
        initial = 'new'

Symulacja

Kod symulacji: