With the Flow

Zrobiłem sobie takie coś — mechanizm ładowania szablonów dla Jinja 2, który trzyma zawartość szablonu w memcache i w razie czego ładuje go z pamięci.

class CachedFileSystemLoader(FileSystemLoader):

    def get_source(self, environment, template):
        key = 'template:%s.%s' % (template, os.environ['CURRENT_VERSION_ID'])
        contents = memcache.get(key)
        if contents is None:
            contents, filename, uptodate = \
                super(CachedFileSystemLoader, self).get_source(environment, template)
            memcache.set(key, contents, 60*60*24)
        else:
            pieces = split_template_path(template)
            filename = os.path.join(self.searchpath[0], *pieces)
            uptodate = lambda: True
        return contents, filename, uptodate

Jak na razie działa.

Alan deLevie zrobił szablon aplikacji na Google AppEngine, który ma być lepszy i wygodniejszy w użyciu od domyślnego, dostarczanego wraz z SDK. Opiera się on na tym, co dostarcza Google (tzn. szablony Django i WebApp). Ja używam innej narzędziówki, więc mój szablon jest zupełnie inny:

proj-name
    apps[1]
    babel
    contrib[2]
        gaeutils
    datastore[3]
    jinja2
    media[4]
        css
        img
        js
    pytz
    sitelib[5]
        utils
    templates
    werkzeug
    wtforms

Kilka rzeczy wymaga pewnego objaśnienia. W katalogu apps[1] znajdują się aplikacje (używając terminologii Django) i mój własny kod serwisu. Do contrib[2] trafiają gotowe moduły i pakiety narzędziowe, jak GAEUtilities czy procesory markupu. Katalog datastore[3] zawiera storage, bo nie chcę go przechowywać w /tmp (ginie przy restarcie systemu a ja nie lubię być zaskakiwany...). W media[4] znajdują się statyki, czyli m.in. również robots.txt oprócz zwyczajowych obrazków, styli i javascriptu. W sitelib[5] jest kod biblioteczny związany z tym konkretnym projektem (w root) i specyficzny dla AppEngine (w utils). Katalogi z pakietami narzędziowymi (np. Babel czy Jinja) są podlinkowane z katalogu, w którym mam lokalną kopię repozytorium z bibliotekami. Oprócz tego w katalogu głównym projektu jest normalny boilerplate (app.yaml, index.yaml, main.py) oraz moduł application.py, w którym mam zdefiniowaną klasę aplikacji WSGI.

Jak do tej pory ten szablon sprawdził się w 3 aplikacjach (w tym także w tej, którą właśnie oglądasz).

Google AppEngine jest ubogie w biblioteki (poza nieco zubożoną biblioteką standardową Pythona dostępne tylko PyYaml, WebOb i Django-0.96), więc każdy kto robi aplikację na to środowisko musi dołączać do aplikacji wszystko, co jest mu potrzebne. Jeżeli aplikacja jest jedna, to pół biedy, da się to utrzymać. Jeżeli jest kilka, to wypadałoby zadbać jakoś o synchronizację. Ta potrzeba doprowadziła mnie do wynalazku, który nie ma nazwy, tylko funkcjonalność — repozytorium bibliotek, których używam na AppEngine. Od repozytoriów źródłowych różni się to tym, że w u mnie biblioteki są w formie takiej, że nic tylko wrzucać i jechać — powycinane są z nich wszystkie te moduły, które nie są potrzebne lub nie mają szansy zadziałać na AppEngine, a w kilku przypadkach zostały odchudzone lub przerobione, żeby nie stanowić nadmiernego obciążenia dla GAE.

W chwili obecnej zawartość repozytorium przedstawia się następująco (w nawiasie opis zmian względem oryginału, brak podanej wersji oznacza wersję rozwojową):

• babel, wersja 0.9.4 (tylko funkcje l10n, zawiera lokalizacje dla en, en_US, en_GB, de, de_DE, de_AT, pl i pl_PL);
• jinja2 (usunięte moduł z przyspieszaczami w C i wsparcie dla IronPythona);
• openid, wersja 2.2.1 (tylko consumer);
• pytz, wersja 2009a (wraz z ułatwiaczem dla AppEngine, zawiera wszystkie strefy czasowe!);
• werkzeug (usunięte parę contribów, które nie mają szans zadziałać na AppEngine);
• wtforms (bez dodatków dla Django).

Wszystkie biblioteki są aktualizowane na bieżąco w miarę pojawiania się nowych wydań lub zmian w repozytoriach źródłowych, co może oznaczać, że incydentalnie mogą się w nich pojawiać błędy, a także (w przypadku wersji rozwojowych) mogą pojawiać się zmiany interfejsu bibliotek. Repozytorium jest trzymane w SVN, więc żądni adrenaliny mogą je dołączyć przez svn:externals. Bardziej stateczni mogą sobie po prostu ściągnąć i porobić symlinki.

No i czas wreszcie na zaspokojenie apetytu. URL repozytorium to http://gae-3rdparty-libs.googlecode.com/svn/trunk/ — repozytorium jest publiczne, więc możliwy jest anonimowy checkout, bez konieczności zakładania konta Google.

Na koniec jeszcze konieczny disklajma: używasz tego na własną odpowiedzialność. Staram się nie umieszczać tam kodu, który jest zepsuty, ale nie gwarantuję poprawnego działania.

To nie jest wprowadzenie do pisania aplikacji na Google AppEngine, ani tym bardziej samouczek Pythona. Nie zamierzam też uprawiać ewangelizacji (choć w przypadku Pythona na pewno by nie zaszkodziło). O co więc chodzi?

Gdy około rok temu (w kwietniu 2008 roku) Google udostępniło swoją nową usługę, wszystkim opadły szczęki — run your application on Google infrastructure wydawało się obietnicą killer feature. Minął rok, ekscytacja opadła, w tym czasie Google znacznie rozwinęło swój produkt (i rozwija go nadal), zaczęło też pobierać opłaty za jego używanie i zapowiedziało znaczną redukcję tego, co będzie dostępne za darmo. Nie łudźmy się, nadal jest to produkt w stadium beta, którego nikt poważnie nie będzie traktował, jeżeli chodzi o uruchamianie poważnych aplikacji w tym środowisku. Obietnica niegraniczonej skalowalności jest jednak wciąż kusząca i choćby z tego powodu warto się chwilę zastanowić, czy napisanie aplikacji w Pythonie na to środowisko nie byłoby rozsądnym rozwiązaniem. W tym artykule mam nadzieję przybliżyć kilka idei, które ułatwią podjęcie takiej decyzji i postaram się zrobić to w miarę bezstronnie.

Vendor lock-in

Wszyscy chyba wiedzą, co to takiego. Jak sobie przypominam z czasów, kiedy jeszcze używałem Windows®, niemal codziennie oskarżano o to Microsoft, Oracle, IBM i chyba wszystkich dużych na runku oprogramowania. Tym razem sytuacja jest podobna do pewnego stopnia, ale nie identyczna. Platforma AppEngine jest bardzo specyficzna, ale to co jest specyficzne to są rzeczy dodatkowe względem aplikacji — nie dotykają one jej zasadniczego działania.

Przede wszystkim, standardowe jest środowisko uruchomieniowe kodu: jest to WSGI, które już na dobre zadomowiło się w świecie Pythona. Poczynając od sprawy najprostszej, Hello, World! w wykonaniu WSGI można bez żadnych zmian uruchomić zarówno na Google AppEngine jak i w dowolnym środowisku WSGI, jak np. mod_wsgi pod Apache2 czy też używając bramki FastCGI/WSGI jak Flup. Gdzie jest haczyk? Na razie nie ma, ale zrobienie aplikacji bazującej tylko na tym mija się z celem i sensem (nie wspominając już o tym, że byłoby bardzo nużące i pracochłonne). Czas wybrać sobie trochę narzędzi ułatwiających życie. Schody zaczynają się właśnie tutaj, bynajmniej nie z powodu ograniczeń, ale z powodu nadmiaru możliwości.

Standardowo Google wraz z SDK dostarcza kilka narzędzi, które mogą ułatwić pisanie aplikacji i jest ich wbrew pozorom całkiem sporo.

• poziom najniższy, WSGI: AppEngine działa z Pythonem 2.5, więc jest dostępna referencyjna implementacja WSGI w postaci wsgiref;
• podstawowa narzędziówka WSGI, WebOb: dostarcza wrapperów odzwierciedlających żądanie i odpowiedź HTTP, wraz z całą maszynerią parsowania nagłówków, payloadów oraz paroma niezbędnymi podklasami;
• niby-ramówka aplikacyjna WebApp: maksymalnie uproszczona, a jednak działająca;
• Django 0.96: w chwili obecnej mocno przestarzała wersja sprzed kilku lat (powoli zbliżamy się do wydania wersji 1.1), ale wciąż spełniająca świetnie swoją rolę.

Jak widać, na każdym poziomie abstrakcji coś się znajdzie. Z tych wszystkich wymienionych narzędzi, tylko WebApp nie jest standardowe (to znaczy — nie jest używane poza AppEngine). Biorąc dodatkowo pod uwagę to, że do aplikacji można dołączać dodatkowe biblioteki i moduły (z pewnymi ograniczeniami), to sytuacja wciąż wygląda dobrze, więc gdzie jest haczyk?

Czego nie ma, a co udaje że jest

Pierwszy haczyk jest w tym, że nie wszystkie moduły biblioteki standardowej są na AppEngne tym, czym na pierwszy rzut oka zdają się być, a inne w tajemniczy sposób nie istnieją. Część modułów jest importowalna lecz pusta, część jest podmieniona na takie, których jedynym zadaniem jest wyrzucać wyjątek przy próbie wykonania dowolnego kodu. Google w ten sposób zabezpiecza się przed możliwością wywalenia w kosmos środowiska (które przecież ma być współdzielone) i poprosiło swoich inżynierów, żeby pochowali co bardziej niebezpieczne zabawki. Dodatkowo dochodzą ograniczenia platformy systemowej w postaci systemu plików tylko do odczytu i dość restrykcyjnych limitów na wykonanie kodu (czas i zasoby CPU).

Najlepszy storage pod słońcem?

Kolejny haczyk to storage, czyli system przechowywania danych. Nierelacyjny, w dużym stopniu bezschematowy, oparty na własnym wynalazku Google, czyli słynnej BigTable. W porównaniu do zwykłych baz danych można powiedzieć, że składa się właściwie z samych ograniczeń:

• nie ma złączeń, jedynie referencje (dość miękkie);
• zwraca najwyżej 1000 dokumentów (wolę takie okreslenie, niż wiersze);
• nie umie liczyć;
• nie umie wymusić unikalności danych;
• transakcyjność jest w dużym stopniu ograniczona (wymaga grupowania dokumentów) i działa bardzo restrykcyjnie — blokowane są wszystkie dokumenty w grupie;
• bardzo nierównomierne traktowanie odczytów i zapisów — zapisy są o wiele, wiele bardziej kosztowne i zdarzaja się zapaści.

Co dostajemy w zamian? Google powtarza swoją mantrę o niegraniczonej skalowalności (zakładam, że mówią prawdę), więc jeżeli to jest to, czego potrzebujesz, to wymienione ograniczenia nie będą czynnikiem powstrzymującym. W każdym innym przypadku czeka długi i żmudny proces przestawiania myślenia z relacyjnego na nieco bardziej płaskie struktury. Koniecznie muszę nadmienić, że wszystkie wymienione przeze mnie problemy są rozwiązywalne innymi sposobami, ale są one zupełnie nieintuicyjne dla kogoś, kto polega na swoim doświadczeniu z relacyjnymi bazami danych.

Zapomnij

Są rzeczy, które trzeba dopisać w kategorii "zapomnij", to znaczy takie, do których nie ma i nie będzie dostępu, a jedyne, czego można się spodziewać, to jakiejś namiastki:

• dostęp z kodu do zasobów statycznych aplikacji;
• standardowy cron (będzie namiastka, ale oczywiście nie wiadomo kiedy);
• nieograniczone przetwarzanie wsadowe (namiastka crona będzie operować w ramach limitów czasu wykonywania kodu).

Jak z tego widać, Google nie uważa, żeby aplikacja webowa miała potrzebę wykonywania jakichkolwiek operacji offline i na boku (osobiście mało takich widziałem, ale może mam zbyt ograniczone pojęcie...).

Mindset, czyli czego nie widać

Jak dla mnie najważniejszą rzeczą, o której trzeba pomyśleć zanim podejmie się decyzję, czy robić aplikację na AppEngine, czy pozostać w sferze bardziej tradycyjnych platform, jest to, jak sobie z tym poradzą programiści. W odróżnieniu od zwykłych środowisk webowych, AppEngine wybacza niewiele, co z kolei narzuca konieczność bardzo starannego pisania kodu i projektowania aplikacji tak, by nie doprowadzić do wyczerpania dostępnych zasobów w krótkim czasie. Przez cały czas trzeba też mieć na uwadze ograniczenia platformy (szczególnie w kontekście egzotyczności storage).

To w końcu jest czy nie ma tego lock-in?

Do pewnego stopnia jest, ale porównując to do zarzutów stawianych np. Microsoftowi, to skala jest jednak zupełnie nieporównywalna. Nadal można uruchomić aplikację w innym środowisku, choć wymaga to pewnego (zależnego od wybranych narzędzi) zachodu. Istnieją narzędzia, które ułatwiają migrowanie aplikacji w Django z AppEngine do zwykłych środowisk i może to być pewnym ułatwieniem, ale nie ma takich narzędzi dla innych ramówek, które można uruchomić na AppEngine.

A ile wysiłku (czasu, kodowania itd.) trzeba włożyć w to, żeby aplikacja jednak była przenośna? To temat na oddzielny artukuł i na pewno go wkrótce napiszę...

Konkluzje? Jakie konkluzje?!

Za nikogo nie podejmę decyzji, więc nie będę też teraz niczego konkludował. AppEngine ma swoje dobre i złe strony — z jednej strony narzuca wiele ograniczeń, ale z drugiej wymaga rzeczy, które i tak powinny być elementarzem każdego programisty webowego. Jak dla mnie to warto spróbować, o ile aplikacja mieści się w przewidzianym (przez Google!) zakresie tego, co mogą robić aplikacje webowe. Na pewno jest to pouczające doświadczenie, ale dla aplikacji, dla której celem jest zostać sprzedaną to marny argument za. ;)