Flask vs webapp2 для Google App Engine

Question

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

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

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

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

Answer 1

Отказ от ответственности: Я являюсь автором 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-choice в одном приложении.

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

Answer 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/

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

Answer 3

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

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

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

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

Answer 4

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

Answer 5

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

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