LINUX.ORG.RU

Веб-фреймворк по принципу static first

 ,


0

1

У человека, работа которого не связана напрямую с вебом возникла идея. Как насчет создания веб-фреймворка, который призван минимизировать генерацию сложного динамического контента. Основная идея - максимум выноса в статику, например на Nginx.

Говоря другими словами, это удобный REST фреймворк, который 99% времени отдает и получает JSON/XML в максимально удобной форме. Кроме этого out-of-the-box ленивая генерация статических HTML страниц в папку, которая раздается nginx на основе данных их БД. Тоесть вам нужен /goods/item/3, вы будете перенаправлены на /goods/item/3.html, который только что нагенерен фреймворком и будет отдан nginx. Если он там есть, то можно сразу редиректить. Более быстрая альтернатива - делать это со стороны nginx. Плагин в нем будет дергать генерацию страницы и нашего фреймворка. Если данные в 3 изменятся, то страницу можно инвалидировать. Эдакий автоматический server side caching, который можно применять к различным ресурсам. Например тривиальный submit загруженой картинки в такую папку.

Comet - first class citizen

Все это делается ручками и решается вполне всякими проксями, но можно на Scala/Groovy/Ruby/Python побороться за максимальную краткость, прозрачность и простоту.

GWT вообще говоря делает подобное, но там намешано много чего и все скрыто. Круто было бы сделать простой фреймворк полностью вокруг идеи статики+Ajax+REST.

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

★★★★★

Последнее исправление: vertexua (всего исправлений: 3)

Я нечто подобное для ЛОРа предлагал. Закидали говняшками: говорят, что нагрузка на сервер будет выше.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

Фиг его знает, ибо нетипичное решение, на очень динамическом сайте может быть стремно. Хотя если через Comet обновлять посты, то я думаю было бы норм.

Другое дело всякие магазины, там был бы прирост огого. Через время 99% сайта было бы одной статикой.

vertexua ★★★★★
() автор топика
Ответ на: комментарий от vertexua

Вот только пришлось бы еще 1 демон содержать для подчистки старья. Ну, а насчет того, что быстрее: генерировать контент динамически или же отдавать статику squid'ом - бабушка надвое нагадала (точнее, я-то думал, что с проксей быстрее, однако ЛОРовские аналитики говорят обратное).

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

Если ты генеришь контент динамически, то ты тратишь ценные ресурсы умного сервера, который жрет память. А nginx может через sendfile отдавать гектары не вспотев.

vertexua ★★★★★
() автор топика

Берешь nginx, пишешь perl модуль. В нем генеришь md5, например, от урла и проверяешь файлик вида - /srv/ur.host/a/b/c/abcdefgh. Если есть - отдаешь его с помощью sendfile, если нет, то передаешь управление скрипту, которые генерит кэш и складывает в те файлики.

xpahos ★★★★★
()

С этим довольно много проблем, индексация поисковиками, тормозная работа шаблонизатора на js, то, что на каждую страницу будет 2 запроса, вместо одного.
Насчет nginx, там есть такая штука, как proxy_cache, довольно гибко настраивается, позволяет любую страницу закэшировать в виде статики.

Tark ★★
()

это удобный REST фреймворк, который 99% времени отдает и получает JSON/XML

перенаправлены на /goods/item/3.html

Взаимоисключающие параграфы, однако.

Кроме того, неправильно понимается REST. Зачем посылать 302 на goods/item/3, когда можно сразу ответить 200? А уж откуда берутся данные: динамически генерируются ли, берутся из memcached ли или вообще из пресловутого 3.html - дело десятое.

Далее. Генерить HTML на стороне сервера - совершенно дурацкая идея. Только на стороне клиента. Мотивацию данного подхода я даже обсуждать не собираюсь, ибо настолько все тривиально и понятно, если нет PHP головного мозга. Поэтому, раз уж так хочется сношать жесткий диск сервака, то 3.json, а не 3.html.

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

Macil ★★★★★
()

Тоесть вам нужен /goods/item/3, вы будете перенаправлены на /goods/item/3.html, который только что нагенерен фреймворком и будет отдан nginx.

man proxy_store/fastcgi_store
и try_files $uri $uri/index.html /fetch$request_uri;

со стороны бэкэнда надо только удалять странички при инвалидации.

У меня на это навешен еще varnish спереди и блочное кеширование. Бэкэнд отдает страницу без блоков, нгникс кладет ее в кеш, варниш собирает все вместе и кладет в свой кеш.

iSage ★★★★
()
Ответ на: комментарий от Macil

Самый классный веб-фреймворк, который я на данный момент знаю - CouchDB.

не могли бы вы на этом месте чуть по-подробнее? насколько я знаю, couchdb - это база данных. Как она может быть веб-фреймворком. Ну и поделитесь пожалуйста спискок нормальной литературы для сабжа (couchdb). заранее благодарен.

anonymous
()
Ответ на: комментарий от anonymous

Ну и поделитесь пожалуйста спискок нормальной литературы

Единственный достойный источник: CouchDB Definitive Guide http://guide.couchdb.org/

Как она может быть веб-фреймворком.

Внезапно REST API, вот как. Плюс Show Functions самой CouchDB, хотя они нафиг не сдались на самом деле.

Понадобится морда типа nginx'а, для URL rewrite, кеширования/балансировки нагрузки и раздачи статики. Хотя тебе ничего не мешает хранить скрипты, HTML и BLOB в самой CouchDB. В CouchDB Definitive Guide есть примеры.

Macil ★★★★★
()
Ответ на: комментарий от Macil

И понятно дело, что-то понадобится на стороне клиента. Например Knockout.js ;)

Macil ★★★★★
()

Спасибо всем отписавшимся, ситуация стала более ясна

vertexua ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.