«Виртуальное хранилище» на стороне клиента с jQuery

[aleks_raiden]

jStore для вас :) code.google.com/p/jquery-jstore/

[ttas]

Спасибо, подобного комментария я и ожидал. Хороший плагин. Но относительно тяжелый. Удивлен, что он не предлагает использовать механизм сессии сервера.

К сожалению, из всех предложенных автором вариантов хранилищ, пожалуй, можно остановиться на новой спецификации HTML — 5. От варианта с флешем я давно отказался, так как он не поддерживается, например, активно распространяющимися iPhone и iPad.

[aleks_raiden]

а зачем, если он универсальный?

[ttas]

В смысле, хоть какой-то способ, да прокатит? Возможно и так. Попробуем его задействовать на практике.

[farafontov]

dev.w3.org/html5/webstorage/

[ttas]

Идея данного решения ко мне пришла определенное время назад. Да, несомненно, HTML5 предлагает мощные решения. Но, увы, на данный момент еще есть браузеры, которые это понимают плохо или не понимают вообще :).

[farafontov]

caniuse.com/#search=web%20storage

[kuber]

И что сильно разгрузили сервер?
А как быть если изменится наименование товара или цена?

[ttas]

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

[kuber]

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

[ttas]

Тестировал тут loadimpact.com. Для 30 клиентов время с 25с упало до 2с. Этих значений вам достаточно?

[zibada]

все перечисленные проблемы:

получение списка ID товаров из cookie;
запрос в БД, из которой возвращалось название товара, его стоимость и прочие необходимые данные;
использование шаблонизатора (Smarty) для генерирование блока корзины на ряду с генерацией остального содержимого.

прекрасно решаются простейшим кэшированием HTML всего блока на стороне сервера по ключу, равному этой самой cookie.
даже сессии не нужны, обычный apc/memcache или что там на его месте.

если хочется оболочку жестко закэшировать — можно в процессе генерации кэша корзины выносить его содержимое в какой-нибудь "cache/" . md5($cart_cookie) . ".js" и его грузить на клиенте (адрес жаваскриптом вычислять по той же куке)
будет замечательный статичный файл вообще без всякого php, только периодически надо убивать старые файлы.

иначе никакого смысла в оптимизации оболочки нет — у вас все равно на каждой странице запрос к php.

можно пойти еще дальше и даже добавление/удаление в корзину делать чисто на клиенте, исправлением куки прямо из js; но тогда надо на cache/*.js еще обработчик 404 повесить, чтобы он перегенерировал кэш для нового значения куки.

[ttas]

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

иначе никакого смысла в оптимизации оболочки нет — у вас все равно на каждой странице запрос к php.

Очень даже есть, так как у меня не грузится громоздкое серверное приложение, а всего лишь скрипт из неск. строк. А memcache можно попробовать использовать, спасибо, но я думаю, особого выигрыша не будет для объема данных в пару Кб (могу и ошибаться).

[zibada]

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

но раз уж все равно дергать php каждый раз, всегда можно обойтись одним запросом вместо двух — например, взять общий для всех закэшированный код оболочки и подставить туда данные из сессии.
(хотя бы просто в конец дописать через <script>)

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

[ttas]

у чисто клиентского хранилища есть большой недостаток — его никак не почистить с сервера, если данные вдруг устареют.

Согласен, но я привел пример, где данные от сервера совершенно никак не зависят. Сервер тут не причем.

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

А клиент и так делает всего один запрос — именно к storage.php, так как все остальное, в том числе и сама страница, уже находится в кэше браузера. Кстати, никто не мешает делать асинхронный запрос к хранилищу не после всей загрузки страницы, а лишь после загрузки необходимых JS-библиотек.

[ttas]

Кстати, в заголовке сразу можно подгружать text/javascript, обращаясь к storage.php, который будет выводить не строку JSON, а уже var storage={...} в готовом виде. Тогда точно можно не ждать загрузки всей страницы :)

[zibada]

так у вас «один интернет-магазин» или полноценное full-ajax приложение?
если все приложение можно запихнуть в одну страницу и намертво ее закэшировать на клиенте это одно.
если же это более традиционный сайт с массой статичных страниц с динамическим блоком на каждой — все их в кэш пользователю не засунуть, получаем при переходах по сайту те самые 2 запроса на страницу.

[ttas]

Я думаю — это не та проблема, на которой стоит акцентировать внимание. Походите по любому, как вы сказали, более традиционному сайту, и посмотрите сколько запросов на страницу клиент отправляет к серверу. Изображения, я думаю, перевесят то, что мы обсуждаем.

[zibada]

речь шла о первоначальном варианте с аякс запросом по загрузке, который не параллелится с загрузкой остальной статики.
в варианте со <script src=«storage.php»> все уже не так плохо.

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

[ttas]

Вообще, изначально речь шла о хранилище данных на стороне клиента, пусть даже и виртуальном. А способов реализовать сие масса. Тут надо смотреть на сам проект и делать выбор.

[copist]

window.name

[ttas]

window.name — это имя окна. Какое отношение это имеет к хранилищу?

[copist]

Тоже хранилище

Выполни в строке URL бразера
javascript:(function(){window.name='the html fragment';}())

Перегрузи страницу
Выполни в строке URL бразера
javascript:(function(){alert(window.name)}())

Не могу найти на хабре описание.
В window.name помещается 2 мегабайта данных

[ttas]

Да, решение имеет право на существование, интересно. Но я бы выделил 2 минуса. Во-первых, сомнительно, что может быть 2Мб данных сохранено в window.name. Если это не так — тем лучше. Во-вторых, если пользователь откроет несколько вкладок, эти данных из window.name невозможно будет извлечь из любой другой вкладки (читай, окна).