Flask против webapp2 для Google App Engine

116

Я запускаю новое приложение Google App Engine и сейчас рассматриваю две платформы: Flask и webapp2 . Я довольно доволен встроенной структурой веб-приложений, которую я использовал для своего предыдущего приложения App Engine, поэтому я думаю, что webapp2 будет еще лучше, и у меня не будет никаких проблем с ним.

Тем не менее, есть много хороших обзоров Flask, мне очень нравится его подход и все то, что я прочитал в документации, и я хочу попробовать его. Но меня немного беспокоят ограничения, с которыми я могу столкнуться с Flask.

Итак, вопрос: знаете ли вы какие-либо проблемы, проблемы с производительностью, ограничения (например, систему маршрутизации, встроенный механизм авторизации и т. Д.), Которые Flask мог бы добавить в приложение Google App Engine? Под «проблемой» я имею в виду то, что я не могу обойти с помощью нескольких строк кода (или любого разумного количества кода и усилий), или что-то, что совершенно невозможно.

И в качестве дополнительного вопроса: есть ли в Flask какие-нибудь убийственные функции, которые, по вашему мнению, могут взорвать мой разум и заставить меня использовать его, несмотря на любые проблемы, с которыми я могу столкнуться?

Антон Моисеев
источник
Я мало что знаю о webapp2, но я использую Flask уже несколько месяцев, и мне это нравится. Я нашел плагины flask, которые действительно помогли мне, например, flask-babelдля поддержки нескольких языков и flask-seasurfподдержки CSRF для защиты моих форм.
ThePloki 08

Ответы:

138

Отказ от ответственности: я являюсь автором tipfy и webapp2.

Большим преимуществом использования webapp (или его естественного развития, webapp2) является то, что вам не нужно создавать свои собственные версии для существующих обработчиков SDK для выбранной вами структуры.

Например, deferred использует обработчик веб-приложений. Чтобы использовать его в чистом представлении Flask, используя werkzeug.Request и werkzeug.Response, вам необходимо реализовать отложенный для него (как я сделал здесь для tipfy).

То же самое происходит и с другими обработчиками: blobstore (Werkzeug все еще не поддерживает запросы диапазона, поэтому вам нужно будет использовать WebOb, даже если вы создадите свой собственный обработчик - см. Tipfy.appengine.blobstore ), mail, XMPP и так далее, или другие, которые будут включены в SDK в будущем.

И то же самое происходит с библиотеками, созданными с учетом App Engine, такими как ProtoRPC , который основан на webapp и для работы с другими фреймворками потребуется порт или адаптер, если вы не хотите смешивать webapp и your-framework-of- обработчики выбора в том же приложении.

Таким образом, даже если вы выберете другую платформу, вы закончите: а) использование webapp в некоторых особых случаях или б) необходимость создавать и поддерживать свои версии для определенных обработчиков или функций SDK, если вы их будете использовать.

Я предпочитаю Werkzeug, а не WebOb, но после более чем одного года портирования и поддержки версий обработчиков SDK, которые изначально работают с tipfy, я понял, что это безнадежное дело - чтобы поддерживать GAE в долгосрочной перспективе, лучше всего оставаться рядом с WebApp / WebOb. Это упрощает поддержку библиотек SDK, обслуживание становится намного проще, оно более перспективно, поскольку новые библиотеки и функции SDK будут работать из коробки, а большое сообщество будет работать с теми же инструментами App Engine.

В защиту конкретных webapp2 суммированы здесь . Добавьте к этому то, что webapp2 можно использовать вне App Engine и легко настроить так, чтобы он выглядел как популярные микро-фреймворки. и у вас будет хороший набор веских причин для этого. Кроме того, у webapp2 есть большие шансы быть включенным в будущий выпуск SDK (это неофициально, не цитируйте меня :-), что продвинет его вперед и привлечет новых разработчиков и внесет свой вклад.

Тем не менее, я большой поклонник Werkzeug и ребят из Pocoo и много позаимствовал у Flask и других (web.py, Tornado), но - и, знаете ли, я предвзято - вышеупомянутые преимущества webapp2 должны приниматься во внимание.

Moraes
источник
10
Спасибо, @moraes! Достаточно солидный. Я думаю, что такие вещи, как blobstore, почта (и, вероятно, ProtoRPC) являются довольно важными частями для этого проекта, и я хочу работать с ними как можно более гладко. Кроме того, я думаю, что смешивать разные фреймворки - не лучшая идея, если вы легко можете этого избежать. Более того, несмотря на то, что я симпатизирую Flask, я действительно впечатлен webapp2, и у меня чешутся руки попробовать его. Спасибо за ответ и за webapp2!
Антон Моисеев
3
@Sundar Он может работать на любом WSGI-совместимом веб-сервере. Для Apache есть code.google.com/p/modwsgi и другие.
Мораес 06
4
@moraes: Этот ответ уже устарел? Я вижу, что GAE SDK поддерживает Flask. Webapp2 по-прежнему лучший выбор?
ноябрь
1
@nish, ссылка на то, что GAE SDK официально поддерживает Flask?
enkash
15
Просто обратите внимание, что, хотя это уже принятый ответ, разработка webapp2 мертва. Я бы сказал, что Flask - это то, что нужно.
Джесси
13

Ваш вопрос очень широкий, но, похоже, нет больших проблем с использованием Flask в Google App Engine.

Эта ветка списка рассылки ссылается на несколько шаблонов:

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

А вот руководство, посвященное комбинации Flask / App Engine:

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

Также см. App Engine - Проблемы с доступом к данным Twitter - Flask , Ошибка при мигании сообщений Flask при переадресации и Как управлять сторонними библиотеками Python с помощью Google App Engine? (virtualenv? pip?) о проблемах, которые возникли с Flask и Google App Engine.

AGF
источник
7
Спасибо, @agf. Я видел большинство этих постов раньше, но думаю, что меня больше интересует личный опыт. Я не думаю, что вопрос настолько широк, поскольку меня не интересует всестороннее обсуждение или подробная информация о проблеме, просто укажите мне, что это и это будет сложно или невозможно реализовать.
Антон Моисеев
2
@Anton, запрос субъективного личного опыта довольно близок к рекомендациям SO по вопросам, которые не следует задавать .
Джеймс
9
@ Джеймс - Не согласен. Я не спрашиваю вас о ваших догадках, предположениях или субъективных ощущениях. Я спрашиваю о вашем опыте, т.е. о фактах, которые вам достоверно известны. Не устаревшие сообщения и не проблемы, с которыми другие люди столкнулись во время тяжелой настройки, а просто факты. Не согласен - хорошо, просто отметьте это.
Антон Моисеев
3

Для меня решение в пользу webapp2 было простым, когда я обнаружил, что flask не является объектно-ориентированной структурой (с самого начала), а webapp2 - чисто объектно-ориентированной структурой. webapp2 использует диспетчеризацию на основе методов в качестве стандарта для всех RequestHandler (поскольку документация по флэш-памяти называет это и реализует его с версии V0.7 в MethodViews). Хотя в Flask MethodView являются надстройкой, это основной принцип дизайна для webapp2. Таким образом, ваш дизайн программного обеспечения будет выглядеть по-разному при использовании обеих платформ. Обе структуры используют современные шаблоны jinja2 и практически идентичны по функциям.

Я предпочитаю добавлять проверки безопасности к RequestHandler базового класса и наследовать от него. Это также хорошо для служебных функций и т. Д. Как вы можете видеть, например, в ссылке [3], вы можете переопределить методы для предотвращения отправки запроса.

Если вы OO-человек или вам нужно разработать REST-сервер, я бы порекомендовал вам webapp2. Если вы предпочитаете простые функции с декораторами в качестве обработчиков для нескольких типов запросов или вас не устраивает объектно-ориентированное наследование, тогда выберите flask. Я думаю, что обе структуры избегают сложности и зависимостей гораздо более крупных структур, таких как пирамида.

  1. http://flask.pocoo.org/docs/0.10/views/#method-based-dispatching
  2. https://webapp-improved.appspot.com/guide/handlers.html
  3. https://webapp-improved.appspot.com/guide/handlers.html#overriding-dispatch
кошка
источник
вот и все, меня покорила поддержка ООП. Изначально я использую web.py, но кажется, что у webapp2 аккуратная структура без обходного пути, который я использовал на web.py. flask может быть легко запустить, но вам понадобится нечто большее, если вы планируете делать большие приложения
Ахмад Музакки
2

Я думаю, что движок приложений Google официально поддерживает фреймворк. Здесь есть образец кода и руководство -> https://console.developers.google.com/start/appengine?_ga=1.36257892.596387946.1427891855

Anup
источник
для меня это не официальная поддержка, это всего лишь пример стиля «вы тоже можете сделать это с Flask». Для webapp2 все еще есть подробное руководство с добавленными здесь и там элементами, относящимися к GAE.
silpol
2

Я не пробовал webapp2 и обнаружил, что tipfy было немного сложно использовать, поскольку для этого требовались сценарии установки и сборки, которые настраивают вашу установку python не по умолчанию. По этим и другим причинам я не сделал свой самый большой проект зависимым от фреймворка, и вместо этого я использую простое веб-приложение, добавляю библиотеку под названием beaker, чтобы получить возможности сеанса, а django уже имеет встроенные переводы для слов, общих для многих вариантов использования, поэтому при создании локализованное приложение django было правильным выбором для моего крупнейшего проекта. Двумя другими фреймворками, которые я фактически развернул с проектами в производственной среде, были GAEframework.com и web2py, и в целом кажется, что добавление фреймворка, изменяющего его механизм шаблонов, может привести к несовместимости между старой и новой версиями.

Итак, мой опыт показывает, что я не хочу добавлять фреймворк в свои проекты, если они не решают более сложные варианты использования (загрузка файлов, мульти-аутентификация, пользовательский интерфейс администратора - это 3 примера более сложных вариантов использования, которых нет в настоящее время для gae. хорошо справляется.

Никлас Р.
источник