This article is shared under a Creative Commons Attribution 4.0 International license, BY Troland.

See Github addresses in updates to this serieshere.

This is Chapter 16 on how JavaScript works.

An overview of the

When designing web applications, it is important to choose the right storage mechanism for the local device. A good storage engine can help developers store data efficiently, reduce transmission bandwidth, and improve program responsiveness. Proper storage and caching strategies are a core part of building a mobile offline web experience, and more and more users take it for granted that they can use mobile web applications offline.

In this chapter, we’ll discuss the various storage apis and services available and provide some advice on how to choose the right storage engine when building web applications.

The data model

The data storage model determines how the data is organized internally. This affects the design of the entire web application and calculates the cost of obtaining a high-performance web application and solving its problems. There is no better technology or one-size-fits-all solution because all problems are engineering related problems. So, let’s look at the alternative data models:

  • Structured: It stores data in tables with predefined fields. As a typical SQL-based database management system, it is well adapted to flexible and dynamic data query. IndexedDB is a good example of a browser-side structured database.
  • Key/value type: Key/value data stores and relational NoSQL databases allow developers to store and retrieve unstructured data (that is, data from fields of non-predefined data types) through unique key indexes. A key/value data store is like a hash table store, meaning it allows access to indepth data types of the index for a certain amount of time. Good examples of key/value data storage are the browser-side Cache API and server-side Apache Cassandra.
  • Byte stream: This simple model stores data as fixed length, obfuscates byte variables of strings, and lets the application layer control its internal data organization. This model is especially suitable for file storage and other hierarchical bloB data. Typical examples of byte stream storage include file systems and cloud storage devices.

persistence

The data storage method of web application can be analyzed by the storage time of data:

  • Session persistence: Data is valid only when a single web session or browser TAB is active, but not when closed. An example of a persistent Session data store is the Session Storage API.
  • Device persistence: This type of data is stored for cross-session and browser tabs/Windows on the specified device. An example of a device persistent storage mechanism is the Cache API.
  • Global persistence: This type of data is stored across sessions and devices. Therefore, it is the most compatible data persistence solution. It is not stored on the device, which means that the data needs to be retrieved from the server storage. Since we are only talking about device-specific datastore, we will only mention server-side datastore briefly.

Client-side data persistence

Today, there are a number of browser apis available for storing data. These methods are discussed in detail here, and then compared to make it easy for developers to choose the right data storage solution.

However, there are a few things developers need to consider before choosing how to store data first. Of course, the first thing you have to do is figure out how you’re going to use your web application and then maintenance and performance tuning. Even if you have a plan in mind, there may be only a few alternatives. Here are some things to consider:

  • Browser support – Standardized and well-organized apis are preferred because they are immutable and compatible. These apis are also well documented and have an active developer community.
  • Transactions – Sometimes, transactions are critical to the success or failure of the atomization of the associated set of data store operations. Traditional databases implement this function using a transaction model in which related data updates are divided into arbitrary units.
  • Synchronous/asynchronous – A few storage apis are synchronous, meaning that a request to store or retrieve data blocks the currently active thread until the data request finishes. Using the synchronous datastore API blocks the main thread and renders the application interface dead. Use asynchronous storage apis whenever possible.

contrast

Here, let’s take a look at the apis currently available to web developers and compare them using the dimensions described above.

File system API

With the FileSystem API, web applications can create, read, manipulate, and write files from the sandbox of a user’s local FileSystem.

The interface consists of the following parts:

  • Read and manipulate files:File/Blob.FileList.FileReader
  • Creating and writing files:Blob().FileWriter
  • Accessing directories and file systems:DirectoryReader.FileEntry/DirectoryEntry.LocalFileSystem

The file system API is not a standard API. It is not compatible, so be sure not to use it in a production environment. Implementations by browser vendors will vary greatly and the API may change in the future.

File and directory entry API File system is used to represent a file system. These objects can be retrieved from the filesystem property of any filesystem entry. A few browsers provide additional apis to create and manipulate file systems.

This interface does not allow developers to access the user’s file system. Instead, developers get a virtual disk in the browser sandbox. To access a user’s file system, install the Chrome plug-in.

Get the file system

A web application can call window.requestFilesystem () to access the sandbox file system. :

The file system has been prefixed as of Google Chrome 12: window.requestFileSystem = window.requestFileSystem || window.webkitRequestFileSystem; window.requestFileSystem(type, size, successCallback, opt_errorCallback)
Copy the code

A new local store is created the first time the requestFileSystem() method is called. Note that the file system is sandboxed, meaning that web applications cannot access other applications’ files.

After gaining access to the file system, developers can perform most of the normal file system operations on files and directories.

FileSystem differs from other storage strategies in that it is designed to cater for situations where a database does not handle client storage well. Typically, programs are used to process large binary blobs files or to share data with programs outside of the browser context.

The following is a good example of using FileSystem:

  • Resumable tool – When selecting a file or file directory to upload, copies the file into the sandbox and uploads the shard one at a time.
  • Video games, music, or other programs with a lot of media files
  • Audio/image editors that provide offline access or local caching for better performance – data blobs tend to be very large and read-write
  • Offline video players – which need to download large files for later viewing or quick track tracking – buffering
  • Offline web mail client – Download attachments and store them locally

The following is the current browser support for the API:

Local storage

The localStorage API allows developers to access the Storage object of the document source. Stored data remains valid across multiple browser sessions. LocalStorage is similar to sessionStorage except that data stored in localStorage has no expiration date, whereas data stored in sessionStorage is lost when the page session ends – that is, when the page is closed.

Both localStorage and sessionStorage store their data only in a specific page source, the so-called page source contains protocol, host name and port.

The following is the current browser support for the API:

Session storage

The sessionStorage property allows developers to access the sessionStorage object of the current source. SessionStorage is similar to localStorage as outlined earlier. The only difference is that data stored in localStorage has no expiration date whereas data stored in sessionStorage is lost at the end of the page session. The duration of a page session is when the browser opens and when the page reloads and resumes. Opening a new page or window in a new TAB causes a new session to be reinitiated, which doesn’t work the same way session cookies do.

Note that whether data is stored in sessionStorage or localStorage is only valid in the specified page source.

The following is the current browser support for the API:

Cookies

The so-called cookie(web cookie, browser cookie) refers to a small piece of data sent by the user’s server to the client. The browser stores it and sends it to the server on the next request. Typically, it is used to tell whether two requests are coming from the same client – for example, to keep the user logged in. It logs stateful information for the stateless HTTP protocol.

Cookies have three main uses:

  • Session management – login, shopping cart, game points, or any other data that needs to be stored on the server.
  • Personalization – user parameters, skins and other Settings
  • Monitor – Record and analyze user behavior

Cookies once dominated client-side storage solutions. This is the best option when it is the only solution for client-side storage, and it is now recommended to use modern storage apis for client-side data. Cookies are attached every time a request is sent, which can affect performance (especially when requesting data on a mobile end).

There are two types of cookies:

  • Session cookie- Expires when the user closes the browser. Web browsers can use session recovery techniques to solidify most session cookies as if the browser had not been closed.
  • Permanent cookie- As opposed to client shutdown expiration, permanent cookies expire at a specified expiration time or after a specified time (max-age).

Be careful not to store credentials or sensitive information in cookies because of their inherently insecure defect mechanisms.

However, cookies are arguably the most compatible solution.

Cache

The Cache interface is the storage mechanism for caching request/response objects. Note that the Cache interface can be used in the window scope as well as workers. Although the Cache is defined in the service worker thread specification, it does not necessarily have to be used with the service worker thread.

A single source can have multiple named cache objects. The developer only needs to implement how to handle the update cache in a script (such as in a service worker thread). Objects in the cache are not updated unless requested by display, and will not expire unless they are deleted. Use cachestorage.open () to open the named cache object, and then call any cache method to maintain the cache.

Developers need to periodically clear cached entries. Each source has a limited amount of cached data on the browser side. Use StorageEstimate to estimate cache quota utilization. The browser tries to manage disk space, but it may delete cached data from a specified source. The browser may or may not delete all data from the specified source. Remember to use names for script versioning and only work on safe versions of scripts. See Deleting Old Caches for more information.

The CacheStorage interface represents Cache object storage.

Interface:

  • Provide a home directory for all named caches accessible to serviceworkers, other worker threads, or the window scope (caches defined in the ServiceWorker thread are not meant to be used only with worker threads)
  • Maintains a mapping between character names and Cache objects

Use cachestorage.open () to create a Cache instance.

Use cachestorage.match () to check whether the specified Request is the key of the Cache object in the CacheStorage object.

Use the global Caches property to access CacheStorage.

IndexedDB

IndexedDB is a client-side persistent data storage solution. It allows developers to create query-rich web applications that can run online or offline, regardless of network conditions.

IndexedDB is suitable for large data stores (e.g., commercial library DVD catalogs) and web applications that do not need to be connected to the Internet (e.g., mail clients, to-do lists, and notes).

Since you are familiar with other storage apis, this article will take a closer look at IndexedDB. In addition, IndexedDB is becoming increasingly popular as web applications become more complex.

With IndexedDB principle

IndexedDB allows developers to store and retrieve an object using keys. All operations on the database occur within a transaction. Like other web storage schemes, IndexedDB follows the same origin policy. Therefore, data cannot be accessed across domains but can only be accessed under the same domain name.

You can use this asynchronous API on most contexts including web service threads. IndexedDB also had a synchronous version for web threads, but it was removed from the specification because the community was not keen on it.

IndexedDB also had a rival specification called WebSQL database, which has been deprecated by the W3C. Although IndexedDB and WebSQL are both storage solutions, they do not function the same. A WebSQL database is a relational database access system, while IndexedDB is just an indexed table system.

Do not copy other types of databases and take IndexedDB for granted. Instead, read the documentation carefully. Here are the core concepts developers need to know:

  • An IndexedDB database stores key-value pairs-values that can be complex structural objects and keys that can be properties of those objects. Developers can use any property of an object to create indexes for quick searches, such as enumeration sorts. Keys can also be binary objects.
  • IndexedDB is built on a transactional data model – all operations in IndexedDB occur in a transactional context. Therefore, developers cannot execute commands or open cursors outside of a transaction. Similarly, transactions can only be committed automatically, not manually.
  • ** Most IndexedDB is asynchronous **- THE API does not return data as a value. Instead, you pass in a callback function to process the return value. That is, the developer does not synchronously store values into the database or retrieve values directly from the database. In contrast, making a request represents a database operation. The developer is notified when the data processing is complete, and the event type the developer is listening for is notified if the data operation was successful. This is much the same way XMLHttpRequest (or so many other JavaScript related things) works.
  • IndexedDB uses a large number of requests – requests are objects that receive the success or failure events mentioned earlier. They contain the onSuccess and onError attributes, as well as readyState, Result, errorCode, and other attributes used to tell the status of the request.
  • IndexedDB is object-oriented -IndexedDB is not a relational database with tables representing a collection of columns and columns. This huge difference affects how developers design and build web applications.
  • IndexedDB does not use structured query language (SQL)- it uses a query on the index to create a cursor that can be used to traverse the result set. If you are not familiar with NoSQL systems, you can read the Wikipedia article on NoSQL.
  • IndexedDB also applies the same origin policy – a source is a document containing the domain name, application layer protocol, and URL port address, where scripts are executed. Each source has its associated database set. Each database has a unique identity in the source.

IndexedDBlimitations

IndexedDB is designed to accommodate most client storage situations. However, it is not designed to handle the following situations:

  • Internationalized sort – Not all languages arrange strings the same way, so internationalized sort is not supported. Although the database cannot store data in a specified international order, developers can read the data in the database and arrange the data themselves.
  • Synchronization – THE API is not designed to synchronize server data. Developers must write their own code to synchronize the client indexedDB database with the server database.
  • Full text retrieval – There is no equivalent of the LIKE operator in SQL in this API.

Also, it is important to note that the browser will clear the database when:

  • User-initiated purge requests – Many browsers allow users to clear data for a specified site, including cookies, bookmarks, stored passwords, and IndexedDB data.
  • Browser in Private mode – Some browsers have “private Browsing” (Firefox) and “Traceless browsing” (Chrome) modes. The database is cleared at the end of the session.
  • The disk capacity or disk quota is exceeded. Procedure
  • Data corruption…

While reality and browser capabilities are changing rapidly, browser manufacturers are moving toward preserving data as best they can.

Choose the appropriate storage API

As stated earlier, it is best to maximize UI responsiveness by using compatible apis whenever possible and providing an asynchronous invocation model. These standards naturally lead to the following technology options:

  • Use the Cache API to operate offline storage. The API is available in browsers that support service worker threading capabilities necessary to create offline applications. The Cache API is great for arranging associated resources with known urls.
  • Use IndexedDB to store program state and user-generated content. This allows users to use applications offline in more browsers than those that only support the Cache API.

reference

  • Developers.google.com/web/fundame…
  • Developer.mozilla.org/en-US/docs/…
  • Developer.mozilla.org/en-US/docs/…

, recruiting

Toutiao is hiring! Send resume to [email protected], you can take the fast internal push channel, long-term effective! The JD of the international PGC department is as follows: c.xiumi.us/board/v5/2H… , can also be pushed inside other departments!

See Github addresses in updates to this serieshere.