Flask vs webapp2 для Google App Engine

116

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

Однак є дуже багато хороших відгуків про Flask, мені дуже подобається його підхід і всі речі, які я до цього часу читав у документації, і хочу спробувати це. Але мене трохи турбують обмеження, з якими я можу зіткнутися з колбою вниз.

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

І як наступне запитання: чи є в Flask якісь вбивчі риси, які, на вашу думку, можуть підірвати мені розум і змусити мене використовувати його, незважаючи на будь-які проблеми, з якими я можу зіткнутися?

— Антон Мойсеєв
джерело

Я не знаю багато про webapp2, але я використовую Flask вже кілька місяців, і мені це подобається. Я знайшов плагіни для фляжок, які мені справді допомогли, наприклад, flask-babelдля підтримки декількох мов та flask-seasurfдля підтримки CSRF для захисту моїх форм.

— ThePloki

138

Відмова: Я є автором tipfy та webapp2.

Великою перевагою дотримання webapp (або його природної еволюції, webapp2) є те, що вам не потрібно створювати власні версії для існуючих обробників SDK для обраної вами рамки.

Наприклад, відкладений використовує обробник веб-сторінки. Щоб використовувати його в чистому режимі Flask, використовуючи werkzeug.Request і werkzeug.Response, вам потрібно буде застосувати відкладені для нього (як я це робив тут для tipfy).

Те саме відбувається і з іншими обробниками: blobstore (Werkzeug досі не підтримує запити діапазону, тому вам потрібно буде використовувати WebOb, навіть якщо ви створили власний обробник - див. Tipfy.appengine.blobstore ), пошту, XMPP тощо. або інші, які в майбутньому будуть включені до SDK.

І те ж саме відбувається з бібліотеками, створеними з App Engine на увазі, як ProtoRPC , який базується на webapp і потребує порту чи адаптера для роботи з іншими рамками, якщо ви не хочете змішувати webapp і ваш- frame-of -of- вибір обробників у тому ж додатку.

Таким чином, навіть якщо ви виберете іншу основу, ви закінчите: a) використання webapp в деяких особливих випадках або b) необхідність створення та підтримки своїх версій для конкретних обробників SDK або функцій, якщо ви їх будете використовувати.

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

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

Це сказало, що я великий фанат Веркзеуга та хлопців Pocoo і багато позичив у Фляска та інших (web.py, Торнадо), але - і, знаєте, я упереджений - вищезгадані переваги webapp2 повинні враховувати.

— моралі
джерело

10

Дякую, @moraes! Досить твердий. Я думаю, що такі речі, як blobstore, пошта (і, мабуть, ProtoRPC) є досить важливими фрагментами для цього проекту, і я хочу працювати з ними як можна більш гладко. Крім того, я вважаю, що змішувати різні рамки - не найкраща ідея, якщо ти можеш її легко уникнути. Більше того, незважаючи на те, що я співчуваю Flask, я дуже вражений webapp2 і в мене сверблять руки, щоб спробувати це. Дякую за відповідь та за webapp2!

— Антон Мойсеєв

3

@Sundar Він може працювати на будь-якому веб-сервері, сумісному WSGI. Для Apache є code.google.com/p/modwsgi та інші.

— морени

4

@moraes: Ця відповідь застаріла зараз? Я бачу, що GAE SDK підтримує Flask. Все-таки кращий вибір є webapp2?

— nish

1

@nish, посилання на те, що GAE SDK підтримує Flask офіційно?

— enkash

15

Лише зауважте, що поки ця відповідь прийнята у спадщину, розвиток webapp2 мертвий. Я б сказав, що колба - це шлях.

— Джессі

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 - Колба , миготливе повідомлення не відображається через переадресації та як я можу керувати сторонніми бібліотеками Python за допомогою Google App Engine? (virtualenv? pip?) для проблем, які виникли у Flask та Google App Engine.

— AGF
джерело

7

Дякую, @agf. Я бачив більшість цих публікацій раніше, але, думаю, мене більше цікавить особистий досвід. Я не думаю, що питання настільки широке, оскільки мене не цікавить всебічна дискусія або детальна інформація про проблему, просто вкажіть мені, що це і це буде важко або неможливо здійснити.

— Антон Мойсеєв

2

@Anton, Запит суб'єктивного особистого досвіду досить близький до керівних принципів SO, щоб не задавати питання .

— Джеймс

9

@James - Не погоджуюсь. Я не питаю вас про ваші здогадки, припущення чи суб’єктивні почуття. Я запитую про ваш досвід, тобто про факти, які ви впевнено знаєте. Не застарілі посади, ані проблеми, з якими стикалися інші люди під час важкого налаштування, просто факти. Не погоджуйтесь - добре, просто позначте це.

— Антон Мойсеєв

3

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

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

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

— кіт
джерело

це все, підтримка OOP перемогла мене. Я спочатку використовую web.py, але, схоже, webapp2 має чітку структуру без вирішення, що я робив на web.py. колбу може легко запустити, але вам потрібно більше, ніж якщо ви плануєте робити більші програми

— Ахмад Музаккі

2

Я думаю, що двигун додатків google офіційно підтримує фреймворк. Тут є зразок коду та підручник -> https://console.developers.google.com/start/appengine?_ga=1.36257892.596387946.1427891855

— Ануп
джерело

для мене це не офіційна підтримка, це лише приклад "ти можеш це зробити і з колбою". Для webapp2 є ще докладний посібник із специфічними для GAE пунктами, доданими тут і там.

— silpol

2

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

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

— Ніклас Р.
джерело