Что такое IndexedDB

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

Хороший короткий ответ на интервью:

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

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

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

IndexedDB хранит значения через structured clone. Можно сохранять обычные объекты, массивы, даты, Blob и другие поддерживаемые типы без ручного превращения всего в строку. Плюс можно делать индексы по полям, а не проходить всю коллекцию руками.

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

В IndexedDB есть важный жизненный цикл. Сначала вы открываете базу по имени и версии. Если версия выросла, браузер вызывает onupgradeneeded. Там можно создать object stores и индексы. После успешного открытия вы работаете с данными через transaction.

function openAppDb() {
  return new Promise((resolve, reject) => {
    const request = indexedDB.open("app-db", 1);

    request.onupgradeneeded = () => {
      const db = request.result;

      if (!db.objectStoreNames.contains("drafts")) {
        const store = db.createObjectStore("drafts", { keyPath: "id" });
        store.createIndex("updatedAt", "updatedAt");
      }
    };

    request.onsuccess = () => resolve(request.result);
    request.onerror = () => reject(request.error);
    request.onblocked = () => reject(new Error("Database upgrade is blocked by another tab"));
  });
}

async function saveDraft(draft) {
  const db = await openAppDb();
  const tx = db.transaction("drafts", "readwrite");
  const store = tx.objectStore("drafts");

  store.put({ ...draft, updatedAt: Date.now() });

  return new Promise((resolve, reject) => {
    tx.oncomplete = () => {
      db.close();
      resolve();
    };
    tx.onerror = () => {
      db.close();
      reject(tx.error);
    };
    tx.onabort = () => {
      db.close();
      reject(tx.error);
    };
  });
}

В этом примере важен не синтаксис, а контракт. Схема создается в upgrade flow, запись идет внутри transaction, а вызывающий код получает ошибку, если данные не сохранились. Соединение закрывается после операции, чтобы не мешать будущему upgrade в другой вкладке. Без этого легко показать пользователю "черновик сохранен", хотя запись упала.

В React или Next.js не вызывайте такой код во время render и не ждите от SSR доступа к локальной базе пользователя. Запускайте чтение после маунта или по действию пользователя. Показывайте loading и проверяйте, что ответ не устарел, прежде чем обновлять state.

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

Вторая ловушка - забыть, что API асинхронный и событийный. Если вы делаете optimistic UI, заранее решите, что произойдет при ошибке. Например, откатить карточку, показать retry, оставить черновик в очереди или подсветить конфликт.

Третья ловушка - обновить UI результатом старого чтения. Пользователь мог уйти на другой экран, выбрать другой документ или начать новый запрос. В компоненте нужен флаг актуальности, отмена на уровне вашего слоя данных или проверка id перед setState. Иначе IndexedDB создаст такой же race condition, как медленный сетевой запрос.

Четвертая ловушка - путать IndexedDB с Cache API. Для PWA они часто дополняют друг друга. Cache API хранит HTTP responses и хорошо работает с service worker. IndexedDB удобнее для доменных данных, метаданных, очередей отправки и поиска.

IndexedDB не делает данные секретными. Если в приложении есть XSS, вредный скрипт может получить доступ к тем же браузерным API, что и ваш код. Поэтому хранение токена в IndexedDB не является полноценной защитой. На интервью лучше сказать спокойно. Безопасность зависит от всей модели, включая защиту от XSS, CSP, cookie strategy и серверные ограничения.

С квотами тоже не стоит называть одно точное число для всех браузеров. Правильнее сказать, что лимиты зависят от браузера, устройства, свободного места и режима хранения. Для крупных данных нужно обрабатывать ошибку записи, показывать понятный UX и иногда использовать navigator.storage.persist(), если приложению действительно нужен более устойчивый storage.

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

Если хотите звучать практично, добавьте пример из UI. Например, вы сохранили бы в IndexedDB черновики формы или список задач для offline-режима, но после восстановления сети синхронизировали бы их с сервером и обработали конфликты. Такая формулировка показывает, что вы думаете не только про API, но и про состояние продукта.