он и есть синхронный, что не вяжется-то?

Может django-server синхронный, но не сама джанго?

забудь про джанго-сервер

В смысл?

фух, быстро получилось

Зарт, можно в лс тогда тебе потравить моз чуть-чуть?:)

в лс не надо, это познавательно всем

давайте с азов

что такое вообще веб-приложение?

некий процесс отзывающийся на http-запросы в более-менее общем случае

Сервак, апи для обработки запроса

поначалу у нас существовали простенькие веб-сервера, которые хавали реквест, транслировали его в путь на диске и возвращали файлик

чтобы сделать вывод более динамичным был изобретён протокол CGI. суть которого сводилась к тому, что веб-сервер разбирал реквест, заполнял его деталями переменные окружения и запускал процесс, потом возвращал вывод этого процесса в сокет наружу

Угу

в лс не надо, это познавательно всем

+

это всё работало, но страшно медленно, поэтому быстро запилили всякие серверные механизмы ака SAPI - NSAPI, ISAPI, вот это всё. чтобы всунуть обработку данных сразу в сервер для скорости

так же всё это дело развивалось и у нас появились промежуточные агенты - прокси, мидлвари

вещи, которые могут сидеть между конечным юзером и сервером и общаться по хттп в обе стороны. или не обязательно по хттп в одну из сторон - так родились AJP, FastCGI, SCGI и прочая

так же шел процесс разработки того как собсно веб-сервера работают внутри с собственно сетью - это и развитие апи на уровне ос - STREAMS, BSD Sockets, Apple Sprockets, WinSock

когда сокеты победили примерно везде, продолжилось развитие механизмов обработки событий от сокетов - select, poll, epoll, kqeueue, IOCP

так же у нас появились самые разные архитектуры построения сетевых приложений - пре-форк, когда сервер создает стопиццот своих копий, каждая из которых слушает единый сокет, и по прилёту входящего пакета ос шедулит один из процессов, который хватает работу на себя

многопоточные модели - примерно так же, но с потоками вместо форка вариаций много - 1:1 - когда на каждый реквест по потоку (популярно было в зеленых потоках явы), пул потоков - более популярный вариант нынче, когда работу выполняет один из свободных потоков, а потом ждёт новой работы

асинхронные модели - когда вся работа делится на много-много мелких кусочков, каждый из которых может быть выполнен в конечное время, а операции I/O отданы на откуп системе, и позволяют избежать ожидания их завершения

переходим конкретно к питону. поначалу разумеется поддерживался лишь цги, как универсальный интерфейс на тот момент. с тех пор в питоне всё еще живы модули cgi и cgitb

потом случились meduza и zope

медуза была одним из самых ранних асинк фреймворков в питоне. asyncore и asynchat - это фактически выдранные от неё мелкие кусочки, дожившие до наших дней я даже видел комментарии той эпохи в ядре сервера waitress 8)

хм... хотя асинк фреймворк был еще тогда, популярности он особой не имел, появившийся позже твистед сорвал все лавры

зопа была одним из первых апп серверов и приобрела приличную популярность в тырпрайзе так как хорошо интегрировалась с тогдашними системами аутентификации, предоставляла очень гибкую схему разработки и безопасности

в те годы начал набирать популярность и пхп, который довольно быстро был перепилен как модуль к апачу

для перла и питона были созданы аналогичные модули mod_perl и mod_python, которые вшивали эти языки прямо в апач, что позволило писать веб-приложения на этих скриптоязыках

хочу отметить что апач до 2.х был строго префорковым, т.е. вся обработка запросов внутри была строго синхронной

и примерно к этому моменту рождается и джанга

изначально она использовала модель хэндлеров - т.е. в зависимости от того к какому серверу надо было прикрутить - создавался экземпляр нужного обработчика - для мод_питона был свой, для фастцги - своё, и чтото еще было

суть всего фреймворка сводилась к тому, чтобы создать объект реквест - подобрать для его обработки нужный вью/контроллер/зовите-как-хотите, а результаты вернуть в веб-сервер

всё это происходит строго по очереди и к моменту возвращения респонса у тебя весь вывод должен быть сгенерирован

поэтому джанга как таковая - синхронна

и должно быть очевидно почему

потому что сервер будет ждать пока фреймворк не сгенерит всё, он не может вернуть клиенту ответ "ща, погоди, тут сперва один воркер повкалывает слегка, потом второй"

к тому времени накопился зоопарк веб-серверов и приложений, и web-sig коллективным разумом родил PEP-333, стандарт WSGI, который декларирует как приложение на питоне должно выглядеть, чтобы его мог вызвать сервер

за основу был взят CGI, плюс туда вшили несколько дубовых вещей, для поддержки тогдашних фреймворков

этот спек совершенно не учитывал никакой асинхронщины, плюс ряд вещей в нем осталась без освещения вовсе - те же чанкед респонсы для стриминга, 100 continue ответы...

часть этих проблем всплыла сильно позже, и спек был обновлен - теперь это PEP-3333, в котором в основном поправили информацию о юникоде/байтах и частично про обработку ошибок. но с асинком там по прежнему глухо

суть всего фреймворка сводилась к тому, чтобы создать объект реквест - подобрать для его обработки нужный вью/контроллер/зовите-как-хотите, а результаты вернуть в веб-сервер

При чем здесь ассинхронность? Ведь это будет разделение на процессы, и мы не сможем передать объект реквеста к вьюхе.

джанго эволюционировала, сперва в ней появился всги хендлер, наподобие предыдущих в последних релизах те старые ошметки были вынесены окончательно

разделение на процессы чего?

Ну, создание реквеста, обработка урла, обработка в вьюхе

Как ты говорил

Слышь че, а если писать маленькую анонимную борду типа двача, то что шустрее? Фласк?

то что знаешь ;Р

хоть на голом всги

Мистер твистер не согласился бы лепить на голом всги(:

Джанго слишком громаден

в общем есть деление - веб-сервера занимаются тем что рулят сокетами - читают и отвечают хттп-запросы в них чтобы получить ответ они либо возвращают файлы с диска, либо пересылают запрос дальше (проксируя), либо вызывают приложения (или уже являются ими)

Зато всё за тебя:)

после перегрузки компа, слетает настройка

есть такая хуйня. Но не разбирался особо - у меня на рабочем тазике аптаймы некислые

в общем есть деление - веб-сервера занимаются тем что рулят сокетами - читают и отвечают хттп-запросы в них чтобы получить ответ они либо возвращают файлы с диска, либо пересылают запрос дальше (проксируя), либо вызывают приложения (или уже являются ими)

Ну, вот здесь архитектура обработки запросов и явлется

джанго же с другой стороны этой кухни - сервер создал процесс, поток в нем, инициализировал там питон, сгенерил питоновый дикт с инфой о запросе - дальше уже фреймворк работает на стороне питона

Слышь че, а если писать маленькую анонимную борду типа двача, то что шустрее? Фласк?

Фласк самое то, имхо

zart спасибо за историю :)

На борде у тебя небольшое количество роутов.

Джанго нахуй

причем джанге не передается никаких реакторов/ивент лупов - т.е. она не может йелдить ожидание

Фласк самое то, имхо

Я юзаю джанго для написания форума, довольно большого А фласк учу как хобби, буду маленькие сайтики пилить)

Да там и учить то нечего. Берешь и пилишь что нужно

в роли примера интегрированного сервера/фреймворка можно посмотреть на черрипай

еще можно посмотреть на аспен и быстро закрыть глаза 8)

Окей, спасибо за время ахуенных историй:)

ERROR: S client not available

на одного миллионера стало больше)

а вот асинковые веб-сервера у нас представлены в первую очередь фреймворками - твистед, гивент, конкурренс, асинкио/троллиус, торнадо

Я юзаю джанго для написания форума, довольно большого А фласк учу как хобби, буду маленькие сайтики пилить)

Я читаю офф доки в пдфке скачанные

к ним есть и веб-фреймворки, заточенные конкретно под асинк - twisted.web2, nevow

насколько оправдано на них чтото клепать я не знаю..

эту нишу уверенно сожрала нода

не все знают js, а от асинка может быть свой профит

жс резко легковеснее, с довольно хитровыебанным джитом и ивент луп ноды отлизан до блеска

в роли альтернативы можно посмотреть на наш отечественный тарантул, или поебаться с луа интеграцией нгинкса

у жс много минусов вроде идиотского приведения типов

у всех этих подходов есть и плюсы и минусы, какие перевешивают - дело сильно индивидуальное

отстутсвия классов и кучи всего еще)

но срачи можно раздуть вполне эпичные 8)

бери тайпскрипт и радуйся жизни

мы тут в комнате регулярно срачи устраивает python vs js vs php))

мы тут в комнате регулярно срачи устраивает python vs js vs php))

Хорошо вам, времени свободного много :(

единственные плюсы пыха - это дешевизна и простота в деплое

в физической, в смысле

по всему прочему - перечитывать https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ до полного просветления

Хорошо вам, времени свободного много :(

не все же время работать, перерывы тоже нужны

отстутсвия классов и кучи всего еще)

если так хочется статик тайпинга и классов - посмотри внимательно на тайпскрипт

часть этого бобра позже войдет в экму

ну я жс совсем плохо знаю

единственные плюсы пыха - это дешевизна и простота в деплое

Дык, его изначально делали из-за того, что деплой перла был заебистым

ну да

натянули примитивный шаблон на апач 8)

хотя нынче все хипстеры уехали на golang) js уже не моден

я уже вижу боевые репорты хипстеров, возвращающихся с голанга обратно в питон

жс резко легковеснее, с довольно хитровыебанным джитом и ивент луп ноды отлизан до блеска

Ток с хуевым управлением памятью, уебищным нпмом и хуево написанными школьниками либами в нём. Но да, каждому своё.

поGOляли и хватит

даааа... нпм - сцуко, сказка

думаю все в курсе последнего отсоса нпм в глобальном масштабе?