Что можно сделать на Tornado?

Question

[Tark]

Здравствуйте, уважаемые люди сообщества!

Я умею и могу в Pyramid и Flask. С некоторых пор захотелось изучить что-нибудь новое и я решил узнать про фреймворк Tornado.

Интересует вопрос: для каких задач лучше всего подойдёт именно он? Чаще всего вижу примеры задач, где с помощью Tornado пишут чат на веб-сокетах... но ведь этот фреймворк используется не только для написания чатов, правда? Правда же? Говорят, писать веб-приложения с использованием шаблонизаторов - то есть "обычные сайты" - на Торнадо расточительно: он может и умеет, но это лучше сделать на других фреймворках, которые лучше предназначены именно для этих целей, таких как Pyramid, Flask. Django etc. А есть ли задачи, глядя на которые тим-лид скажет, что вот тут лучше всего подойдёт именно Tornado?

Или, что ещё лучше, может быть у вас завалялись тестовые задачи при устройстве на работу, где пишут сервисы на Tornado и которые вам не жалко открыть? Буду благодарен за любые задания!

Answer 1

[bobrovskyserg]

Посмотрите вот это, прежде чем хвататься за Торнадо.

Comments

[Tark]

Спасибо! Похоже, пора плотно переходить на Python 3. Уж больно простым становится асинхронное программирование с aiohttp...

[Алексей Черемисин]

А еще на twisted гляньте, там и 2.7 еще в теме.

[bobrovskyserg]

Tark:
Поставьте ответ решением.
Средства языка здорово выросли, и надо продвигать их, а не ~censored~ антикварное (я про твистед).

Answer 2

[Andrey K]

На tornado можно сделать все что угодно, вопрос в целесообразности. Но больше всего он подходит для задач с большим количеством http-запросов. Напишите например агрегатор ленты нескольких соц. сетей и/или rss.

Comments

[Tark]

Что на Tornado можно сделать что угодно, это понятно. Более того, почти на всём можно сделать почти всё. Используется, если нужно обработать большое количество HTTP-запросов? Но если посмотреть на (довольно старое и крайне сомнительное) сравнение, то торнадо ничем особенным не выделяется. И "длительная обработка запроса (например, по причине взаимодействия с сервером баз данных), сводит преимущества Торнадо на нет" (с) википедия.

Тем не менее, в правой части этого сайта иногда пишут вакансии Python-программистов и там иногда требуется знание Tornado. Что же это? Неужели просто наследие? Или всё-таки есть какие-то задачи, где лучше всего подойдёт именно этот фреймворк?

Вопрос-то состоит в том, для чего Tornado был написан помимо "фатального недостатка". Это не значит, что мне нечем себя занять и я прошу дать мне какую-то задачу, чтобы я познакомился с этим фреймворком - уж с этим-то я и сам справлюсь :)

[Алексей Черемисин]

Это кто же сказал, что торнадо и "длительная обработка запроса" как-то связаны?! Просто их, запросы к базе, делайте асинхронно. Хотя на чистом торнадо может быть так и есть, я всё больше за cyclone (клон торнадо) + twisted.

Answer 3

[Алексей Черемисин]

Для чего я использую tornado, точнее cyclone.io, порт tornado под twisted.

- для системы miidleware ТВ-приставок. Приставка лезет за страничкой к серверу, а в остальное время общается с ним по json/REST/comet. Админка статистики этого дела работает на отдельном порту и содержит 10 страниц + json/comet/rest.
- для системы доступа к кластеру с тонких клиентов, сервер отдает данные в json о доступных точках входа на сервера кластера и запоминает выбор пользователя. Всего 30 строк кода, Карл :-) С одной стороны сервер подключается в influxdb, с другой отдает данные пользователям.
- для админок к разным устройствам
- для вещей, когда просто нужен вебсервер и шаблоны, и не нужна база данных, ORM, и куча лишнего говна.
- для вещей, когда web-интерфейс как небольшая часть остального функционала
- для web, когда нужно быстро туда-сюда прогнать данные.

Если посмотреть на отличия с django, то django умеют делать отличный фреймворк для web, а торнадо - отличный фреймворк для http!

Дополнил

А чего далеко ходить. Простая конфигурилка для линукса, интерфейсы, логин/пароль, просмотр и конфигурилка запущенных служб. Раньше я это делал на webmin, теперь cyclon + angularjs.

А вот.. вот делаю дизайн html для битрикс (уж простите...). Как-то нужно смотреть html/css + картинки + javascript, причем, все с путями реального сайта - 10 минут и у меня всё готово. Ну не апач с nginx для этого разворачивать же?

Ну и как-то была задача типа чата (для удаленных устройств), когда нужно было обеспечить около 10к подключений. Без танцев с бубном и минимум кода.

В общем везде, где просто нужен быстрый и простой web-сервер с моторчиком из питона. Раньше я для этого использовал jetty (java) с моторчиком на яве соответственно. На питоне это проще в два/три раза только из-за того, что можно по ssh зайти и тупо поправить в коде без компиляции (maven) и среды разработки (eclipse).

Comments

[Tark]

Спасибо! А можно ещё парочку примеров насчёт "вещей, когда просто нужен вебсервер и шаблоны"?..

[Tark]

Спасибо :) Кажется, что вам просто нравится Tornado (исключая последний пример, когда действительно может пригодиться). Мне пришло в голову возможное применение торнадо для хранения и обработки состояний чего-нибудь типа игроков в онлайн-игре или, я не знаю, месторасположения таксистов и пассажиров для показа всего этого на сайте/приложении. Но стоит ли тогда целенаправленно изучать этот фреймворк или правда стоит перейти на третий питон и врубиться в asyncio/aiohttp?

[Алексей Черемисин]

Дополнил.

[Алексей Черемисин]

Tark: О!!! Как раз для этого (хранение и обработка в играх) очень часто его пользуют. Ну и конечно мне нравится - 5 строк кода и у вас готовый сервер с батарейкой, + 10 строк кода и уже готовое приложение!

[Алексей Черемисин]

На счет того, нужен или нет торнадо, он простой как две копейки, за неделю освоите полностью. А на aiohttp я сейчас и сам гляну. Про торнадо уже сказал, быстрота и простота рулит у него.

[Алексей Черемисин]

Ну что, досмотрел про aiohttp, очень неплохо! Понравилось сравнение с торнадо, и что они не будут делать мегамонстра. Вообще очень, на первый взгляд, вкусно. буду пробовать. Комментарии порадовали.

Answer 4

[Tark]

Посмотрел на aiohttp, осталось странное такое впечатление.

Начнём с того, что асинхронный aiohttp в 2-5 раз медленнее синхронных топов на самой простой задаче - вернуть JSON. Окей, в реальной жизни засчёт однопоточности и ненужности кеш-серверов скорость сгладится.

Второе. Андрей Светлов говорил: "смотрите, у нас есть джынжа со с макой! Можно уже писать приложения!". Да.
aiohttp_jinja2 не проверяет в декораторе значение, которое ей передаётся. Вернули не словарь? Нате пятихатку!
Почему бы не проверять? Почему в шаблон не передаётся request по умолчанию, почему мне нужно будет вписывать его самостоятельно? Если бы мне хотелось многословия, я бы Django использовал.

Третье, про aiohttp.web. В pyramid, к примеру, есть чёткое разделение между роутом и вью-функцией, где роут - это URL с именем, а во вьюшке можно определить обработчик роута в зависимости от HTTP-метода и прочего. В результате можно строить URL в шаблоне, указывая имя роута и необходимые параметры; очень удобно. В отличие от pyramid, в aiohttp есть понятие роута, где сразу же указывается HTTP-метод, URL и обработчик. Что самое злое, метод тут - ТОЛЬКО СТРОКА. Не список/множество возможных методов типа method=('GET', 'POST'), а только строка. В результате необходимо придумывать разные name для роута для одного и того же URL, что добавляет неудобства для их построения. И чёртово отсутствие request в шаблоне, чёрт бы его подрал. Ну не хочу я вертать взад dict(request=request, user='Tark'), я хочу без реквеста, но чтобы оно в шаблон передавалось самим aiohttp. Аргх!

Что понравилось - aioauth-client. Ужасное название пакета, но какая прелесть внтурях. Осталось чуток дописать, чтобы не приходилось делать if 'twitter' elif 'github' elif 'google', добавить роутов и можно получить нормально работающий python-social-auth-light.

Но пока что всё это слишком не доработанное. Разработка идёт гигантскими шагами, но результат пока ещё использовать тяжело.

Answer 5

[Захар Скороходов]

Мне кажется, какие-нибудь шашки или шахматы сетевые будут неплохим вариантом. Ну, и присоединюсь к замечанию про asyncio.

Answer 6

[Mikhail]

Прежде всего для работы с websocket. Хотя как писали раньше, мелкие запросы он пропускает лучше чем pyramid. Вообще так как я использую pyramid так-же и он мне нравится, то его очень хорошо дополнять tornado для быстрого асинхронного сервера. Вот только вопрос лучше ли Торнадо работает с ORM?

Answer 7

[unclechu]

Как-то писали «обычный сайт», в общем-то если собрать однажды гибкие и расширяемые «рельсы», то вполне можно делать и обычные сайты в том числе. В приведённом примере собрана достаточно гибкая и расширяемая админ-панель, можно юзать на условиях GNU/AGPL. Правда в качестве ORM для БД я бы порекомендовал взять что-нибудь аля монгус, т.к. в данном проекте главная боль в заднице — это были миграции для SQLAlchemy.