Flask vs webapp2 dla Google App Engine

116

Rozpoczynam nową aplikację Google App Engine i obecnie rozważam dwa frameworki: Flask i webapp2 . Jestem raczej zadowolony z wbudowanego frameworka webapp, którego użyłem w mojej poprzedniej aplikacji App Engine, więc myślę, że webapp2 będzie jeszcze lepszy i nie będę miał z nim żadnych problemów.

Jest jednak wiele dobrych recenzji Flaska, bardzo podoba mi się jego podejście i wszystkie rzeczy, które przeczytałem do tej pory w dokumentacji i chcę go wypróbować. Ale jestem trochę zaniepokojony ograniczeniami, z którymi mogę się zmierzyć dzięki Flask.

Pytanie brzmi więc - czy znasz jakieś problemy, problemy z wydajnością, ograniczenia (np. System routingu, wbudowany mechanizm autoryzacji itp.), Które Flask mógłby wprowadzić do aplikacji Google App Engine? Przez „problem” rozumiem coś, czego nie mogę obejść w kilku wierszach kodu (lub rozsądnej ilości kodu i wysiłków) lub coś, co jest całkowicie niemożliwe.

I jako pytanie uzupełniające: czy są jakieś zabójcze funkcje w Flask, które Twoim zdaniem mogą zaskoczyć mnie i zmusić mnie do użycia go pomimo wszelkich problemów, z którymi mogę się zmierzyć?

— Anton Moiseev
źródło

Niewiele wiem o webapp2, ale używam Flaska od kilku miesięcy i bardzo mi się to podoba. Znalazłem wtyczki flask, które naprawdę mi pomogły, takie jak obsługa flask-babelwielu języków i flask-seasurfobsługa CSRF w celu zabezpieczenia moich formularzy.

— ThePloki

138

Zastrzeżenie: jestem autorem tipfy i webapp2.

Dużą zaletą trzymania się aplikacji internetowej (lub jej naturalnej ewolucji, webapp2) jest to, że nie musisz tworzyć własnych wersji dla istniejących programów obsługi SDK dla wybranej platformy.

Na przykład deferred używa programu obsługi aplikacji sieci Web. Aby użyć go w czystym widoku Flask, używając werkzeug.Request i werkzeug.Response, musisz zaimplementować odroczony dla niego (tak jak zrobiłem tutaj dla tipfy).

To samo dzieje się z innymi modułami obsługi: blobstore (Werkzeug nadal nie obsługuje żądań zakresu, więc będziesz musiał użyć WebOb, nawet jeśli utworzysz własny moduł obsługi - patrz tipfy.appengine.blobstore ), mail, XMPP i tak dalej, lub inne, które zostaną uwzględnione w zestawie SDK w przyszłości.

To samo dzieje się z bibliotekami utworzonymi z myślą o App Engine, np ProtoRPC , który jest oparty na aplikacji internetowej i wymagałby portu lub adaptera do współpracy z innymi frameworkami, jeśli nie chcesz mieszać aplikacji internetowej i swojej struktury programy obsługi wyboru w tej samej aplikacji.

Tak więc, nawet jeśli wybierzesz inną platformę, zakończysz a) używanie aplikacji internetowej w niektórych specjalnych przypadkach lub b) konieczność tworzenia i utrzymywania wersji dla określonych programów obsługi SDK lub funkcji, jeśli będziesz ich używać.

Znacznie wolę Werkzeug od WebOb, ale po ponad roku przenoszenia i utrzymywania wersji programów obsługi SDK, które działają natywnie z tipfy, zdałem sobie sprawę, że jest to przegrana sprawa - aby wspierać GAE w dłuższej perspektywie, najlepiej jest pozostać blisko webapp / WebOb. To sprawia, że obsługa bibliotek SDK jest bardzo prosta, konserwacja staje się dużo łatwiejsza, jest bardziej przyszłościowa, ponieważ nowe biblioteki i funkcje SDK będą działać od razu po wyjęciu z pudełka, a duża społeczność pracuje wokół tych samych narzędzi App Engine.

Specyficzną webapp2 obrony podsumowano tutaj . Dodaj do tych, że webapp2 może być używany poza App Engine i jest łatwo dostosować, aby wyglądał jak popularne mikro-frameworki, a masz dobry zestaw ważnych powodów, aby to zrobić. Ponadto, webapp2 ma duże szanse na dołączenie do przyszłej wersji SDK (to jest nieoficjalne, nie cytuj mnie :-), co popchnie ją do przodu i przyniesie nowych programistów i wkład.

To powiedziawszy, jestem wielkim fanem Werkzeug i Pocoo i dużo pożyczyłem od Flaska i innych (web.py, Tornado), ale - i wiesz, jestem stronniczy - powyższe korzyści z webapp2 powinny być branym pod uwagę.

— moraes
źródło

10

Dzięki, @moraes! Wystarczająco solidne. Myślę, że takie rzeczy jak blobstore, mail (i prawdopodobnie ProtoRPC) są dość ważnymi elementami dla tego projektu i chcę z nimi pracować tak płynnie, jak to tylko możliwe. Myślę też, że mieszanie różnych frameworków nie jest najlepszym pomysłem, jeśli można go łatwo uniknąć. Co więcej, pomimo faktu, że sympatyzuję z Flaskiem, jestem pod wrażeniem webapp2 i mam ochotę go wypróbować. Dziękuję za odpowiedź i za webapp2!

— Anton Moiseev

3

@Sundar Może działać na dowolnym serwerze WWW zgodnym z WSGI. W przypadku Apache jest code.google.com/p/modwsgi i inne.

— moraes

4

@moraes: Czy ta odpowiedź jest teraz nieaktualna? Widzę, że GAE SDK obsługuje Flask. Czy webapp2 nadal jest lepszym wyborem?

— zakończenie

1

@nish, odniesienie do tego, że GAE SDK oficjalnie obsługuje Flask?

— enkash

15

Tylko uwaga, że chociaż jest to tradycyjna przyjęta odpowiedź, programowanie webapp2 jest martwe. Powiedziałbym, że Flask jest drogą do zrobienia.

— Jesse

13

Twoje pytanie jest bardzo obszerne, ale wydaje się, że używanie Flask w Google App Engine nie stanowi większych problemów.

Ten wątek listy mailingowej zawiera linki do kilku szablonów:

http://flask.pocoo.org/mailinglist/archive/2011/3/27/google-app-engine/#4f95bab1627a24922c60ad1d0a0a8e44

A oto samouczek dotyczący kombinacji Flask / App Engine:

http://www.franciscosouza.com/2010/08/flying-with-flask-on-google-app-engine/

Zobacz też App Engine - Trudność w uzyskiwaniu dostępu do danych Twittera - Flask , flashowanie wiadomości Flask kończy się niepowodzeniem w przypadku przekierowań oraz Jak zarządzać bibliotekami Python innych firm za pomocą Google App Engine? (virtualenv? pip?) w przypadku problemów z Flask i Google App Engine.

— agf
źródło

7

Dzięki, @agf. Widziałem już większość tych postów, ale myślę, że bardziej interesują mnie osobiste doświadczenia. Nie wydaje mi się, żeby to pytanie było aż tak szerokie, bo nie interesuje mnie obszerna dyskusja czy szczegółowe informacje o problemie, tylko wskaż mi, że to i to będzie trudne lub niemożliwe do zrealizowania.

— Anton Moiseev,

2

@Anton, Żądanie subiektywnego osobistego doświadczenia jest bardzo zbliżone do wytycznych SO dotyczących pytań, których nie należy zadawać .

— James,

9

@James - Nie zgadzaj się. Nie pytam o Twoje domysły, przypuszczenia czy subiektywne odczucia. Pytam o Twoje doświadczenie, czyli o fakty, które z całą pewnością znasz. Nie przestarzałe posty ani problemy, z którymi borykali się inni ludzie podczas intensywnego dostosowywania, tylko fakty. Nie zgadzaj się - ok, po prostu oznacz to.

— Anton Moiseev,

3

Dla mnie decyzja o webapp2 była łatwa, kiedy odkryłem, że flask nie jest frameworkiem zorientowanym obiektowo (od początku), podczas gdy webapp2 jest frameworkiem czysto obiektowym. webapp2 używa metody Method Based Dispatching jako standard dla wszystkich RequestHandlerów (jak nazywa to dokumentacja Flask i implementuje ją od wersji 0.7 w MethodViews). Podczas gdy w flask MethodViews są dodatkiem, jest to podstawowa zasada projektowania dla webapp2. Projekt oprogramowania będzie wyglądał inaczej przy użyciu obu frameworków. Oba frameworki używają obecnie szablonów jinja2 i są dość identyczne.

Wolę dodawać kontrole bezpieczeństwa do klasy bazowej RequestHandler i dziedziczyć z niej. Jest to również dobre dla funkcji narzędziowych itp. Jak widać na przykład w linku [3], możesz nadpisać metody, aby zapobiec wysyłaniu żądania.

Jeśli jesteś OO-osobą lub potrzebujesz zaprojektować serwer REST, polecam webapp2. Jeśli wolisz proste funkcje z dekoratorami jako programami obsługi dla wielu typów żądań lub nie czujesz się komfortowo z dziedziczeniem OO, wybierz flask. Myślę, że oba frameworki unikają złożoności i zależności znacznie większych frameworków, takich jak piramida.

— kot
źródło

to wszystko, wsparcie OOP wygrało mnie. Początkowo używam web.py, ale wydaje się, że webapp2 ma zgrabną strukturę bez obejścia, które zrobiłem na web.py. flask może być łatwy do uruchomienia, ale potrzebujesz czegoś więcej, jeśli planujesz tworzyć większe aplikacje

— Ahmad Muzakki

2

Myślę, że silnik aplikacji Google oficjalnie obsługuje platformę flask. Tutaj jest przykładowy kod i samouczek -> https://console.developers.google.com/start/appengine?_ga=1.36257892.596387946.1427891855

— Anup
źródło

dla mnie to nie jest oficjalne wsparcie, to tylko przykład "możesz to zrobić z Flaskiem też". W przypadku aplikacji webapp2 nadal istnieje szczegółowa instrukcja z dodanymi tu i tam elementami specyficznymi dla GAE.

— silpol

2

Nie próbowałem webapp2 i stwierdziłem, że tipfy było trochę trudne w użyciu, ponieważ wymagało skryptów konfiguracyjnych i kompilacji, które konfigurują instalację Pythona na inną niż domyślna. Z tych i innych powodów nie uzależniłem swojego największego projektu od frameworka i zamiast tego używam zwykłej aplikacji internetowej, dodaję bibliotekę o nazwie beaker, aby uzyskać możliwości sesji, a django ma już wbudowane tłumaczenia słów wspólnych dla wielu przypadków, więc podczas budowania zlokalizowana aplikacja django była właściwym wyborem dla mojego największego projektu. Dwa inne frameworki, które faktycznie wdrożyłem z projektami w środowisku produkcyjnym, to GAEframework.com i web2py i ogólnie wydaje się, że dodanie frameworka zmieniającego jego silnik szablonów może prowadzić do niekompatybilności między starą a nową wersją.

Z mojego doświadczenia wynika, że nie chcę dodawać frameworka do moich projektów, chyba że rozwiązują one bardziej zaawansowane przypadki użycia (przesyłanie plików, wielokrotne uwierzytelnianie, interfejs administratora to 3 przykłady bardziej zaawansowanych przypadków użycia, których obecnie nie ma frameworku dla gae dobrze się trzyma.

— Niklas R.
źródło