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ć?
źródło
flask-babelwielu języków iflask-seasurfobsługa CSRF w celu zabezpieczenia moich formularzy.Odpowiedzi:
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ę.
źródło
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.
źródło
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.
źródło
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
źródło
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.
źródło