1. SSI + XSLT + шаблоны в бэкенде (без последних если используем только xslt) шаблоны двух видов — гемор. xslt сам по себе не самый удобный шаблонизатор.
3. Такая разница, что если блок не кэшируется принципиально, то придётся запрашивать его с бекэнда каждый раз, и если таких блоков больше одного, то вся эта солянка теряет смысл. И даже если один, она становится очень сомнительной.
4. Тестировали, некоторые трансформации текут. Возможно, если просто подсовывать значения, то с этим не столкнёшься.
5. Намного сложнее, чем html, любой неэкранированный символ, любая неопредённая entity, неправильный utf символ и всё, весь документ сломался.
Во-первых, это гемор, во-вторых xslt — это не так уж быстро, в третьих остаются блочки некэшируемые по другим причинам: число сообщений у юзера, статус онлайн кого-нибудь, просто часто обновляющаяся инфа, в-четвёртых, libxml/libxslt текут, в-пятых, чтобы делать xsl-трансформацию нужно чтобы ssi-скрипты выдавали валидный xml.
Ну и в конце концов, что у нас получится? Бекэнд со своим движком и какими-то шаблонами (предположительно), ssi-шаблончики, xsl-трансформации. жуткий зоопарк.
Причём тут поддержка переменных и выражения?
Мне нужно прочитать сессию пользователя из, скажем, редиса, запросить сколько у него сообщений ещё откуда-нибудь (PostgreSQL) и вывести соответствующую фразу. ngnix же это за меня не сделает?
Или, например, мы показываем список постов, для текущего пользователя нужно показать кнопки редактирования рядом с его постами, что же мне кэшировать этот список постов отдельно для каждого юзера?
Способ слишком не гибкий — применяли уже кое-что подобное.
Почему? Потому что могут быть принципиально не кэшируемые блочки: те что зависят от текущего пользователя, например, «Спасибо, что заглянули, %username%! У вас %msg_count% новых сообщений». Каждый такой блочок будет выражаться в запросе к backend-у. Допустим таких блочков у нас 5 (вполне возможная ситуация: приветствия, формы, контролы над своими сообщениями и т.п.), это означает, что на каждую страницу на нужно делать 5 запросов к backend-у, пусть все они будут простыми, но с каждого мы получим оверхед сети, fastcgi запроса/разбора, проверки текущего пользователя. В общем, ужасно.
Куда эффективнее да ещё и гибче разруливать такие вещи на самом backend-е
Лидер всегда будет задавать если не w3c стандарт, то по крайней мере стандарт де факто, разработчику сайта или заказчику если на то пошло нужно, чтобы сайт работал у подавляющего большинства пользователей, чем бы они не пользовались
Дело вовсе не в насильном обновлении, а в том, что люди-то и не знают, что можно обновиться, многие вообще не знают, что такое браузер. У них просто стоит пиратский WinXP с IE6, а был бы не пиратский Windows Update давно бы уже их обновил.
Сравнивать так прямо десктопные и веб-приложения просто нечестно.
А насчёт того, что нововведения должны внедрять разработчики браузеров, а W3C потом стандартизировать лучшее — верно.
при особом желании можно запустить два нгинкса, задним жать передним кэшировать и выдавать статику. Писать какой-то кастомный бекэнд — напрашиваться на неприятности
Я понимаю почему, но мне кажется это нелогичным. Ответ Not Modified этот модуль к примеру не фильтрует.
И как отловить 404? Я использую вот такой, не самый элегантный способ:
location-ов может быть больше одного, тогда придётся дублировать (один для image_filter resize, второй для crop, например). Кроме того, с $1 $2 были проблемы в location, поэтому я и вынес определение размеров наружу
Вариант с проксированием своего сервера node.js тоже рассматривался, но решили, что возможностей ngx_http_image_filter_module нам хватит, а если не хватит, то можно модуль дописать.
На самом деле большие возможности ImageMagick тут просто не нужны, нужен просто ресайз картинок, иногда ресайз с кропом, это модуль умеет.
3. Такая разница, что если блок не кэшируется принципиально, то придётся запрашивать его с бекэнда каждый раз, и если таких блоков больше одного, то вся эта солянка теряет смысл. И даже если один, она становится очень сомнительной.
4. Тестировали, некоторые трансформации текут. Возможно, если просто подсовывать значения, то с этим не столкнёшься.
5. Намного сложнее, чем html, любой неэкранированный символ, любая неопредённая entity, неправильный utf символ и всё, весь документ сломался.
Ну и в конце концов, что у нас получится? Бекэнд со своим движком и какими-то шаблонами (предположительно), ssi-шаблончики, xsl-трансформации. жуткий зоопарк.
Мне нужно прочитать сессию пользователя из, скажем, редиса, запросить сколько у него сообщений ещё откуда-нибудь (PostgreSQL) и вывести соответствующую фразу. ngnix же это за меня не сделает?
Или, например, мы показываем список постов, для текущего пользователя нужно показать кнопки редактирования рядом с его постами, что же мне кэшировать этот список постов отдельно для каждого юзера?
Почему? Потому что могут быть принципиально не кэшируемые блочки: те что зависят от текущего пользователя, например, «Спасибо, что заглянули, %username%! У вас %msg_count% новых сообщений». Каждый такой блочок будет выражаться в запросе к backend-у. Допустим таких блочков у нас 5 (вполне возможная ситуация: приветствия, формы, контролы над своими сообщениями и т.п.), это означает, что на каждую страницу на нужно делать 5 запросов к backend-у, пусть все они будут простыми, но с каждого мы получим оверхед сети, fastcgi запроса/разбора, проверки текущего пользователя. В общем, ужасно.
Куда эффективнее да ещё и гибче разруливать такие вещи на самом backend-е
А насчёт того, что нововведения должны внедрять разработчики браузеров, а W3C потом стандартизировать лучшее — верно.
Надо будет в него добавлять когда понадобятся новые типоразмеры картинок, а так просто пеняешь ссылку и всё.
И как отловить 404? Я использую вот такой, не самый элегантный способ:
Просто у меня несколько location-ов в таком случае /path/to/images/ придётся указывать в каждом.
На самом деле большие возможности ImageMagick тут просто не нужны, нужен просто ресайз картинок, иногда ресайз с кропом, это модуль умеет.