Я запускаю новое приложение Google App Engine и сейчас рассматриваю две платформы: Flask и webapp2 . Я довольно доволен встроенной структурой веб-приложений, которую я использовал для своего предыдущего приложения App Engine, поэтому я думаю, что webapp2 будет еще лучше, и у меня не будет никаких проблем с ним.
Тем не менее, есть много хороших обзоров Flask, мне очень нравится его подход и все то, что я прочитал в документации, и я хочу попробовать его. Но меня немного беспокоят ограничения, с которыми я могу столкнуться с Flask.
Итак, вопрос: знаете ли вы какие-либо проблемы, проблемы с производительностью, ограничения (например, систему маршрутизации, встроенный механизм авторизации и т. Д.), Которые Flask мог бы добавить в приложение Google App Engine? Под «проблемой» я имею в виду то, что я не могу обойти с помощью нескольких строк кода (или любого разумного количества кода и усилий), или что-то, что совершенно невозможно.
И в качестве дополнительного вопроса: есть ли в Flask какие-нибудь убийственные функции, которые, по вашему мнению, могут взорвать мой разум и заставить меня использовать его, несмотря на любые проблемы, с которыми я могу столкнуться?
источник
flask-babelдля поддержки нескольких языков иflask-seasurfподдержки CSRF для защиты моих форм.Ответы:
Отказ от ответственности: я являюсь автором 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 должны приниматься во внимание.
источник
Ваш вопрос очень широкий, но, похоже, нет больших проблем с использованием 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.
источник
Для меня решение в пользу webapp2 было простым, когда я обнаружил, что flask не является объектно-ориентированной структурой (с самого начала), а webapp2 - чисто объектно-ориентированной структурой. webapp2 использует диспетчеризацию на основе методов в качестве стандарта для всех RequestHandler (поскольку документация по флэш-памяти называет это и реализует его с версии V0.7 в MethodViews). Хотя в Flask MethodView являются надстройкой, это основной принцип дизайна для webapp2. Таким образом, ваш дизайн программного обеспечения будет выглядеть по-разному при использовании обеих платформ. Обе структуры используют современные шаблоны jinja2 и практически идентичны по функциям.
Я предпочитаю добавлять проверки безопасности к RequestHandler базового класса и наследовать от него. Это также хорошо для служебных функций и т. Д. Как вы можете видеть, например, в ссылке [3], вы можете переопределить методы для предотвращения отправки запроса.
Если вы OO-человек или вам нужно разработать REST-сервер, я бы порекомендовал вам webapp2. Если вы предпочитаете простые функции с декораторами в качестве обработчиков для нескольких типов запросов или вас не устраивает объектно-ориентированное наследование, тогда выберите flask. Я думаю, что обе структуры избегают сложности и зависимостей гораздо более крупных структур, таких как пирамида.
источник
Я думаю, что движок приложений Google официально поддерживает фреймворк. Здесь есть образец кода и руководство -> https://console.developers.google.com/start/appengine?_ga=1.36257892.596387946.1427891855
источник
Я не пробовал webapp2 и обнаружил, что tipfy было немного сложно использовать, поскольку для этого требовались сценарии установки и сборки, которые настраивают вашу установку python не по умолчанию. По этим и другим причинам я не сделал свой самый большой проект зависимым от фреймворка, и вместо этого я использую простое веб-приложение, добавляю библиотеку под названием beaker, чтобы получить возможности сеанса, а django уже имеет встроенные переводы для слов, общих для многих вариантов использования, поэтому при создании локализованное приложение django было правильным выбором для моего крупнейшего проекта. Двумя другими фреймворками, которые я фактически развернул с проектами в производственной среде, были GAEframework.com и web2py, и в целом кажется, что добавление фреймворка, изменяющего его механизм шаблонов, может привести к несовместимости между старой и новой версиями.
Итак, мой опыт показывает, что я не хочу добавлять фреймворк в свои проекты, если они не решают более сложные варианты использования (загрузка файлов, мульти-аутентификация, пользовательский интерфейс администратора - это 3 примера более сложных вариантов использования, которых нет в настоящее время для gae. хорошо справляется.
источник