Кстати, спасибо за core.cache. Знал бы о нем раньше — использовал бы вместо одного из атомов.
Ну и буду писать пост о серверной архитектуре Warmagnet, пока свежо.
Если кратко, у нас прикольно получилось с синхронизацией состояния игры между клиентом и сервером. Есть общий код игровой логики, который принимает «мир» и мутирует его с помощью входящих действий. Любые действия игроков отправляются на сервер, тот их проверяет, изменяет локальное состояние и рассылает эти же действия всем клиентам смотрящим игру. Те уже применяют действие к своим локальным состояниям. Ну и поскольку на сервере хранится мастер копия, то реконнект клиента очень простой — тот просто получает готовое состояние игры сразу, ну а потом инкрементальные апдейты. Вся логика мутаций мира общая на клиенте и на сервере с помощью crossover (https://github.com/emezeske/lein-cljsbuild/blob/master/doc/CROSSOVERS.md)
По сути, получилось что-то типа node.js — возможность написания общего кода между клиентом и сервером, но clojure и в функциональном стиле.
Кстати — нет. SQLAlchemy для питона считается большой и тяжеловесной. Слишком много всего умеет, слишком много абстракций, слишком конфигурируемая и «слишком» много кода.
Но, как ни странно, достаточно быстрая. Понятно что, где и как происходит + за счет архитектуры есть возможность отказаться от «тормозящих» слоев.
Вот reddit, например, ORM не использует, сделали свою обертку поверх SQLAlchemy Core (генератор SQL запросов из питоновских выражений). Ну и вообще, ее хорошо так применяют: www.sqlalchemy.org/organizations.html
Обычно питоновские библиотеки маленькие и лаконичные и SQLAlchemy это исключение (как и Django, но ему можно — он комбайн все-в-одном).
Если хочется, можно комбинировать с сырым SQL, причем на всех уровнях — хоть весь запрос на SQL, хоть куски.
DSL очень серьезный, умеет почти все. Работает правильно — в момент создания запроса можно «ответвляться». Например, сделали основной запрос, вызвали его с count(), достроили с offset().limit() и получили страницу данных.
В отличии от других ORM еще ни разу не приходилось писать сырой SQL.
2) Есть event'ы, которые можно вешать на все уровни — от «вот-вот отправим SQL запрос в БД» до «поменялось значение вот этого свойства модели»
3) Тоже есть. Включая lazy loading для связей, каскад и т.п.
4) Есть.
5) Есть.
6) Ленивая загрузка есть. Можно на уровне запроса определять как и что грузить, а можно на уровне моделей описать.
Там вообще много чего есть.
Если по теме, алхимия серьезно использует динамическую диспетчеризацию и типизацию. Например есть такой модуль sqlalchemy.func. Для простоты примера, предположим у него нет «своих» функций. Любая попытка получения аттрибута по имени из этого модуля, например sqlalchemy.func.max(Model.name) генерирует вызов функции SQL с переданными параметрами. Для примера выше 'MAX(model.name)'. Очень сильно экономит на кодо-генераторах и размере кода. Сделано оно вменяемо и не влияет на производительность.
Могу назвать две причины:
1. Накладные расходы на разбор HTTP запроса будут выше чем разбор пакета ZMQ
2. С ZMQ будет легче масштабироваться в будущем. Добавление ноды в кластер не требует написания кода вообще.
В принципе, это применимо к любой message bus (AMQP, redis pub/sub, etc).
Но HTTP API тоже можно, если не планируется какой либо серьезной нагрузки.
PythonAnywhere (облачная питоновская консоль) переехала. Одна из причин была стабильность Socket.IO, вторая — у SockJS latency меньше. blog.pythonanywhere.com/27/
Знаю несколько человек, которые долго долбили багтрекер Socket.IO (@dominiek, тоже есть в том тикете), перешли со своими проектами на SockJS.
Metor тот же (который на node.js) сначала был на socket.io, потом его выпилили и сделали SockJS.
Ну и так далее.
Переезд — смотря сколько функционала завязано на фичи самого socket.io. Если используются event'ы — прийдется их руками сделать (или найти либу, вроде кто-то делал).
Крупные ресурсы, которые хоть какую-то имеют нагрузку переезжают на альтернативные варианты.
Для «поиграться» (всякие небольшие проектики, proof-of-concept, etc) вполне себе нормально работают на Socket.IO. Там не такие нагрузки, что бы спровоцировать этот race condition.
Лучше не использовать — сервера ложатся от нагрузки из за бага указанного по ссылке выше. Этот самый серьезный, по мелочи там хватает разного.
Сейчас все ждут Socket.IO поверх Engine.IO (Engine.IO это SockJS, но от разработчиков Socket.IO) или переходят на что-то более стабильное (Faye, SockJS, etc).
Что до SockJS… В плане функциональности — это вебсокеты и ничего больше. Нет событий, нет каналов из коробки (но есть отдельный мультиплексор — https://github.com/sockjs/websocket-multiplex), нет автоматического реконнекта, нет комнат и тому подобного.
И, если честно это хорошо. Очень сложно угадать что потребуется разработчикам: как группировать клиентов, как должен работать реконнект и т.д.
Да, но если есть необходимость поддерживать старые браузеры: Socket.IO не самое лучшее решение. А идти с чистыми вебсокетами — еще хуже, IE8-9 еще популярен.
Так уж сложилось что я с ним (и SockJS) уже около двух лет вожусь и Socket.IO совершенно не радует.
Есть такая штука — SockJS. Идея проекта — дать разработчикам вебсокет-подобный объект на клиенте и он уже сам будет откатываться на поддерживаемые протоколы.
Работает сильно лучше Socket.IO, является хорошим переходным решением — когда все браузеры начнут поддерживать вебсокеты, от него можно отказаться сменой создаваемого класса.
А что до Socket.IO — он действительно очень плохой, его совершенно не поддерживают. Вот пример эпического бага, который открыт год: https://github.com/LearnBoost/socket.io/issues/438#issuecomment-10620702. Если кратко, то в клиенте есть race condition, который не могут вылечить уже год и клиент начинает DDOS'ить сервер.
А зачем в торнадо писать на callback'ах если есть tornado.gen?
Единственное что надо не забывать вызывать callback, но я вот написал себе такой вот велосипед и он отлично работает: gist.github.com/3924669
#1 — где лежит исходник
#2 — как писать
#3 — аналог с текущим gen.engine
#4 — как можно писать в python 3.3+ (return в генераторе кидает StopIteration)
Реально используется в боевом приложении. Единственный минус — надо не забывать асинхронные вызовы оборачивать в gen.Task, а то иначе не происходит вызова.
Сварга, идеологически, была очень похожа на Flask. Ну или наоборот, Flask появился на пол года позже. Те же идеи с threadlocals, та же основа — Werkzeug, Jinja2. Разница только в том, что у Сварги было много идей позаимствовано из Django и идеи эти были не самыми лучшими. Например — структура приложений, автоимпорт моделей и т.д.
Когда анонсировали Flask, стало сразу понятно что его будет использовать больше народа чисто за счет большего community pocoo. И было принято решение заморозить Сваргу и потихоньку перетаскивать наработки во Flask. Что, собственно, и происходит.
У него другая идеология — будем комбайном а-ля Django, что бы все было из коробки. Своя ORM, свои шаблоны и т.д. А в результате, для проектов больше одного файла, все равно используют сторонние библиотеки.
Грубо говоря, это попытка быть Django без ресурсов и community Django. Может оно и не так, но внешне очень похоже.
> Ээээ, а можете привести примеры?
Конечно. Там всего две зависимости: Werkzeug и Jinja2 и очень тонкая прослойка между ними.
Werkzeug умеет много всякого хорошего, например вот такой вот замечательный, интерактивный дебаггер: werkzeug.pocoo.org/docs/debug/
Jinja2, же, очень хороший шаблонизатор с синтаксисом Django. Лучше хотя бы тем, что при ошибках в шаблонах умеет показывать stacktrace и банально работает быстрее.
Если взять третью компоненту — ORM, то это скорее всего будет SQLAlchemy (некоторые еще Peewee используют, я его даже не смотрел). А алхимия сама по себе лучше ORM Django. Можно спорить о удобности и привычности синтаксиса, но как ни крутить — позволяет больше и не заставляет писать сырой SQL в относительно сложных случаях.
Тут скорее дело в том, что Django это комбайн все в одном. Разработчики распыляют свои усилия по достаточно большой кодовой базе. И в каждой своей части, Django работает хоть и не плохо, но хуже чем отдельные специализированные решения. Да, можно сказать что у Django лучше связанность компонент, но на самом деле Flask от слабой связанности не сильно страдает.
Я бы назвал такие:
1. Меньший размер, мало зависимостей, можно быстро писать приложения в одном .py файле
2. Отдельные компоненты из которых состоит Flask лучше аналогов из Django
3. Explicit is better than implicit, никаких автоимпортов и другой магии кроме threadlocals (которые Django тоже использует)
Из минусов:
1. Надо привыкнуть к чтению документации из кучи разных мест (запросы — Werkzeug, шаблоны — Jinja2, ORM скорее всего SQLAlchemy и так далее).
2. Сторонних компонент явно меньше
3. Начинающим сложнее — слишком много свободы и непонятно что делать
Ну и буду писать пост о серверной архитектуре Warmagnet, пока свежо.
Если кратко, у нас прикольно получилось с синхронизацией состояния игры между клиентом и сервером. Есть общий код игровой логики, который принимает «мир» и мутирует его с помощью входящих действий. Любые действия игроков отправляются на сервер, тот их проверяет, изменяет локальное состояние и рассылает эти же действия всем клиентам смотрящим игру. Те уже применяют действие к своим локальным состояниям. Ну и поскольку на сервере хранится мастер копия, то реконнект клиента очень простой — тот просто получает готовое состояние игры сразу, ну а потом инкрементальные апдейты. Вся логика мутаций мира общая на клиенте и на сервере с помощью crossover (https://github.com/emezeske/lein-cljsbuild/blob/master/doc/CROSSOVERS.md)
По сути, получилось что-то типа node.js — возможность написания общего кода между клиентом и сервером, но clojure и в функциональном стиле.
Но, как ни странно, достаточно быстрая. Понятно что, где и как происходит + за счет архитектуры есть возможность отказаться от «тормозящих» слоев.
Вот reddit, например, ORM не использует, сделали свою обертку поверх SQLAlchemy Core (генератор SQL запросов из питоновских выражений). Ну и вообще, ее хорошо так применяют: www.sqlalchemy.org/organizations.html
Обычно питоновские библиотеки маленькие и лаконичные и SQLAlchemy это исключение (как и Django, но ему можно — он комбайн все-в-одном).
Если кратко, то да — можно сравнивать, при этом библиотека меньше по размерам. Вот совсем небольшой feature list: www.sqlalchemy.org/features.html
Если по пунктам:
1) Запросы пишутся питоновским кодом. Что-то типа:
Если хочется, можно комбинировать с сырым SQL, причем на всех уровнях — хоть весь запрос на SQL, хоть куски.
DSL очень серьезный, умеет почти все. Работает правильно — в момент создания запроса можно «ответвляться». Например, сделали основной запрос, вызвали его с
count(), достроили сoffset().limit()и получили страницу данных.В отличии от других ORM еще ни разу не приходилось писать сырой SQL.
2) Есть event'ы, которые можно вешать на все уровни — от «вот-вот отправим SQL запрос в БД» до «поменялось значение вот этого свойства модели»
3) Тоже есть. Включая lazy loading для связей, каскад и т.п.
4) Есть.
5) Есть.
6) Ленивая загрузка есть. Можно на уровне запроса определять как и что грузить, а можно на уровне моделей описать.
Там вообще много чего есть.
Если по теме, алхимия серьезно использует динамическую диспетчеризацию и типизацию. Например есть такой модуль
sqlalchemy.func. Для простоты примера, предположим у него нет «своих» функций. Любая попытка получения аттрибута по имени из этого модуля, напримерsqlalchemy.func.max(Model.name)генерирует вызов функции SQL с переданными параметрами. Для примера выше 'MAX(model.name)'. Очень сильно экономит на кодо-генераторах и размере кода. Сделано оно вменяемо и не влияет на производительность.1. Накладные расходы на разбор HTTP запроса будут выше чем разбор пакета ZMQ
2. С ZMQ будет легче масштабироваться в будущем. Добавление ноды в кластер не требует написания кода вообще.
В принципе, это применимо к любой message bus (AMQP, redis pub/sub, etc).
Но HTTP API тоже можно, если не планируется какой либо серьезной нагрузки.
PythonAnywhere (облачная питоновская консоль) переехала. Одна из причин была стабильность Socket.IO, вторая — у SockJS latency меньше. blog.pythonanywhere.com/27/
Знаю несколько человек, которые долго долбили багтрекер Socket.IO (@dominiek, тоже есть в том тикете), перешли со своими проектами на SockJS.
Metor тот же (который на node.js) сначала был на socket.io, потом его выпилили и сделали SockJS.
Ну и так далее.
Переезд — смотря сколько функционала завязано на фичи самого socket.io. Если используются event'ы — прийдется их руками сделать (или найти либу, вроде кто-то делал).
Крупные ресурсы, которые хоть какую-то имеют нагрузку переезжают на альтернативные варианты.
Для «поиграться» (всякие небольшие проектики, proof-of-concept, etc) вполне себе нормально работают на Socket.IO. Там не такие нагрузки, что бы спровоцировать этот race condition.
Сейчас все ждут Socket.IO поверх Engine.IO (Engine.IO это SockJS, но от разработчиков Socket.IO) или переходят на что-то более стабильное (Faye, SockJS, etc).
Что до SockJS… В плане функциональности — это вебсокеты и ничего больше. Нет событий, нет каналов из коробки (но есть отдельный мультиплексор — https://github.com/sockjs/websocket-multiplex), нет автоматического реконнекта, нет комнат и тому подобного.
И, если честно это хорошо. Очень сложно угадать что потребуется разработчикам: как группировать клиентов, как должен работать реконнект и т.д.
Так уж сложилось что я с ним (и SockJS) уже около двух лет вожусь и Socket.IO совершенно не радует.
Работает сильно лучше Socket.IO, является хорошим переходным решением — когда все браузеры начнут поддерживать вебсокеты, от него можно отказаться сменой создаваемого класса.
А что до Socket.IO — он действительно очень плохой, его совершенно не поддерживают. Вот пример эпического бага, который открыт год: https://github.com/LearnBoost/socket.io/issues/438#issuecomment-10620702. Если кратко, то в клиенте есть race condition, который не могут вылечить уже год и клиент начинает DDOS'ить сервер.
А с эрлангом та же проблема — очень тяжело найти людей.
Везде приходится искать какие-то компромиссы.
Единственное что надо не забывать вызывать callback, но я вот написал себе такой вот велосипед и он отлично работает: gist.github.com/3924669
#1 — где лежит исходник
#2 — как писать
#3 — аналог с текущим gen.engine
#4 — как можно писать в python 3.3+ (return в генераторе кидает StopIteration)
Реально используется в боевом приложении. Единственный минус — надо не забывать асинхронные вызовы оборачивать в gen.Task, а то иначе не происходит вызова.
Есть сервер для эрланга, работает тоже поверх ковбоя: github.com/sockjs/sockjs-erlang
Да, можно сделать так:
А можно кинуть RequestRedirect(url) из самого is_accessible и произойдет редирект.
Сварга, идеологически, была очень похожа на Flask. Ну или наоборот, Flask появился на пол года позже. Те же идеи с threadlocals, та же основа — Werkzeug, Jinja2. Разница только в том, что у Сварги было много идей позаимствовано из Django и идеи эти были не самыми лучшими. Например — структура приложений, автоимпорт моделей и т.д.
Когда анонсировали Flask, стало сразу понятно что его будет использовать больше народа чисто за счет большего community pocoo. И было принято решение заморозить Сваргу и потихоньку перетаскивать наработки во Flask. Что, собственно, и происходит.
У него другая идеология — будем комбайном а-ля Django, что бы все было из коробки. Своя ORM, свои шаблоны и т.д. А в результате, для проектов больше одного файла, все равно используют сторонние библиотеки.
Грубо говоря, это попытка быть Django без ресурсов и community Django. Может оно и не так, но внешне очень похоже.
Конечно. Там всего две зависимости: Werkzeug и Jinja2 и очень тонкая прослойка между ними.
Werkzeug умеет много всякого хорошего, например вот такой вот замечательный, интерактивный дебаггер: werkzeug.pocoo.org/docs/debug/
Jinja2, же, очень хороший шаблонизатор с синтаксисом Django. Лучше хотя бы тем, что при ошибках в шаблонах умеет показывать stacktrace и банально работает быстрее.
Если взять третью компоненту — ORM, то это скорее всего будет SQLAlchemy (некоторые еще Peewee используют, я его даже не смотрел). А алхимия сама по себе лучше ORM Django. Можно спорить о удобности и привычности синтаксиса, но как ни крутить — позволяет больше и не заставляет писать сырой SQL в относительно сложных случаях.
Тут скорее дело в том, что Django это комбайн все в одном. Разработчики распыляют свои усилия по достаточно большой кодовой базе. И в каждой своей части, Django работает хоть и не плохо, но хуже чем отдельные специализированные решения. Да, можно сказать что у Django лучше связанность компонент, но на самом деле Flask от слабой связанности не сильно страдает.
1. Меньший размер, мало зависимостей, можно быстро писать приложения в одном .py файле
2. Отдельные компоненты из которых состоит Flask лучше аналогов из Django
3. Explicit is better than implicit, никаких автоимпортов и другой магии кроме threadlocals (которые Django тоже использует)
Из минусов:
1. Надо привыкнуть к чтению документации из кучи разных мест (запросы — Werkzeug, шаблоны — Jinja2, ORM скорее всего SQLAlchemy и так далее).
2. Сторонних компонент явно меньше
3. Начинающим сложнее — слишком много свободы и непонятно что делать
Как-то так.
Но как только PyPy подтянется, то и смысла нет.
Ах да, еще хочется гринлетов в PyPy с JIT.