Comments 13
Спасибо. Как раз искал что-то подобное. Наверняка и с tastypie будет работать.
Несколько заметок по теме:
1) Из моего опыта фреймворки типа Django-rest-framework или Tastypie очень хорошо для быстрого создания простых прототипов. Так сказать, для создания REST JSON интерфейсов для моделей. Но когда приходится делать более навороченные вещи проще отказаться от него и делать все самому.
2) Фейсбук говорит обратное www.facebook.com/note.php?note_id=389414033919. Они, для того чтобы увеличить скорость работы вебсайта, наоборот начали рендерить HTML на сервере и отдавать клиенту уже готовый HTML.
3) Джанго не асинхронный фреймворк. Это значит законнектившись по вебсокету мы блокируем его пока клиент не сделает дисконнект. А это значит что много клиентов не законнектится. Как вы с этим боретесь?
В примере используется Tornado неспроста. Это и есть асинхронный Python фреймворк.
1) Из моего опыта фреймворки типа Django-rest-framework или Tastypie очень хорошо для быстрого создания простых прототипов. Так сказать, для создания REST JSON интерфейсов для моделей. Но когда приходится делать более навороченные вещи проще отказаться от него и делать все самому.
2) Фейсбук говорит обратное www.facebook.com/note.php?note_id=389414033919. Они, для того чтобы увеличить скорость работы вебсайта, наоборот начали рендерить HTML на сервере и отдавать клиенту уже готовый HTML.
3) Джанго не асинхронный фреймворк. Это значит законнектившись по вебсокету мы блокируем его пока клиент не сделает дисконнект. А это значит что много клиентов не законнектится. Как вы с этим боретесь?
В примере используется Tornado неспроста. Это и есть асинхронный Python фреймворк.
По поводу пункта 3. Если я верно понял, от Django используется только механизм request-response. Т.е. в Django обычным образом написаны контроллеры, а с помощью django-websocket-request можно их вызывать, не внося изменений, со стороны асинхронного сервера, который уже и будет работать с вебсокетами, как в примере.
На гитхабе это понятнее описано: github.com/GetBlimp/django-websocket-request/blob/master/README.md
На гитхабе это понятнее описано: github.com/GetBlimp/django-websocket-request/blob/master/README.md
То есть мы получаем HTTP over WebSockets? Зачем это нужно?
Т.е. WebSocket соединение работает с каким-то сервером который находится между браузером и Django? В чем смысл тогда? В примере добавляется Tornado поверх Django.
Кроме того, это получается общение только в одну сторону Клиент->Сервер (если сервером считаем Django) который может быть достигнут обычными AJAX запросами. Весь сок WebSockets в двусторонней асинхронной коммуникации и самое важное из этого что сервер может послать данные в браузер без необходимых действий со стороны браузера (кроме того чтобы быть законнекченным).
Кроме того, это получается общение только в одну сторону Клиент->Сервер (если сервером считаем Django) который может быть достигнут обычными AJAX запросами. Весь сок WebSockets в двусторонней асинхронной коммуникации и самое важное из этого что сервер может послать данные в браузер без необходимых действий со стороны браузера (кроме того чтобы быть законнекченным).
Нет, не совсем так. Как тут выше уже написали, получаем просто HTTP over WebSockets. Серверов не добавляется, просто указанное приложение передает пришедший по сокетам запрос на обработку в соответствующий контроллер в Django, получает ответ и отправляет его по сокету назад.
Сервер тут действительно не может сам что-то послать клиенту, но ведь никто не запрещает дописать только нужную функциональность отдельно. В результате вы и избавляетесь от отдельных ajax-запросов, просто обращаясь к серверу по постоянному каналу и сохраняя при этом всю реализацию API в единственном варианте, и можете использовать все плюсы вебсокетов.
Сервер тут действительно не может сам что-то послать клиенту, но ведь никто не запрещает дописать только нужную функциональность отдельно. В результате вы и избавляетесь от отдельных ajax-запросов, просто обращаясь к серверу по постоянному каналу и сохраняя при этом всю реализацию API в единственном варианте, и можете использовать все плюсы вебсокетов.
Делал достаточно внушительный (хотя, возможно, у вас проекты сильно больше) биллинг для виртуального сотового оператора на базе django и tastypie (front — extjs). Не всё было гладко и с тестированием тоже, но задачи решались, чуть больше сотни тысяч абонентов вполне себе обслуживались. Так что про простые прототипы что-то вы загнули.
В статье указана крайне узкая область использования вебсокетов. Под заголовком хотелось увидеть, всё-таки, смену парадигмы и инструментов, на те что предлагают вебсокеты (statefull, server-push, binary frames и т.д.). А видим просто транспортное решение. Если хочется сделать простейший чат, то всё равно будет пулинг и экономия только трафика на http-заголовках. И руки вновь тянутся к чему-то, где можно использовать вебсокеты полноценно.
Но заголовок всё равно правильный. Там просто ключевое слово — «простейший». Так как, полноценно, пока не ясно, как вообще можно работать с вебсокетными соединениями в python. И развития не видать. Появился asyncio(tulip), но он только про event loop и асинхронное IO, чем уже давно не удивишь. Не понятно, как выделять соединения в сущности и работать с ними — подписывать, пушить сообщения и делать это не блокируясь внутри сопрограммы (на yield from).
Но заголовок всё равно правильный. Там просто ключевое слово — «простейший». Так как, полноценно, пока не ясно, как вообще можно работать с вебсокетными соединениями в python. И развития не видать. Появился asyncio(tulip), но он только про event loop и асинхронное IO, чем уже давно не удивишь. Не понятно, как выделять соединения в сущности и работать с ними — подписывать, пушить сообщения и делать это не блокируясь внутри сопрограммы (на yield from).
Какой-то бессмысленный проект. Заменили один транспортный уровень на другой, да ещё и с потерей части функциональности (Middleware, gzip) и не получили никаких преимуществ (пушить события с сервера не позволяет). Хоть одна объективная причина для этого была?
Забавно, что весь проект по сути один файлик на 100 строк.
Забавно, что весь проект по сути один файлик на 100 строк.
Sign up to leave a comment.
Простейший способ добавить WebSocket в Django