Comments 35
Интересно. Но у меня пока ровно один вопрос что может побудить выбрать Bottle при наличии Flask?
Из того что видел, flask брали, когда надо уже именно web-приложение, а bottle когда есть питоновская программа (т.е. по сути desktop сервис какой-то), а для нее делали API.
На главной странице ботла написано «Bottle: Python Web Framework». В вашем примере это тоже веб приложение.
Не вижу противоречия, однако, уточню.
Если пишем 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.
Хотя выбор между микрофреймворками, это как выбор между зеленым и красным, т.е. сути не меняется, сиравно там нет никакой асинхронности.
сиравно там нет никакой асинхронности
После знакомства с Tornado полностью перестал смотреть и щупать Bottle, Web.py, Flask…
Не для всех целей tornado, особенно если учитывать деньги-время + действительно необходимость заюзать торнадо.
Не для всех целей tornado
Но для большинства. В целом все основные фичи там есть, и даже шаблонизатор из коробки, а тот же Mako в 2 строчки подключается.
деньги-время + действительно
очень экономно если реализуются REST подобные JSON интерфейсы. Тут просто нету различий среди этих фреймворков.
На самом деле главное отличие это наличие ORM в Flask ну и возможность её подключить в других. Но в последнее время понял, что кроме парочки моментов, ORM нафиг не нужна и только создаёт проблемы, и при этом жрёт ресурсы. :(
Я к слову научился использовать шаблонизатор Tornado для формирования SQL, что решило множество проблем.
Для ваших задач 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 отсутствует.
Я работал с одним человеком, он был фанат торнадо. Проекты были разные, так что я знаком с торнадо поверхностно, по его проекту. Когда я открыл этот проект то ужаснулся на сколько код на торнадо не читаемый и запутанный. Например, в том же твистед можно писать асинк не колбэками, а линейно и повесив декоратор на функцию inlinecallback, в торнадо же я всегда видел код с колбэками.
Шаблонизатор для API не нужен.
Sqlalchemy подключается и к flask и к bottle через готовые плагины, либо без.
По поводу необходимости ORM в свое время тоже пытался понять, хорошо или плохо. Не без помощи мыслей других пришел к тому, что ORM это хорошо, скорость разработки, читабельнее код и т.п., но до тех пор, пока ORM не станет причиной падения производительности, тогда можно по частям переписать просто медленные участки на прямые sql запросы. имхо
Шаблонизатор для API не нужен.
Sqlalchemy подключается и к flask и к bottle через готовые плагины, либо без.
По поводу необходимости ORM в свое время тоже пытался понять, хорошо или плохо. Не без помощи мыслей других пришел к тому, что ORM это хорошо, скорость разработки, читабельнее код и т.п., но до тех пор, пока ORM не станет причиной падения производительности, тогда можно по частям переписать просто медленные участки на прямые sql запросы. имхо
У вас устаревшее представление о Tornado. Уже давно (вроде с 3 версии, а сейчас 4 актуальная) всё пишется на корутинах и никаких callback функций.
@gen.coroutine
def get(self):
user_id = yield self.auth(False)
А каково вообще преимущество Tornado для API-oriented сервисов? Скорость?
Если учесть, что тяжелые задачи во Flask/… уносятся к бэкграунд с помощью Celery (что может быть и лучше чем плодить треды).
Если учесть, что тяжелые задачи во Flask/… уносятся к бэкграунд с помощью Celery (что может быть и лучше чем плодить треды).
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 пока ещё не все пересели).
Простите, что так сумбурно.
Тот же nginx push module не решает проблемы 10к и длинных клиентов просто работая с не tornado?
«Nginx Push Stream» это немного о другом технология. Как я говорил выше, проблему длинных коннектов в nginx можно решить просто поставив кеш для backend (backend отдаёт всё в кеш nginx и работает дальше, а за доставку клиенту отвечает nginx). Но у вас не всегда есть nginx да и как правило всё упирается не в это.
Проблема 10к это в первую очередь о том, что обслуживать потоки/процессы дорого. И никто не отменял длинных запросов внутри вашего кода (на тот же S3).
Проблема 10к это в первую очередь о том, что обслуживать потоки/процессы дорого. И никто не отменял длинных запросов внутри вашего кода (на тот же S3).
он состоит из одного файла — его можно целиком затащить в проект для ради простоты, не нужно никаких зависимостей.
Судя по всему — это производительность. Сами для написания API выбрали Falcon (из-за скорости) и у них как раз есть страница с бенчмарками — falconframework.org/#Metrics. Насколько это правда — это уж не знаю. Сами не гоняли.
Сами видите где там Flask, а где Bottle. Bottle не сильно проседает относительно Falcon, но более удобен.
И если не ошибаюсь у Flask-а нет такого типа плагинов, как в статье описывается.
Сами видите где там Flask, а где Bottle. Bottle не сильно проседает относительно Falcon, но более удобен.
И если не ошибаюсь у Flask-а нет такого типа плагинов, как в статье описывается.
Бенчмарки хелоу вордлов не показательны. Я вполне могу поверить в эти цифры, но тут меряется не то что следует мерять. Задержки в реальном проекте будут не в интерфейсе между веб сервеом и приложением, а в внутри контроллера приложения, где будет какая-то логика для проекта — например обращние к БД. С учетом этого переписывание проекта с Django на Flask или c Flask на Falcon, не даст хоть сколько нибудь заметного выигрыша в производительности. Сорее всего будет разница до 5-10%. Причем разница будет больше чем больше будет rps, а чем больше в нашем проекте rps, тем меньше нас волнует производительность. Если вас действительно волнует производительность, то для веб проекта в общем случае скорее нужен асинхронный фреймоврк, например Tornado.
Да и вообще это все не показательно. Выбирая микрофреймворки из соображений «производительности» это очевидная преждевременная оптимизациия. Более того, это оптимизация не того, что следует оптимизировать, это не узкое место. Если у вас такой кроутой сайт, что вам пришлось столкнуться с большой нагрузкой, то вы можете выжать сколько угодно rps на любом фреймворке, главное правильно построить архитектуру. А если у вас такой проект, то скорость разработки скорее всего важнее, чем затраты на покупку пары лишних серверов и мучения с отсутствием нужных библиотек в микрофреймворках.
Да и вообще это все не показательно. Выбирая микрофреймворки из соображений «производительности» это очевидная преждевременная оптимизациия. Более того, это оптимизация не того, что следует оптимизировать, это не узкое место. Если у вас такой кроутой сайт, что вам пришлось столкнуться с большой нагрузкой, то вы можете выжать сколько угодно rps на любом фреймворке, главное правильно построить архитектуру. А если у вас такой проект, то скорость разработки скорее всего важнее, чем затраты на покупку пары лишних серверов и мучения с отсутствием нужных библиотек в микрофреймворках.
Оставлю ссылку:
bottlepy.org/docs/dev/async.html
Glueon не говорил про переписывать.
bottlepy.org/docs/dev/async.html
С учетом этого переписывание проекта с Django на Flask или c Flask на Falcon, не даст хоть сколько нибудь заметного выигрыша в производительности.
Glueon не говорил про переписывать.
Glueon не говорил про переписывать.
Можно заменить слово «переписывать» на «выбирать».
Просто когда-то это был первый опыт и надо было выбрать что-нибудь. Когда выбираешь в первый раз Falcon/Flask/Bottle/Django для тех целей что он был нужен (небольшой бэкенд для API) выглядят ну уж очень похоже. Концептуальной разницы фактически нет, особенно если в Django использовать только FBV.
Поэтому да, выбрали ткнув пальцем — по бенчмаркам. Но пока, к сожалению, так и не пригодились те скорости, что там заявлены
Поэтому да, выбрали ткнув пальцем — по бенчмаркам. Но пока, к сожалению, так и не пригодились те скорости, что там заявлены
Хм… интересно. Вроде бы Werkzeug тупой как пять копеек почему такая разница. Хочется на методику посмотреть. Что там тормозит роутинг или разбор окружения.
Дак там все описано
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.
Без кода не считается.
Считается. github.com/racker/falcon/tree/master/falcon/bench придраться не к чему.
Ну, например, вот статья Андрея Светлова, почему он не любит flask: asvetlov.blogspot.com/2014/10/flask_20.html
Ну и про боттле. Меньше кода — меньше ошибок — побыстрее — легко разобраться внутри да и поправить если надо без труда. Предоставляет минимальные фичи вроде роутов, пробросов переменных, подключение плагинов. Для апи самое то, ничего лишнего, никаких шаблонизаторов и т.п.
Ну и про боттле. Меньше кода — меньше ошибок — побыстрее — легко разобраться внутри да и поправить если надо без труда. Предоставляет минимальные фичи вроде роутов, пробросов переменных, подключение плагинов. Для апи самое то, ничего лишнего, никаких шаблонизаторов и т.п.
Спасибо за статью. На заметку: в последнем примере еще более красивым решением, как мне кажтеся, было бы использование вот этой штуки для валидации принимаемых данных.
Sign up to leave a comment.
Bottle и плагины