Комментарии 35
Интересно. Но у меня пока ровно один вопрос что может побудить выбрать Bottle при наличии Flask?
+6
Из того что видел, flask брали, когда надо уже именно web-приложение, а bottle когда есть питоновская программа (т.е. по сути desktop сервис какой-то), а для нее делали API.
0
На главной странице ботла написано «Bottle: Python Web Framework». В вашем примере это тоже веб приложение.
0
Не вижу противоречия, однако, уточню.
Если пишем web-app с javascript, css, шаблонами, то здесь flask, а если только web API к сервису, который живет в вечном loop'e, то зачем тащить flask.
По-моему опыту, в flask удобней сделаны все эти frontend вещи, в bottle они как-то каким-то магическими взмахами делаются. Однако, как раз все в одном файле (для bottle), позволяет его пихать в проекты, где используется чистый python и не беспокоится о версиях библиотек. Во flask такой свободы не ощущается.
Резюмируя, для прототипов, а также не требующих web gui приложений, bottle смотрится более удачным решением, чем flask.
Хотя выбор между микрофреймворками, это как выбор между зеленым и красным, т.е. сути не меняется, сиравно там нет никакой асинхронности.
Если пишем web-app с javascript, css, шаблонами, то здесь flask, а если только web API к сервису, который живет в вечном loop'e, то зачем тащить flask.
По-моему опыту, в flask удобней сделаны все эти frontend вещи, в bottle они как-то каким-то магическими взмахами делаются. Однако, как раз все в одном файле (для bottle), позволяет его пихать в проекты, где используется чистый python и не беспокоится о версиях библиотек. Во flask такой свободы не ощущается.
Резюмируя, для прототипов, а также не требующих web gui приложений, bottle смотрится более удачным решением, чем flask.
Хотя выбор между микрофреймворками, это как выбор между зеленым и красным, т.е. сути не меняется, сиравно там нет никакой асинхронности.
0
сиравно там нет никакой асинхронности
После знакомства с Tornado полностью перестал смотреть и щупать Bottle, Web.py, Flask…
0
Не для всех целей tornado, особенно если учитывать деньги-время + действительно необходимость заюзать торнадо.
0
Не для всех целей tornado
Но для большинства. В целом все основные фичи там есть, и даже шаблонизатор из коробки, а тот же Mako в 2 строчки подключается.
деньги-время + действительно
очень экономно если реализуются REST подобные JSON интерфейсы. Тут просто нету различий среди этих фреймворков.
На самом деле главное отличие это наличие ORM в Flask ну и возможность её подключить в других. Но в последнее время понял, что кроме парочки моментов, ORM нафиг не нужна и только создаёт проблемы, и при этом жрёт ресурсы. :(
Я к слову научился использовать шаблонизатор Tornado для формирования SQL, что решило множество проблем.
0
Для ваших задач Celery + Bottle/Flask/Django-Rest-Framework никак не подходили?
На Tornado в свое время смотрели и тогда, если честно, он немного сломал мозг.
Есть какие-нибудь статьи на тему написания каких-то небольших web-вещей, которые обычно делают на Flask?
> ORM в Flask
Точно есть? В flask.pocoo.org/docs/0.10/foreword/ указано, что database abstraction layer отсутствует.
На Tornado в свое время смотрели и тогда, если честно, он немного сломал мозг.
Есть какие-нибудь статьи на тему написания каких-то небольших web-вещей, которые обычно делают на Flask?
> ORM в Flask
Точно есть? В flask.pocoo.org/docs/0.10/foreword/ указано, что database abstraction layer отсутствует.
0
Я работал с одним человеком, он был фанат торнадо. Проекты были разные, так что я знаком с торнадо поверхностно, по его проекту. Когда я открыл этот проект то ужаснулся на сколько код на торнадо не читаемый и запутанный. Например, в том же твистед можно писать асинк не колбэками, а линейно и повесив декоратор на функцию inlinecallback, в торнадо же я всегда видел код с колбэками.
Шаблонизатор для API не нужен.
Sqlalchemy подключается и к flask и к bottle через готовые плагины, либо без.
По поводу необходимости ORM в свое время тоже пытался понять, хорошо или плохо. Не без помощи мыслей других пришел к тому, что ORM это хорошо, скорость разработки, читабельнее код и т.п., но до тех пор, пока ORM не станет причиной падения производительности, тогда можно по частям переписать просто медленные участки на прямые sql запросы. имхо
Шаблонизатор для API не нужен.
Sqlalchemy подключается и к flask и к bottle через готовые плагины, либо без.
По поводу необходимости ORM в свое время тоже пытался понять, хорошо или плохо. Не без помощи мыслей других пришел к тому, что ORM это хорошо, скорость разработки, читабельнее код и т.п., но до тех пор, пока ORM не станет причиной падения производительности, тогда можно по частям переписать просто медленные участки на прямые sql запросы. имхо
0
У вас устаревшее представление о Tornado. Уже давно (вроде с 3 версии, а сейчас 4 актуальная) всё пишется на корутинах и никаких callback функций.
@gen.coroutine
def get(self):
user_id = yield self.auth(False)
0
А каково вообще преимущество Tornado для API-oriented сервисов? Скорость?
Если учесть, что тяжелые задачи во Flask/… уносятся к бэкграунд с помощью Celery (что может быть и лучше чем плодить треды).
Если учесть, что тяжелые задачи во Flask/… уносятся к бэкграунд с помощью Celery (что может быть и лучше чем плодить треды).
0
1. Скорость. (но это субъективно, надо понимать конкретную задачу)
2. Потребление RAM за счёт асинхронности не создаются ни треды ни процессы.
3. WebSockets из коробки. Если у вас в API есть длинные запросы к сторонним API, за счёт асинхронных клиентов процесс не простаивает.
4. Куда меньше проблем с длинными запросами клиентов. На обычный сервер можно поставить nginx перед вашим backend и специально настроить но в том же Heroku у вас нету такой возможности. У меня есть негативный опыт с RoR в этом плане.
5. Пресловутая проблема 10к коннектов.
6. Tornado самый развитый асинхронный фреймворк. Дело в том, что от самого сервера мало толку, нужны ещё либы которые позволяют коннектить к различным БД и системам. Так вот, библиотеки которые поддерживают торндаовский event-loop больше всех. Возможно скоро придёт унификация с async-io (торнадо его тоже поддерживает), но пока это так (да и на python3 пока ещё не все пересели).
Простите, что так сумбурно.
2. Потребление RAM за счёт асинхронности не создаются ни треды ни процессы.
3. WebSockets из коробки. Если у вас в API есть длинные запросы к сторонним API, за счёт асинхронных клиентов процесс не простаивает.
4. Куда меньше проблем с длинными запросами клиентов. На обычный сервер можно поставить nginx перед вашим backend и специально настроить но в том же Heroku у вас нету такой возможности. У меня есть негативный опыт с RoR в этом плане.
5. Пресловутая проблема 10к коннектов.
6. Tornado самый развитый асинхронный фреймворк. Дело в том, что от самого сервера мало толку, нужны ещё либы которые позволяют коннектить к различным БД и системам. Так вот, библиотеки которые поддерживают торндаовский event-loop больше всех. Возможно скоро придёт унификация с async-io (торнадо его тоже поддерживает), но пока это так (да и на python3 пока ещё не все пересели).
Простите, что так сумбурно.
0
Тот же nginx push module не решает проблемы 10к и длинных клиентов просто работая с не tornado?
0
«Nginx Push Stream» это немного о другом технология. Как я говорил выше, проблему длинных коннектов в nginx можно решить просто поставив кеш для backend (backend отдаёт всё в кеш nginx и работает дальше, а за доставку клиенту отвечает nginx). Но у вас не всегда есть nginx да и как правило всё упирается не в это.
Проблема 10к это в первую очередь о том, что обслуживать потоки/процессы дорого. И никто не отменял длинных запросов внутри вашего кода (на тот же S3).
Проблема 10к это в первую очередь о том, что обслуживать потоки/процессы дорого. И никто не отменял длинных запросов внутри вашего кода (на тот же S3).
0
он состоит из одного файла — его можно целиком затащить в проект для ради простоты, не нужно никаких зависимостей.
+1
Судя по всему — это производительность. Сами для написания API выбрали Falcon (из-за скорости) и у них как раз есть страница с бенчмарками — falconframework.org/#Metrics. Насколько это правда — это уж не знаю. Сами не гоняли.
Сами видите где там Flask, а где Bottle. Bottle не сильно проседает относительно Falcon, но более удобен.
И если не ошибаюсь у Flask-а нет такого типа плагинов, как в статье описывается.
Сами видите где там Flask, а где Bottle. Bottle не сильно проседает относительно Falcon, но более удобен.
И если не ошибаюсь у Flask-а нет такого типа плагинов, как в статье описывается.
+2
Бенчмарки хелоу вордлов не показательны. Я вполне могу поверить в эти цифры, но тут меряется не то что следует мерять. Задержки в реальном проекте будут не в интерфейсе между веб сервеом и приложением, а в внутри контроллера приложения, где будет какая-то логика для проекта — например обращние к БД. С учетом этого переписывание проекта с Django на Flask или c Flask на Falcon, не даст хоть сколько нибудь заметного выигрыша в производительности. Сорее всего будет разница до 5-10%. Причем разница будет больше чем больше будет rps, а чем больше в нашем проекте rps, тем меньше нас волнует производительность. Если вас действительно волнует производительность, то для веб проекта в общем случае скорее нужен асинхронный фреймоврк, например Tornado.
Да и вообще это все не показательно. Выбирая микрофреймворки из соображений «производительности» это очевидная преждевременная оптимизациия. Более того, это оптимизация не того, что следует оптимизировать, это не узкое место. Если у вас такой кроутой сайт, что вам пришлось столкнуться с большой нагрузкой, то вы можете выжать сколько угодно rps на любом фреймворке, главное правильно построить архитектуру. А если у вас такой проект, то скорость разработки скорее всего важнее, чем затраты на покупку пары лишних серверов и мучения с отсутствием нужных библиотек в микрофреймворках.
Да и вообще это все не показательно. Выбирая микрофреймворки из соображений «производительности» это очевидная преждевременная оптимизациия. Более того, это оптимизация не того, что следует оптимизировать, это не узкое место. Если у вас такой кроутой сайт, что вам пришлось столкнуться с большой нагрузкой, то вы можете выжать сколько угодно rps на любом фреймворке, главное правильно построить архитектуру. А если у вас такой проект, то скорость разработки скорее всего важнее, чем затраты на покупку пары лишних серверов и мучения с отсутствием нужных библиотек в микрофреймворках.
0
Оставлю ссылку:
bottlepy.org/docs/dev/async.html
Glueon не говорил про переписывать.
bottlepy.org/docs/dev/async.html
С учетом этого переписывание проекта с Django на Flask или c Flask на Falcon, не даст хоть сколько нибудь заметного выигрыша в производительности.
Glueon не говорил про переписывать.
0
Glueon не говорил про переписывать.
Можно заменить слово «переписывать» на «выбирать».
0
Просто когда-то это был первый опыт и надо было выбрать что-нибудь. Когда выбираешь в первый раз Falcon/Flask/Bottle/Django для тех целей что он был нужен (небольшой бэкенд для API) выглядят ну уж очень похоже. Концептуальной разницы фактически нет, особенно если в Django использовать только FBV.
Поэтому да, выбрали ткнув пальцем — по бенчмаркам. Но пока, к сожалению, так и не пригодились те скорости, что там заявлены
Поэтому да, выбрали ткнув пальцем — по бенчмаркам. Но пока, к сожалению, так и не пригодились те скорости, что там заявлены
0
Хм… интересно. Вроде бы Werkzeug тупой как пять копеек почему такая разница. Хочется на методику посмотреть. Что там тормозит роутинг или разбор окружения.
0
Дак там все описано
Scenario. The benchmark acts as a WSGI server and performs a GET request directly on each framework's app. Each app parses a route template with a single embedded parameter, reads a query parameter and a header from the request data, sets an x-header on the response, and finally returns a 10 KiB plain-text body, randomly generated.
0
Без кода не считается.
0
Считается. github.com/racker/falcon/tree/master/falcon/bench придраться не к чему.
0
Ну, например, вот статья Андрея Светлова, почему он не любит flask: asvetlov.blogspot.com/2014/10/flask_20.html
Ну и про боттле. Меньше кода — меньше ошибок — побыстрее — легко разобраться внутри да и поправить если надо без труда. Предоставляет минимальные фичи вроде роутов, пробросов переменных, подключение плагинов. Для апи самое то, ничего лишнего, никаких шаблонизаторов и т.п.
Ну и про боттле. Меньше кода — меньше ошибок — побыстрее — легко разобраться внутри да и поправить если надо без труда. Предоставляет минимальные фичи вроде роутов, пробросов переменных, подключение плагинов. Для апи самое то, ничего лишнего, никаких шаблонизаторов и т.п.
+2
Спасибо за статью. На заметку: в последнем примере еще более красивым решением, как мне кажтеся, было бы использование вот этой штуки для валидации принимаемых данных.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Bottle и плагины