@devops_ru
Alexander02.01.2017
22:47:16
22:47:16
пока channels это не часть Django, а отдельно, я не знаю, что там дальше будет с этим
Nikolay02.01.2017
22:47:38
22:47:38
так уже ж часть вроде?
GoogleAlexander02.01.2017
22:49:03
22:49:03
а почему курам на смех? они хуже, чем то, что уже есть в Django?
Nikolay02.01.2017
22:49:32
22:49:32
нет, просто джанго изначально не умело во много вещей, и их потом приделывали говном и палками
взять хоть REST
асинхронность теперь туда же
Alexander02.01.2017
22:50:13
22:50:13
а что именно там не так?
вообще, если есть прогресс относительно себя раннего - это хорошо
если Django с channels станет лучше, чем была до них - это же хорошо
Nikolay02.01.2017
22:51:13
22:51:13
я не очень знаю про channels, я на джангу давно не смотрел, но еще пару лет назад основная схема была - поднимать два сервиса независимых
джанго и торнадо рядом
GoogleNikolay02.01.2017
22:52:28
22:52:28
вроде ж уже немного научили?
Alexander02.01.2017
22:53:50
22:53:50
я не уверен до конца, но вроде как судя по вещам, озвученным о uWSGI, что чтобы сделать нормально всё - надо ломать совместимость с WSGI, чего, разумеется, uWSGI делать не будет, и добавили то, что можно добавить, не ломая реализацию WSGI
ну а Django как и другие - просто WSGI-фреймворк
то есть тут понятно, что она всегда будет более тормознутая, чем тот же aiohttp
ну, если я всё правильно понял, то вот так
поэтому все эти channels и что угодно ещё деплоится отдельными процессами от самой Django
то есть примерно те же проблемы тут будет испытывать и Flask и Pyramid, и другие WSGI-(микро)фреймворки
Nikolay02.01.2017
22:58:38
22:58:38
да, скорее всего
Alexander02.01.2017
22:58:52
22:58:52
а aiohttp изначально построен вокруг asyncio
Nikolay02.01.2017
22:59:43
22:59:43
ну да, там же внизу epoll и эвентлуп
Alexey02.01.2017
22:59:44
22:59:44
объясни, будь человеком. вот есть поднятое приложение. у меня, например, используется сворм, все запускается в контейнерах, наружу смотрит балансировщик. сворм берет на себя весь головняк и по дискавери и по перезапуску процессов. тем не менее, наружу смотрит один хапрокси, у него есть ip. если он, пардон за мат, пизданется, то похер на всю эту балансировку, приложение из вне не будет доступно. можно поднять еще один балансировщик, но тогда надо обеспечить ХА на уровне ДНС. в каком моменте своих рассуждений я допускаю ошибку?
в этом конерктном случае не нужне HA на уровне DNS — берёте BGP и аннонсируете один и тотже IP со всех своих машин. Получаете active-active балансеры через ECMP.
Roman02.01.2017
23:01:31
23:01:31
Alexander02.01.2017
23:02:08
23:02:08
в общем, я тут защитил Django, потому что Django - норм фреймворк и проблема тут не именно в нём, а в том, что там WSGI
ну и channels - это вроде как альтернатива для тех, кому это нужно
может быть, потом со временем и всю Django перетащат с WSGI, кто знает
GoogleAlexander02.01.2017
23:04:07
23:04:07
http://uwsgi-docs.readthedocs.io/en/latest/asyncio.html
Status: EXPERIMENTAL, lot of implications, especially in respect to the WSGI standard
главный плюс Django на фоне других решений - это стабильность, поддержка и отсюда возможность использования фреймворка для серьёзных задач
понятно, что другие решения будут быстрее, скорость - не главный фактор тут
Nikolay02.01.2017
23:08:31
23:08:31
главный плюс Django на фоне других решений - это стабильность, поддержка и отсюда возможность использования фреймворка для серьёзных задач
я бы сказал, что главный плюс джанго - это батарейки, которые уже встроеныпотому что есть flask, который по всем параметрам ее переплюнет, но это не комбайн, а сборная солянка
Alexander02.01.2017
23:08:51
23:08:51
батарейки тут https://djangopackages.org/
куча вещей, которые не нужно писать, ставишь, пару строчек настраиваешь и оно работает, как LEGO
Nikolay02.01.2017
23:09:56
23:09:56
ну, во flask так же примерно
Alexander02.01.2017
23:10:03
23:10:03
да не переплюнет ничего flask) это микрофреймворк
flask для лендингов ок)
Nikolay02.01.2017
23:10:21
23:10:21
это просто другой подход
связка Flask+SQLAlchemy гораздо мощнее джанги
Alexander02.01.2017
23:10:50
23:10:50
SQLAlchemy есть и для Django
Nikolay02.01.2017
23:10:52
23:10:52
но чуточку сложнее в освоении и настройке
Alexander02.01.2017
23:12:12
23:12:12
забей, мне лень спорить
Django - это full-stack
большой фреймворк, где можно делать всё и вся
GoogleAlexey02.01.2017
23:12:37
23:12:37
@SaveTheRbtz образумь пожалуйста людей которые хотят днс для ха использовать
Ну если внутри сети, балансировку делать когда ты контролируешь всех клиентов и серверов, то DNS ничем не хуже чего-то другово.
У нашего **внутреннего** Service Dicovery очень DNS-like API сейчас.
Большинство SD ещё имею DNS-bridge для third party software, например тот же консул.Alexander02.01.2017
23:12:38
23:12:38
Flask - микрофреймворк
Alexey02.01.2017
23:12:41
23:12:41
@m1553ry вон например, всё на DNS и SRV-записях делал в linkedin: https://www.usenix.org/conference/srecon16europe/program/presentation/jackson
Alexander02.01.2017
23:12:45
23:12:45
они в разных сегментах, не конкурируют
Pavel02.01.2017
23:14:01
23:14:01
потому что есть flask, который по всем параметрам ее переплюнет, но это не комбайн, а сборная солянка
Во фласке появилось что-то для rest api?
PsyNikolay02.01.2017
23:14:58
23:14:58
можно самому писать, можно flask-restful, если хочется простоты
Alexander02.01.2017
23:15:18
23:15:18
Django - это такой монстр, где можно всё, если есть задача - всегда найдётся плагинчик, который легко прикрутится
и как-нибудь решит задачу
Nikolay02.01.2017
23:15:28
23:15:28
просто SQLAlchemy к джанге отношения не имеет
у нее свой ORM
Alexander02.01.2017
23:15:45
23:15:45
ну и что?
ты можешь хоть ponyorm юзать
импортируй и используй, что тебе хочется
Nikolay02.01.2017
23:16:24
23:16:24
можешь, но тогда смысл джанги теряется
Alexander02.01.2017
23:16:29
23:16:29
почему?
Nikolay02.01.2017
23:16:35
23:16:35
у нее интеграция хорошая именно со своим ормом
Alexander02.01.2017
23:16:48
23:16:48
так и используй там где надо её ORM
GoogleAlexander02.01.2017
23:16:59
23:16:59
у Django админка удобная
Nikolay02.01.2017
23:17:19
23:17:19
зачем мне мешать все в кашу, если проще взять фласк?
Pavel02.01.2017
23:18:21
23:18:21
можно самому писать, можно flask-restful, если хочется простоты
Так сборная солянка или самому? А flask restful едва ли данные научился валидироватьNikolay02.01.2017
23:18:39
23:18:39
Так сборная солянка или самому? А flask restful едва ли данные научился валидировать
валидировать - jsonschema или wtformsAlexander02.01.2017
23:18:52
23:18:52
мне Django нужна в первую очередь потому что мне надо побыстрее накодить, а вопрос скорости работы всего этого вторичен
Alex02.01.2017
23:18:54
23:18:54
как раз собирался джангу потыкать и в чате про неё, это судьба
Alexander02.01.2017
23:19:07
23:19:07
на Django быстрее делать проекты, чем на любом другом фреймворке
тем более на асинхронном со всеми этими async await'ами
в которых ещё и запутаться на порядок проще
Nikolay02.01.2017
23:20:03
23:20:03
мне Django нужна в первую очередь потому что мне надо побыстрее накодить, а вопрос скорости работы всего этого вторичен
ну так на фласке ничуть не медленнееAlexander02.01.2017
23:20:13
23:20:13
для тех, кому нужно быстро собирать проекты их кубиков и так, чтобы кубики работали надёжно, выбирают Django, это отражается на популярности фреймворка
Nikolay02.01.2017
23:20:26
23:20:26
вообще в большинстве фреймворков одно и то же - это урлы и хэндлеры
Nikolay02.01.2017
23:20:38
23:20:38
для тех, кому нужно быстро собирать проекты их кубиков и так, чтобы кубики работали надёжно, выбирают Django, это отражается на популярности фреймворка
нет, если тебе нужны кубики - то тебе фласк, а не джангаесли искаропки - то джанга
Roman02.01.2017
23:21:14
23:21:14
во-первых, никто нормально не может сказать что такое rest
Открыть в Telegram