Макс Лапшин написал о том, куда нужно двигаться Рельсам на примере Nitrogen, и резюмировал:
Важно понять, что код тут выходит за рамки классического «запрос-ответ» и позволяет в процессе обработки долгоживущего процесса что-то рисовать в браузере.
[…]
даже на таком маленьком примере кода ясно, что классический подход а-ля php: reply on request уже не актуален. Нотификация с сервера на клиент может пройти когда угодно и теперь надо это учитывать.
Меня зацепило словосочетание "уже не актуален". На самом деле, идея построения серверного кода в виде как бы непрерывной функции, когда общение с браузером абстрагируется куда-нибудь внутрь, не нова. Это называется continuation-based фреймворки, и они есть не только на Erlang, но и на Ruby, и на Python, и на Smalltalk. А у лисперов (и особенно схемеров) это вообще любимое упражнение, как я заметил.
Однако несмотря на то, что попыток было много, большая часть веб-программирования продолжает делаться в запрос-ответном стиле. И long-poll тоже укладывается в этот подход.
Я не знаю, будет ли так всегда. Возможно, все попытки до сих пор были просто неудачно реализованы, или не хватало каких-то ярких примеров, или в браузерных технологиях нет какой-то мелочи, мешающей этому подходу выстрелить. Но я знаю, что запрос-ответная схема — это не какая-то устаревшая концепция, это, на самом деле, тот самый REST — одна из фич веба. Есть мнение, что именно из-за неё он победил всё остальное. И если continuation-based фреймворки хотят быть следующей ступенью эволюции, им надо будет по крайней мере предложить что-то взамен того, что предлагает REST. Начать хотя бы с универсальной адресуемости состояния сервиса.
Комментарии: 4 (особо ценных: 1)
Ну хорошо, тебя успокоит другая формулировка «рельсы не могут больше быть самым прогрессивным веб-фреймворком, предлагая лишь вариант с запрос-ответ».
Безусловно, важно, что концепция «запрос-ответ-сдохли» многократно упрощает все программистские проблемы типа управления ресурсами и масштабирования. Но этого одного уже стало не хватать.
Особо ценный комментарий
Я вижу резкое удорожание разработки. REST проект относительно прост и понятен архитектурно, при проектировании он хорошо дробится, за счет связок адрес->хэндлер локализовать дефекты достаточно просто. Также при использование REST интеграция становится достаточно простой вещью. Веб победил за счет REST потому что это дешево и надежно.
С continuation мы сразу огребаем ведро проблем - проблема с проксированием и кэширование выдачи, падение надежности за счет необходимости поддержания стейта воркеров, смешение уровней абстракции и плавание ошибок по ним(имхо) и т.д.
Много крупных проектов на Stackless python? Можно сказать, что полтора. А ему семь лет, между прочим. Это фактически так и осталось внутренним решением CCP. Не очень взрывной рост для технологии будущего. Хотя, конечно, исходники и архитектура EVE впечатляют.
В статье вики пяток фреймворков, каждый из которых фактически внутреннее решение для одного проекта и строчка в портфолио автора, не больше.
А много ли веб-проектов пишут на, например, scheme? Где парад охрененных continuatuon фреймворков, что мешало этому случиться на заре web и что мешает случиться до сих пор? (у нас он ограниченно используется, достаточно чтобы понять насколько неблагодарная задача создавать веб-решения на функционалке без крайней на то необходимости)
Имхо, удел contiunuation-based веба это узкоспециализированные решения, тесно сросшиеся с проектом, для которого, в силу его задач, предоставляемые приемущества перевешивают многочисленные проблемы. В любом случае не массовые. Не массовые - значит ненадежные за рамками проекта и с бедным комьюнити, хочешь использовать - изволь перелопатить под себя и вникнуть в фреймворк не хуже его создателей.
Если посмотреть исходники примеров под nitrogen все встает на свои места, у них фактически полная репрезентация DOM в серверном коде, отсюда и растет уровень контроля над ним. Лично меня пугает подобное капитальное свертывание уровней абстракции а-ля назад в 90-е. И мне кажется, что такой стиль работы является предполагаемым разработчиками.
Я считаю, что для джанги это не ново: существует такая штука как мастер форм (https://docs.djangoproject.com/en/1.3/ref/contrib/formtools/form-wizard/). Который является специализированным contiunuation-based микрофреймворком.
Все написанное про continuation наверное справедливо, однако мне кажется что Макс Лапшин имел ввиду event-based, а не continuation. Сейчас comet становится все более популярным и держать для каждого соединения долгоживущий процесс слишком затратно в существующих решениях. А пример с erlang'ом приведен в силу того, что он как раз ориентирован на работу с большим количеством легковесных процессов. Посмотрите на тот же RabbitMQ. Вобщем мне кажется, что в данном случае он имел ввиду движение от request-response в сторону event-based модели.