Flask vs webapp2 для Google App Engine

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

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

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

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

ОТВЕТЫ

Ответ 1

Отказ от ответственности: Я автор tipfy и webapp2.

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

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

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

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

Итак, даже если вы выберете другую структуру, вы закончите: a) используя webapp в некоторых особых случаях или b) вам придется создавать и поддерживать ваши версии для определенных обработчиков или функций 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 должны быть приняты во внимание.

Ответ 2

Ваш вопрос чрезвычайно широк, но, похоже, нет больших проблем с использованием 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/

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

Ответ 4

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

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

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

Ответ 5

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

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