Flask vs webapp2 для Google App Engine

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

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

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

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

114 голосов | спросил Anton Moiseev 21 J000000Thursday11 2011, 14:03:51

5 ответов


0

Отказ от ответственности: я автор 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 в долгосрочной перспективе, лучше всего оставайтесь рядом с веб-приложением /WebOb. Это упрощает поддержку библиотек SDK, обслуживание становится намного проще, оно становится более перспективным, поскольку новые библиотеки и функции SDK будут работать «из коробки», и есть преимущество большого сообщества, работающего над одними и теми же инструментами App Engine.

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

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

ответил moraes 22 J000000Friday11 2011, 11:07:49
0

Ваш вопрос чрезвычайно широк, но, похоже, нет особых проблем с использованием 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 - Flask , Ошибка мигания сообщения колбы при перенаправлении и Как управлять сторонними библиотеками Python с помощью Google App Двигатель? (virtualenv? pip?) из-за проблем, возникающих у пользователей с Flask и Google App Engine.

ответил agf 21 J000000Thursday11 2011, 15:09:33
0

Для меня решение о 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 /просмотров /# метод на основе диспетчеризации
  2. https://webapp-improved.appspot.com/guide/handlers.html
  3. https://webapp-improved.appspot.com/guide/handlers.html # переопределение-диспетчерская
ответил cat 6 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 06 Sep 2015 19:19:26 +0300 2015, 19:19:26
0

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

ответил Anup 3 AMpFri, 03 Apr 2015 09:09:17 +030009Friday 2015, 09:09:17
0

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

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

ответил Niklas Rosencrantz 23 J000000Saturday11 2011, 12:11:10

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132