Причём тут поддержка переменных и выражения?
Мне нужно прочитать сессию пользователя из, скажем, редиса, запросить сколько у него сообщений ещё откуда-нибудь (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 тут просто не нужны, нужен просто ресайз картинок, иногда ресайз с кропом, это модуль умеет.
Можно сделать через proxy_store, можно поставить больше таймаут, это уже дело вкуса.
А можно радоваться тому, что неиспользуемые миниатюрки сами уничтожаться через сутки.
Всё зависит от того, чего мы хотим добиться
Мне нужно прочитать сессию пользователя из, скажем, редиса, запросить сколько у него сообщений ещё откуда-нибудь (PostgreSQL) и вывести соответствующую фразу. ngnix же это за меня не сделает?
Или, например, мы показываем список постов, для текущего пользователя нужно показать кнопки редактирования рядом с его постами, что же мне кэшировать этот список постов отдельно для каждого юзера?
Почему? Потому что могут быть принципиально не кэшируемые блочки: те что зависят от текущего пользователя, например, «Спасибо, что заглянули, %username%! У вас %msg_count% новых сообщений». Каждый такой блочок будет выражаться в запросе к backend-у. Допустим таких блочков у нас 5 (вполне возможная ситуация: приветствия, формы, контролы над своими сообщениями и т.п.), это означает, что на каждую страницу на нужно делать 5 запросов к backend-у, пусть все они будут простыми, но с каждого мы получим оверхед сети, fastcgi запроса/разбора, проверки текущего пользователя. В общем, ужасно.
Куда эффективнее да ещё и гибче разруливать такие вещи на самом backend-е
А насчёт того, что нововведения должны внедрять разработчики браузеров, а W3C потом стандартизировать лучшее — верно.
Надо будет в него добавлять когда понадобятся новые типоразмеры картинок, а так просто пеняешь ссылку и всё.
И как отловить 404? Я использую вот такой, не самый элегантный способ:
Просто у меня несколько location-ов в таком случае /path/to/images/ придётся указывать в каждом.
На самом деле большие возможности ImageMagick тут просто не нужны, нужен просто ресайз картинок, иногда ресайз с кропом, это модуль умеет.
А можно радоваться тому, что неиспользуемые миниатюрки сами уничтожаться через сутки.
Всё зависит от того, чего мы хотим добиться