Мэтью Сеттер — профессиональный технический писатель и страстный разработчик веб-приложений. Он также является основателем Malt Blue , сообщества профессионалов по разработке веб-приложений на PHP и специалистов по разработке облачных решений PHP — изучающих разработку облачных вычислений через призму PHP. Вы можете связаться с ним в Twitter , Facebook , LinkedIn или Google+ в любое время.
Недавно я обсуждал альтернативу Cookies с введением HTML5 или веб-хранилища . Я взглянул на то, что это такое и почему это такая отличная альтернатива (сильно пороченым) куки.
На случай, если вы пропустили это, вот краткое резюме. Local_ и SessionStorage предоставляют гораздо более эффективный способ хранения информации на стороне клиента в браузере. Более того, у них нет накладных расходов, которые делают Cookies, поскольку они не включены в запросы страниц. Мы рассмотрели, как это работает, потенциальные последствия для безопасности, поддержку браузера и многое другое.
Но Local- и SessionStorage — не единственные доступные варианты, когда мы стремимся повысить сложность веб-приложений, которые мы разрабатываем и поставляем сегодня. С HTML5 W3C предоставляет еще один стандарт, который может быть больше того, что вы ищете, особенно если вы поклонник технологий на основе NoSQL. Эта опция — IndexedDB .
Итак, в этой серии мы рассмотрим, что такое IndexedDB, каковы его преимущества и недостатки, и где он будет хорошо соответствовать вашим потребностям в разработке. В следующей части мы закончим с примером приложения, чтобы вы могли понять, как оно работает.
Обзор технологии
IndexedDB является альтернативой (в настоящее время не рекомендуется) стандартной базе данных WebSQLW3C(WebSQL). Он был представлен около 23 апреля 2009 года. Это описание из Википедии:
«… API веб-страницы для хранения данных в базах данных, которые могут быть запрошены с использованием варианта SQL»
Как он говорит на олове, WebSQL приносит для разработки приложений на стороне клиента полную мощь SQL . Основанный на SQLite , он позволяет нам использовать один из фундаментальных навыков, которыми мы обладаем в нашем инструментарии разработки — разработку баз данных — как на стороне клиента, так и на стороне сервера.
18 ноября 2010 года W3C принял решение больше не поддерживать стандарт. Это произошло из-за разногласий со стороны ряда поставщиков, включая Mozilla и Microsoft, о том, как это должно быть практически реализовано, и неполной поддержки браузеров. В результате IndexedDB был представлен в качестве альтернативного стандарта для хранения веб-данных.
Однако IndexedDB — это не база данных браузера, а хранилище объектов . Это позволяет приложениям проектировать, хранить и манипулировать объектами без стерилизации, а также дает возможность проводить высокопроизводительный поиск по ним.
Как я упоминал ранее, это очень похоже на базы данных NoSQL, такие как mongoDB и CouchDB . Объекты создаются и обрабатываются в JavaScript, а затем сохраняются и обновляются в хранилище объектов.
Но это не совсем то же самое, что, скажем, стандартный скрипт PHP, Ruby или Python, создающий и сохраняющий объекты. Есть несколько ключевых моментов, которые нужно знать и помнить при использовании
Операции требуют транзакций
Каждая операция, которую вы выполняете при использовании IndexedDB, должна выполняться внутри транзакции. Будь то чтение информации из хранилища объектов, манипулирование данными в нем или изменение его структуры.
Транзакции могут иметь три режима:
|
Режим |
Описание |
| только для чтения (снимок) | Уметь читать хранилища объектов базы данных, не имея возможности что-либо изменить. |
| читай пиши | Уметь читать и записывать хранилища объектов в базе данных, не имея возможности изменять ее структуру. |
| versionchange | Уметь изменять структуру, добавлять и удалять хранилища объектов в базе данных, а также управлять индексами на них. |
Операции асинхронные
Вот в чем разница. С SQL вы запускаете запрос и получаете результат обратно. С IndexedDB вы запускаете транзакцию и настраиваете обратный вызов для обработки успеха или неудачи транзакции, который вы можете проверить позже. Вы не запускаете запрос и не ждете результата, такого как получение списка объектов, соответствующих индексу.
Если вы знакомы с jQuery, вы поймете, о чем я говорю. Если нет, взгляните на следующий код:
var jqxhr = $.ajax( "http://www.newrelic.com" )
.done(function() { alert("success"); })
.fail(function() { alert("error"); })
.always(function() { alert("complete"); });
С помощью приведенного выше кода мы делаем запрос ajax на newrelic.com . Затем мы устанавливаем три обработчика или обратные вызовы ; один для готовых, неудачных и всегда событий. Мы также делаем это в IndexedDB. Посмотрите на образец ниже:
// open the library data store
var request = indexedDB.open("library");
request.onsuccess = function(e) {
newrelic.indexedDB.getAllbooksList();
};
request.onerror = function(e) {
console.log("Error Opening Object Store. : ", e);
};
Здесь мы делаем запрос на открытие библиотеки хранилища данных. Если запрос выполнен успешно, мы запускаем функцию getAllbooksList, которая, в свою очередь, следует аналогичному шаблону. Если запрос не выполняется, мы регистрируем причину.
Индексы и курсоры
Продолжая аналогию с базой данных, объекты в хранилище объектов могут иметь один или несколько индексов для ускорения поиска данных. Создать их довольно просто, как показано в этом коде из Mozilla Development Network (MDN):
// This is what our customer data looks like.
const customerData = [
{ ssn: "444-44-4444", name: "Bill", age: 35, email: "[email protected]" },
{ ssn: "555-55-5555", name: "Donna", age: 32, email: "[email protected]" }
];
// Create an objectStore to hold information about our customers. We're
// going to use "ssn" as our key path because it's guaranteed to be
// unique.
var objectStore = db.createObjectStore("customers", { keyPath: "ssn" });
// Create an index to search customers by name. We may have duplicates
// so we can't use a unique index.
objectStore.createIndex("name", "name", { unique: false });
С помощью курсоров мы можем перебирать данные, которые мы получаем из хранилища объектов. Мы также можем использовать индекс для ограничения данных, которые мы получаем. В приведенном ниже примере, также из MDN, мы выполняем запрос типа ‘getall’:
var customers = [];
objectStore.openCursor().onsuccess = function(event) {
var cursor = event.target.result;
if (cursor) {
customers.push(cursor.value);
cursor.continue();
}
else {
alert("Got all customers: " + customers);
}
};
Поддержка браузера
К сожалению, это еще не все хорошие новости. В настоящее время IndexedDB поддерживается только следующими браузерами:
|
браузер |
Версия |
| Mozilla Firefox |
10 |
| Гугл Хром |
23 |
| IE версия |
10 |
Поскольку WebSQL устарела, вполне вероятно, что поддержка IndexedDB будет продолжать расти со временем, так как спецификация становится более усовершенствованной. Чтобы узнать, какие именно браузеры (и их версии) поддерживают его, попробуйте на caniuse.com .
Хотя Safari, Chrome и Opera по-прежнему поддерживают WebSQL — и технически вы можете разрабатывать приложения с его помощью — это не очень хорошая идея. Некоторые, однако, предлагают средний уровень с использованием библиотеки-обертки, позволяющей вам иметь оба лучших мира.
преимущества
1. Новый стандарт
Благодаря большой поддержке со стороны W3C, Mozilla, Microsoft и Google, IndexedDB быстро становится стандартом. Вполне вероятно, что он будет вокруг в течение достаточно долгого времени, а это значит, что вы можете надежно развиваться против него. Более того, он предлагает ощущение стабильности и независимости от поставщиков, чего нет в WebSQL.
2. Используйте объекты — не SQL
Кроме того, Indexed DB позволяет вам работать с объектами, которые наилучшим образом соответствуют потребностям и проектам вашего приложения (тогда как WebSQL требовал, чтобы вы хорошо понимали SQL.)
Недостатки
1. Отсутствие поддержки браузера.
На этом этапе основным недостатком является отсутствие поддержки браузера. Да, он уже доступен в последних версиях Firefox и Chrome и будет в IE 10. Но он доступен только в полной версии IE 10 и только в Windows 8. А поскольку IE 10 был выпущен только В последнее время пройдет некоторое время, прежде чем станет доминирующей версией IE.
Хорошей новостью является то, что Chrome и Firefox составляют около 54% используемых браузеров. Смотрите это на графике ниже от StatCounter :
Где это хорошо подходит?
Как я уже говорил, IndexedDB хорошо подходит, если ваши потребности в данных на стороне клиента более сложны, чем то, что может обеспечить Local / SessionStorage (т.е. вы ищете не просто хранилище ключей / значений в вашем приложении).
Да, вы можете использовать функции JavaScript (такие как JSON.stringify и JSON.parse) для управления информацией, хранящейся в нем. Но он не предлагает вам гибкость и мощь, которые обеспечивает IndexedDB. Поэтому, если вам нужен слой хранения, который предлагает более высокую производительность, дублирует значения ключей или эффективный способ поиска по сохраненным данным, тогда используйте IndexedDB. Но если ваши потребности проще, используйте Session и LocalStorage. Помните, ваши потребности должны определять ваш выбор.
Это правильный выбор?
Было много споров за и против WebSQL и IndexDB. Лично я не считаю WebSQL плохой технологией, но я считаю IndexedDB лучшим выбором. Недавно я читал блог Пола Харрисона, и его три балла за IndexedDB резюмируют, почему я считаю, что это лучший выбор:
* SQL — это совершенно другая система, не связанная с языками, в которые она обычно встроена.
* Неопытным программистам легко внедрить недостатки безопасности в свои операторы SQL
* Неопытным программистам легко создавать слишком сложные запросы, которые системы баз данных считают невозможными обработать в течение разумного периода времени.
В этой статье он поддерживает WebSQL, и я не хочу цитировать его здесь вне контекста. Но, по крайней мере, для меня веб-приложения становятся все более сложными, и было бы неправильно брать технологию, которая предшествовала сети, и пытаться встраивать ее в нее. Я считаю, что лучший выбор — это оторваться от прошлого и обеспечить уровень хранения данных, более соответствующий его потребностям. И это то, что я считаю IndexedDB.
Заключение
Итак, у вас есть это. IndexedDB станет одним из двух ключевых новых стандартов для хранения данных на стороне клиента в ближайшие годы. Это позволяет нам хранить сложные объекты, которые мы создаем и которыми манипулируем в JavaScript, в сочетании с приличной производительностью индекса при поиске хранимой информации.
Мы рассмотрели преимущества и недостатки и коснулись того, является ли он или WebSQL правильным стандартом на будущее. Так что вы думаете об этом? Считаете ли вы, что это подходит для будущего разработки веб-приложений? Или вы считаете, что WebSQL был бы лучшим выбором? Выскажите свое мнение в комментариях. Мы хотим знать, что вы думаете.
Для интересной дискуссии о том, должен ли WebSQL или IndexedDB быть стандартом для веб-разработчиков, ознакомьтесь с этой веткой на странице Google+ Кевина Дангура (Mozilla). Это делает для некоторого интересного чтения с множеством мнений.