какие способы хранения данных в браузере вы знаете когда и каким методом можно пользоваться

Хранилище для Веба

Доброго времени суток, друзья.

Представляю вашему вниманию перевод статьи «Storage for the Web» автора Pete LePage.

Существует несколько технологий для хранения данных в браузере. Какая из них лучше?

Интернет-соединение может быть плохим или вовсе отсутствовать в определенных местах. Поэтому поддержка оффлайн-режима является одной из ключевых особенностей прогрессивных веб-приложений. Даже при наличии высокоскоростного подключения разумно применять кэширование и другие техники для улучшения пользовательского опыта. Существует несколько способов сохранения файлов (HTML, JavaScript, CSS, изображения и т.д.) и данных (пользовательские данные, новостные статьи и др.). Но какое решение лучше выбрать? И как обеспечить его долговечность?

Что использовать?

Могу посоветовать следующее:

Что насчет других механизмов?

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

Какой объем данных я могу хранить?

Как минимум, несколько сотен мегабайт, потенциально, сотни гигабайт. Это зависит от браузера, однако объем хранилища, как правило, зиждется на объеме доступной памяти в устройстве пользователя.

Сегодня большая часть браузеров этого не делает, автоматически увеличивая объем хранилища в пределах квоты. Исключение составляет Safari, который при достижении 750 Мб запрашивает разрешение пользователя на увеличение лимита до 1,1 Гб. Попытка превысить квоту закончится провалом.

Как проверить остаток лимита?

Для этого во многих браузерах можно воспользоваться StorageManager API. Он показывает общее количество байт, использованных IndexedDB и Cache API, позволяя рассчитать остаток.

Необходимо учитывать, что StorageManager API пока поддерживается не всеми браузерами. Однако даже если он поддерживается, необходимо предусматривать обработчик ошибок. В некоторых случаях квота может превышать реальный объем хранилища.

Инспектирование

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

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

Как обрабатывать ошибки?

Что делать при достижении лимита? Разумеется, обрабатывать ошибки, будь то QuotaExceededError или нечто иное. Затем, в зависимости от дизайна вашего приложения, следует выбрать способ их обработки. Можно, например, удалять старый контент или данные в зависимости от их размера, либо предоставлять пользователю возможность решать, что удалять.

IndexedDB и Cache API выбрасывают DOMError QuotaExceededError при превышении квоты.

IndexedDB

При достижении лимита попытка записать данные в IndexedDB потерпит неудачу. Будет вызван метод onabort() с событием в качестве аргумента. Событие будет содержать DOMException в свойстве ошибки. Проверка имени ошибки вернет QuotaExceededError.

Cache API

Попытка записать данные в Cache API при достижении лимита будет отклонена с QuotaExceededError DOMException.

Как работает очистка хранилища?

Веб-хранилища подразделяются на две категории, «автономные» и «управляемые». Автономное означает, что хранилище может быть очищено браузером без участия пользователя, однако оно менее устройчиво при длительном использовании, а также при наличии критических данных. Управляемые хранилища не очищаются автоматически при заполнении. Пользователь должен вручную очищать такие хранилища (через настройки браузера).

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

Условия для очистки хранилища следующие:

Бонус: обертка из промисов над IndexedDB

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

Заключение

Времена ограниченных хранилищ и запросов разрешения пользователя на увеличение лимита канули в лету. Сайты могут эффективно хранить все ресурсы и данные, необходимые им для работы. С помощью StorageManager API вы можете определить, сколько памяти использовано и сколько еще осталось. А с помощью перевода хранилища в режим ручного управления, вы можете защитить данные от удаления.

Источник

Где хранить данные на вебе?

Вольный перевод статьи Storage for the web

Существует много разных вариантов хранения данных в браузере. Какой из них лучше всего подходит для ваших нужд?

Подключения к интернету могут быть нестабильными или вообще отсутствовать, поэтому автономная поддержка и надежная производительность являются общепринятыми функциями прогрессивных веб-приложений. Даже в идеальных беспроводных средах разумное использование кэширования и других методов хранения может существенно улучшить взаимодействие с пользователем. Существует несколько способов кеширования статических ресурсов приложения (HTML, JavaScript, CSS, изображений и т. Д.) и данных (данные пользователя, новостные статьи и т.д.). Но какое решение лучше? Сколько можно хранить? Как вы предотвращаете их вытеснение?

Что я должен использовать?

Вот общая рекомендация для хранения ресурсов:

IndexedDB и Cache Storage API поддерживаются в каждом современном браузере. Они оба асинхронные и не будут блокировать основной поток. Они доступны из window объекта, web woker’ов и service wroker’ов, что упрощает их использование в любом месте кода.

А что насчет других механизмов хранения?

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

SessionStorage зависит от вкладки и ограничен временем жизни вкладки. Он может быть полезнен для хранения небольших объемов информации, специфичной для сеанса, например ключа IndexedDB. Его следует использовать с осторожностью, поскольку он является синхронным и блокирует основной поток. Он ограничен до 5 МБ и может содержать только строки. Поскольку он зависит от вкладки, он недоступен web worker’ам или service worker’ам.

LocalStorage следует избегать, поскольку он является синхронным и блокирует основной поток. Он ограничен до 5 МБ и может содержать только строки. LocalStorage недоступен web worker’ам или service worker’ам.

Файлы cookie используются, но не должны использоваться для хранения. Файлы cookie отправляются с каждым HTTP-запросом, поэтому хранение чего-либо большего, чем небольшой объем данных, значительно увеличит размер каждого веб-запроса. Они синхронны и недоступны для web worker’ов. Как и LocalStorage и SessionStorage, файлы cookie ограничиваются только строками.

File System API и FileWriter API предоставляют методы для чтения и записи файлов в изолированную файловую систему. Хотя они асинхроны, они не рекомендуются, потому что они доступны только в Chromium браузерах.

Native File System API был разработан, чтобы облегчить пользователям чтение и редактирование файлов в их локальной файловой системе. Пользователь должен предоставить разрешение, прежде чем страница сможет читать или записывать в любой локальный файл, и разрешения не сохраняются между сеансами.

WebSQL не должен использоваться, а существующее использование должно быть перенесено в IndexedDB. Поддержка была удалена практически из всех основных браузеров. W3C прекратил поддержку спецификации Web SQL в 2010 году, не планируя дальнейших обновлений.

Application Cache не должен использоваться, а существующее использование должно быть перенесено на service worker’ов и Cache API. Он устарели, и поддержка будет удалена из браузеров в будущем.

Сколько я могу хранить?

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

В прошлом, если сайт превышал определенный порог хранимых данных, браузер предлагал пользователю предоставить разрешение на использование большего количества данных. Например, если сайт использовал более 50 МБ, браузер предложит пользователю разрешить ему сохранить до 100 МБ, а затем запросит снова с шагом 50 МБ.

Сегодня большинство современных браузеров не будут спрашивать пользователя и позволят сайту использовать свою выделенную квоту. Исключением является Safari, который запрашивает 750 МБ и запрашивает разрешение на хранение до 1,1 ГБ. Если источник попытается использовать больше, чем его выделенная квота, дальнейшие попытки записи данных потерпят неудачу.

Как я могу проверить, сколько места доступно?

Во многих браузерах вы можете использовать StorageManager API, чтобы определить объем памяти, доступный для сайта, и объем памяти, который он использует. Он сообщает об общем количестве байтов, используемых IndexedDB и Cache API, и позволяет рассчитать приблизительное оставшееся доступное пространство для хранения.

Exit fullscreen mode

StorageManager еще не реализован во всех браузерах, поэтому вы должны проверить его, прежде чем использовать. Даже когда он доступен, вы все равно должны ловить ошибки превышения квоты (см. Ниже). В некоторых случаях доступная квота может превышать фактический объем доступного хранилища.

Другие браузеры на основе Chromium могут учитывать количество свободного места при сообщении о доступной квоте. Chrome этого не делает и всегда будет давать 60% фактического размера диска. Это помогает уменьшить возможность определения размера cross origin ресурсов.

Инспектирование

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

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

Как разобраться с превышением квоты?

Что делать, когда вы превышаете квоту? Самое главное, вы всегда должны отлавливать и обрабатывать ошибки записи, будь то QuotaExceededError или что-то еще. Затем, в зависимости от архитектуры вашего приложения, решите, как с этим справиться. Например, удалите контент, к которому долгое время не обращались, удалите данные в зависимости от размера или предоставьте пользователям возможность выбрать то, что они хотят удалить.

IndexedDB

Exit fullscreen mode

Cache API

Exit fullscreen mode

Как работает вытеснение?

Веб-хранилище подразделяется на две группы: «Best effort» и «Persistent Best Effort означает, что хранилище может быть очищено браузером без прерывания работы пользователя, но оно менее долговечно для долговременных или критических данных. Persistent хранилище не очищается автоматически при низком уровне хранилища. Пользователь должен вручную очистить это хранилище (через настройки браузера).

По умолчанию данные сайта (включая IndexedDB, Cache API и т.д.) попадают в категорию Best Effort, что означает, что, если сайт не запросил постоянное хранилище, браузер может исключить данные сайта по своему усмотрению, например, когда память устройства невелика.

Политика вытеснения для Best Effort:

Начиная с iOS и iPadOS 13.4 и Safari 13.1 на macOS, существует семь дней для всех хранилищ с возможностью записи сценариев, включая IndexedDB, регистрацию service worker’ов и Cache API. Это означает, что Safari будет удалять весь контент из кэша после семи дней использования Safari, если пользователь не взаимодействует с сайтом. Эта политика вытеснения не распространяется на установленные PWA, которые были добавлены на домашний экран. См. Полная блокировка сторонних файлов cookie и многое другое в блоге WebKit для получения полной информации.

Бонус: Зачем использовать враппер для IndexedDB?

Заключение

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

Источник

Как работает JS: системы хранения данных

При проектировании веб-приложения чрезвычайно важно выбрать подходящие средства для локального хранения данных. Речь идёт о механизме, который позволит надёжно хранить информацию, будет способствовать снижению объёма данных, передаваемых между серверной и клиентской частями приложения, и при этом не ухудшит скорость реакции приложения на воздействия пользователя. Хорошо продуманная стратегия локального кэширования данных является центральным звеном в разработке мобильных веб-приложений, которые могут работать без подключения к интернету. Современные пользователи всё чаще и чаще относятся к подобным возможностям как к чему-то привычному и ожидаемому.

Сегодня, в переводе 16 части серии материалов, посвящённых всему, что связано с JavaScript, мы поговорим о механизмах хранения данных на стороне клиента, которые могут использоваться в веб-разработке, и о выборе системы хранения данных для конкретного проекта.

Модель данных

Модель данных определяет внутреннюю организацию хранимых данных. Она воздействует на все аспекты устройства веб-приложения, в ней заложены решения, часто компромиссные, от которых зависит эффективность приложения и возможность системы хранения решать поставленные перед ней задачи. Не существует некоего «самого лучшего» подхода к проектированию моделей данных, нет универсальных решений, подходящих для всех приложений. Выбор модели данных основан на особенностях и потребностях конкретного приложения. Рассмотрим несколько основных моделей хранения данных, из которых можно выбрать что-то подходящее для конкретного проекта.

Методики постоянного хранения данных, доступных браузеру

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

Оценка систем хранения данных на стороне клиента

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

Для начала, однако, остановимся на нескольких общих вопросах, которые стоит принять к сведению перед выбором конкретной технологии для хранения данных. Конечно, в первую очередь нужно понять то, как ваше приложение будет использоваться, как будет организована его поддержка, как планируется его развивать. При этом, если даже у вас есть чёткие ответы на эти вопросы, вы, в итоге, можете выйти на несколько вариантов систем хранения данных, из которых нужно будет выбрать наиболее подходящий. Вот на что стоит обратить внимание, выбирая систему хранения данных:

Сравнение систем хранения данных

В этом разделе мы рассмотрим некоторые из существующих систем хранения данных, доступных веб-разработчикам, и сравним их по описанным выше показателям.

Теперь поговорим подробнее об этих способах хранения данных.

API FileSystem

Благодаря использованию API FileSystem веб-приложения могут работать с выделенной областью локальной файловой системы пользователя. Приложение может просматривать содержимое хранилища, создавать файлы, выполнять операции чтения и записи.

Это API состоит из следующих основных частей:

Интерфейс filesystem этого API используются для представления файловой системы. Доступ к соответствующим объектам можно получить через свойство filesystem. Некоторые браузеры предлагают дополнительные API для создания файловых систем и управления ими.

Этот интерфейс не даёт веб-странице доступ к файловой системе пользователя. Вместо этого он позволяет работать с чем-то вроде виртуального диска, который находится в «песочнице», создаваемой браузером. Если вашему приложению нужен доступ к файловой системе пользователя, вам понадобится использовать другие механизмы.

Веб-приложение может запросить доступ к виртуальной файловой системе, выполнив вызов window.requestFileSystem() :

Если вы вызываете requestFileSystem() в первый раз, то для вашего приложения будет создано новое хранилище. Важно помнить, что это — изолированное хранилище, то есть, одно веб-приложение не может работать с хранилищем, созданным другим приложением.

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

API FileSystem серьёзно отличается от других подобных систем, используемых веб-приложениями, так как оно нацелено на решение задач хранения данных на клиенте, которые не очень хорошо решаются средствами баз данных. В целом, это — приложения, которые работают с большими фрагментами бинарных данных, либо обмениваются данными с внешними по отношению к браузеру приложениями.

Среди вариантов использования API FileSystem можно отметить следующие:

Поддержка API FileSystem браузерами

API LocalStorage

API LocalStorage, или локальное хранилище, позволяет работать с объектом Storage объекта Document с учётом принципа одинакового источника. Данные не теряются между сессиями. API LocalStorage похоже на API SessionStorage, сессионное хранилище, разница заключается в том, что данные в сессионном хранилище удаляются после того, как сессия страницы завершится, а данные в локальном хранилище хранятся постоянно.

Обратите внимание на то, что данные, размещённые в локальном или в сессионном хранилище привязаны к источнику страницы, который определяется комбинацией протокола, хоста и порта.
Вот сведения о поддержке API LocalStorage различными браузерами.

Поддержка API LocalStorage браузерами

API SessionStorage

Вот сведения о поддержке API SessionStorage различными браузерами:

Поддержка API SessionStorage браузерами

API Cookie

Cookie (куки, веб-куки, браузерные куки) — это небольшие фрагменты информации, которые сервер отправляет браузеру. Браузер может их сохранять и отправлять серверу, используя их при формировании запросов к нему. Обычно они используются для идентификации конкретного экземпляра браузера, от которого поступают запросы. Например — для того, чтобы пользователь, после входа в систему, оставался бы в ней. Куки — это нечто вроде системы хранения информации о состоянии сеанса связи для протокола HTTP, который рассматривает каждый запрос, даже приходящий из одного и того же браузера, как совершенно независимый от других.

Куки используются для решения трёх основных задач:

Существует два вида куки:

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

API Cache

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

Браузер делает всё, что в его силах, для того, чтобы поддерживать определённый объём доступного пространства кэша, но он может удалить кэш для некоего источника. Обычно браузер либо удаляет весь кэш, либо совершенно его не касается. Пользуясь кэшами, не забывайте о том, чтобы различать их в соответствии с версиями ваших скриптов, например, включая версию скрипта в имя кэша. Делается это для того, чтобы обеспечить безопасную работу различных версий скриптов с кэшем. Подробности об этом можно посмотреть здесь.

Интерфейс CacheStorage представляет хранилище для объектов Cache. Вот задачи, за решение которых отвечает этот интерфейс:

Обратиться к CacheStorage можно через глобальное свойство caches.

API IndexedDB

API IndexedDB — это СУБД, которая позволяет хранить данные средствами браузера. Так как это позволяет создавать веб-приложения, обладающие возможностями работы со сложными наборами данных даже без подключения к интернету, такие приложения могут одинаково хорошо себя чувствовать и при наличии соединения с сервером, и без него. IndexedDB находит применение в приложениях, которым нужно хранить большие объёмы данных (например, такое приложение может быть чем-то вроде каталога фильмов некоей службы, выдающей их напрокат), и которым необязательно поддерживать постоянное соединение с сетью для нормальной работы (например — это почтовые клиенты, менеджеры задач, записные книжки, и так далее).

Здесь мы уделим IndexedDB немного больше внимания, чем остальным технологиям хранения данных на клиенте, так как, с одной стороны, другие API известны более широко, а с другой — так как СУБД IndexedDB становится всё более популярной из-за постоянного роста сложности веб-приложений.

▍Внутренние механизмы IndexedDB

API IndexedDB позволяет сохранять в базу и читать из неё данные объектов с использованием «ключа». Все изменения, вносимые в базу данных, происходят в транзакциях. Как и большинство подобных решений, IndexedDB следует политике одного источника. В результате приложение может получить доступ только к данным, относящимся к собственному домену, но не к данным из других доменов.

IndexedDB — это асинхронное API, которое можно использовать в большинстве контекстов, в том числе — в веб-воркерах. Раньше существовала и синхронная версия этого API, предназначенная для веб-воркеров, но её убрали из спецификации из-за того, что она была не особенно интересна веб-разработчикам.

У IndexedDB был конкурент в лице базы данных WebSQL, но работа над этим стандартом была прекращена W3C много лет назад. В то время, как и IndexedDB и WebSQL являются решениями для хранения данных на клиенте, их функционал различается. WebSQL — это реляционная СУБД, а IndexedDB — это система, основанная на индексированных таблицах.

Не стоит приступать к работе с IndexedDB, основываясь на идеях, вынесенных из опыта работы с другими СУБД. Вместо этого полезно будет внимательно ознакомиться с документацией по этой базе данных и использовать при работе с ней те методы, на которые она рассчитана. Вот краткий обзор основных концепций IndexedDB:

▍Ограничения IndexedDB

Система IndexedDB разработана в расчёте на то, что её возможностей должно хватить для решения большинства задач хранения данных на стороне клиента. Понятно, что она не является универсальной системой, подходящей для любых сценариев использования. Вот несколько ситуаций, на которые она не рассчитана:

Вот сведения о поддержке IndexedDB в различных браузерах.

Поддержка IndexedDB различными браузерами

Выбор системы хранения данных

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

Итоги

Автор этого материала говорит, что в компании SessionStack используют различные API для хранения данных. Например, библиотека, интегрируемая в веб-приложения для сбора данных об их работе, использует куки и сессионное хранилище. Приложение, которое предназначено для воспроизведения того, что происходило на странице, использует куки-файлы для целей аутентификации пользователей.

Уважаемые читатели! Какими технологиями хранения данных на стороне клиента вы пользуетесь в своих веб-приложениях?

Источник