Fonctionnement de JS: stockage

Lors de la conception d'une application Web, il est extrêmement important de choisir les bons outils pour le stockage local des données. Nous parlons d'un mécanisme qui vous permettra de stocker de manière fiable des informations, aidera à réduire la quantité de données transférées entre les parties serveur et client de l'application, et en même temps, cela n'aggravera pas la vitesse de réaction de l'application à l'exposition de l'utilisateur. Une stratégie bien pensée pour la mise en cache des données locales est essentielle au développement d'applications Web mobiles qui peuvent fonctionner sans connexion Internet. Les utilisateurs modernes se réfèrent de plus en plus à ces opportunités comme quelque chose de familier et attendu.



Aujourd'hui, dans la traduction de la partie 16 d'une série de documents consacrés à tout ce qui concerne JavaScript, nous parlerons des mécanismes de stockage côté client qui peuvent être utilisés dans le développement Web et du choix d'un système de stockage pour un projet spécifique.

Modèle de données

Un modèle de données définit l'organisation interne des données stockées. Il affecte tous les aspects du dispositif d'application Web, il contient des solutions, souvent compromettantes, dont dépendent l'efficacité de l'application et la capacité du système de stockage à résoudre ses tâches. Il n'y a pas de «meilleure» approche pour concevoir des modèles de données, il n'y a pas de solutions universelles qui conviennent à toutes les applications. Le choix du modèle de données est basé sur les caractéristiques et les besoins d'une application particulière. Considérez plusieurs modèles de stockage de données de base à partir desquels vous pouvez choisir quelque chose qui convient à un projet particulier.

• Un modèle de stockage de données structuré. Lorsque vous utilisez ce modèle, les données sont stockées dans des tables avec des champs prédéfinis. Cette approche est typique des systèmes de gestion de bases de données SQL. Ces systèmes sont bien adaptés pour fonctionner avec eux à l'aide de requêtes. IndexedDB est un exemple bien connu d'un entrepôt de données de navigateur structuré (bien qu'il s'agisse d'un SGBD NoSQL).
  
• Modèle de stockage clé / valeur. Les entrepôts de données organisés sous forme de paires clé / valeur, et les SGBD NoSQL qui leur sont associés, donnent au développeur la possibilité de stocker des données non structurées et de les récupérer dans le magasin par leurs clés uniques. Ces stockages sont similaires aux tables de hachage dans le sens où ils vous permettent d'organiser l'accès aux données indexées de types opaques. Un bon exemple de stockage clé / valeur de valeurs est l'API Cache dans le navigateur et le SGBD Apache Cassandra côté serveur.
  
• Un modèle pour stocker des données dans des séquences d'octets. En utilisant ce modèle simple, les données sont stockées sous forme de séquences d'octets de longueur variable. La tâche d'organisation interne de ces données est entièrement résolue au niveau de l'application. Ce modèle est utilisé dans les systèmes de fichiers et autres entrepôts de données organisés hiérarchiquement comme les systèmes de stockage cloud.
  

Méthodes de stockage persistant des données disponibles pour le navigateur

Les méthodes de stockage utilisées dans les applications Web peuvent être analysées en termes de durée de stockage persistante de ces données.

• Stockage de données dans la session. Les données de cette catégorie ne sont stockées que tant qu'une session Web spécifique existe ou que l'onglet du navigateur est actif. L'API SessionStorage est un exemple du mécanisme de stockage des données de session.
  
• Stockage des données sur l'appareil sans référence à la durée de vie de la session. Ces données sont stockées sur un appareil spécifique et entre les sessions, par exemple, lorsque vous fermez l'onglet du navigateur avec la page d'application Web, elles ne sont pas supprimées. L'API Cache est un exemple du mécanisme de stockage des données d'application Web sur les appareils.
  
• Stockage permanent des données à l'aide du stockage global. Cette approche implique le stockage de données qui ne sont pas perdues entre les sessions et qui ne sont pas liées à un appareil spécifique. Ces données peuvent être partagées entre différents appareils par les utilisateurs. Par conséquent, il s'agit du moyen le plus fiable et à long terme de stocker des données. Ces données ne peuvent pas être stockées sur l'appareil lui-même, ce qui signifie qu'une sorte de stockage sur serveur doit être utilisé pour organiser un tel système de stockage de données. Nous n'entrerons pas dans le détail, car notre tâche principale est d'examiner comment stocker les données des applications Web sur les appareils.
  

Évaluation du stockage côté client

Aujourd'hui, il existe de nombreuses API de navigateur qui vous permettent d'organiser le stockage des données. Nous allons en examiner certains et les comparer afin de vous faciliter le choix de la bonne API.

Pour commencer, nous allons cependant nous attarder sur quelques questions générales qui devraient être prises en compte avant de choisir une technologie spécifique pour le stockage des données. Bien sûr, tout d'abord, vous devez comprendre comment votre application sera utilisée, comment son support sera organisé et comment il est prévu de la développer. Dans le même temps, même si vous avez des réponses claires à ces questions, vous pouvez enfin accéder à plusieurs options pour les systèmes de stockage de données, parmi lesquelles vous devrez choisir la plus appropriée. Voici à quoi vous devez faire attention lors du choix d'un système de stockage:

• Prise en charge du navigateur. Il convient de garder à l'esprit qu'il est préférable de préférer une API standardisée et développée. Ils ont, d'une part, une durée de vie assez longue, et d'autre part, ils sont pris en charge par de nombreux navigateurs. De plus, des API similaires ont généralement une bonne documentation et une communauté de développeurs active.
  
• Prise en charge des transactions. Parfois, il est important que lorsque vous travaillez avec le référentiel, les ensembles d'opérations associées aient la propriété d'atomicité, c'est-à-dire que l'exécution de l'ensemble d'opérations réussisse si toutes les opérations réussissent, ou si au moins l'une d'entre elles échoue, elle échoue. Les bases de données prennent généralement en charge cette fonctionnalité en utilisant un modèle de transaction qui peut être utilisé pour regrouper les mises à jour de données associées en blocs arbitraires.
  
• Fonctionnement synchrone ou asynchrone. Certaines API de stockage de données sont synchrones, dans le sens où les opérations d'enregistrement ou de chargement de données à partir de ces API bloquent le thread actif jusqu'à ce que la demande correspondante soit terminée. L'utilisation d'API synchrones peut entraîner le blocage du thread principal, ce qui peut entraîner des «freins» de l'interface utilisateur. Par conséquent, si possible, essayez d'utiliser des API asynchrones.
  

Comparaison de stockage

Dans cette section, nous allons examiner certains des systèmes de stockage existants disponibles pour les développeurs Web et les comparer en fonction des indicateurs décrits ci-dessus.

API	Modèle de données	Méthodologie de stockage	Prise en charge du navigateur	Prise en charge des transactions	Synchrone ou asynchrone
Système de fichiers	Séquence d'octets	Périphérique	52%	Non	Asynchrone
Stockage local	Clé / valeur	Périphérique	93%	Non	Synchrone
Stockage de session	Clé / valeur	La session	93%	Non	Synchrone
Cookie	Données structurées	Périphérique	100%	Non	Synchrone
Cache	Clé / valeur	Périphérique	60%	Non	Asynchrone
Indexeddb	Modèle hybride	Périphérique	83%	Oui	Asynchrone

Parlons maintenant davantage de ces méthodes de stockage des données.

API FileSystem

Grâce à l'utilisation de l'API FileSystem , les applications Web peuvent fonctionner avec une zone sélectionnée du système de fichiers local de l'utilisateur. L'application peut afficher le contenu du stockage, créer des fichiers, effectuer des opérations de lecture et d'écriture.

Cette API comprend les parties principales suivantes:

• Mécanismes de gestion des fichiers et de lecture des fichiers: File/Blob , FileList , FileReader
  
• Mécanismes pour créer des fichiers et y écrire des données: Blob , FileWriter
FileWriter

• Mécanismes de travail avec les répertoires et le système de fichiers: DirectoryReader , FileEntry / DirectoryEntry , LocalFileSystem
  

L'API FileSystem n'est pas standard, elle ne doit donc pas être utilisée en production, car elle ne fonctionnera pas pour tous les utilisateurs. Les différentes implémentations de cette API peuvent varier considérablement et il est très probable qu'elles puissent changer à l'avenir.

L'interface du filesystem de cette API est utilisée pour représenter le système de fichiers. L'accès aux objets correspondants peut être obtenu via la propriété du système de fichiers . Certains navigateurs proposent des API supplémentaires pour créer et gérer des systèmes de fichiers.

Cette interface ne donne pas accès à la page Web au système de fichiers de l'utilisateur. Au lieu de cela, il vous permet de travailler avec quelque chose comme un disque virtuel, qui se trouve dans le bac à sable créé par le navigateur. Si votre application a besoin d'accéder au système de fichiers de l'utilisateur, vous devrez utiliser d'autres mécanismes.

Une application Web peut demander l'accès au système de fichiers virtuel en appelant window.requestFileSystem() :

 // :    Google Chrome 12: window.requestFileSystem = window.requestFileSystem || window.webkitRequestFileSystem; window.requestFileSystem(type, size, successCallback, opt_errorCallback) 

Si vous appelez requestFileSystem() pour la première fois, un nouveau référentiel sera créé pour votre application. Il est important de se rappeler qu'il s'agit d'un stockage isolé, c'est-à-dire qu'une application Web ne peut pas fonctionner avec le stockage créé par une autre application.

Après avoir accédé au système de fichiers, vous pouvez effectuer la plupart des opérations standard avec des fichiers et des répertoires.

FileSystem API FileSystem est très différente des autres systèmes similaires utilisés par les applications Web, car elle vise à résoudre les tâches de stockage de données sur le client, qui ne sont pas très bien résolues par les outils de base de données. En général, ce sont des applications qui fonctionnent avec de gros fragments de données binaires ou qui échangent des données avec des applications externes au navigateur.

Les options d'utilisation de l'API FileSystem sont les suivantes:

• Systèmes de téléchargement de données. Lorsqu'un utilisateur sélectionne un fichier ou un dossier à télécharger sur un serveur, ces données sont copiées sur un stockage isolé local, puis, en partie, envoyées au serveur.
  
• Applications qui gèrent de grandes quantités de données multimédias - jeux, lecteurs de musique.
  
• Applications d'édition de son et d'image qui fonctionnent sans connexion Internet ou utilisent un grand cache local pour accélérer le travail. Les données avec lesquelles ces applications fonctionnent sont une séquence d'octets qui peut être assez volumineuse. Le stockage de ces données doit permettre de les écrire et de les lire.
  
• Lecteurs vidéo hors ligne. Ces programmes doivent télécharger des fichiers volumineux qui peuvent être consultés sans connexion Internet. Cela peut être nécessaire lors de la diffusion de données en continu et pour organiser un système pratique de déplacement dans le fichier.
  
• Clients de messagerie hors ligne. Ces programmes peuvent télécharger des fichiers joints à des e-mails et les enregistrer localement.
  

C'est ainsi que les navigateurs prennent en charge l'API FileSystem .


Prise en charge de l'API FileSystem par les navigateurs

API LocalStorage

L'API LocalStorage , ou stockage local, vous permet de travailler avec l'objet Storage de l'objet Document , en tenant compte du principe de la même source. Les données ne sont pas perdues entre les sessions. L'API LocalStorage similaire à l'API SessionStorage , stockage de session, la différence est que les données dans le stockage de session sont supprimées après la fin de la session de page et les données dans le stockage local sont stockées de manière permanente.

Veuillez noter que les données situées dans le stockage local ou dans le stockage de session sont liées à la source de la page, qui est déterminée par la combinaison du protocole, de l'hôte et du port.
Voici LocalStorage informations de prise en charge du LocalStorage navigateur LocalStorage pour différents navigateurs.


Prise en charge de l'API LocalStorage par les navigateurs

API SessionStorage

L'API SessionStorage vous permet de travailler avec un objet de session de stockage . L'API SessionStorage similaire à l'API LocalStorage dont nous avons parlé ci-dessus. La différence entre eux, comme déjà mentionné, réside dans le temps de stockage des données, à savoir, dans le cas de SessionStorage données sont stockées aussi longtemps que dure la session. Il dure jusqu'à ce que le navigateur soit ouvert, tandis qu'il reste après le rechargement de la page. L'ouverture d'une page dans un nouvel onglet ou une nouvelle fenêtre lancera une nouvelle session, ce qui est différent du comportement des cookies de session. En même temps, tout en travaillant avec SessionStorage et avec LocalStorage , il faut se rappeler que les données de ces stockages sont liées à la source de la page.

Voici une prise en charge du navigateur pour l'API SessionStorage :


Prise en charge de l'API SessionStorage du navigateur

API de cookies

Les cookies (cookies, cookies web, cookies de navigateur) sont de petites informations que le serveur envoie au navigateur. Le navigateur peut les enregistrer et les envoyer au serveur, en les utilisant lors de la génération de requêtes. Ils sont généralement utilisés pour identifier une instance de navigateur spécifique à partir de laquelle les demandes sont envoyées. Par exemple, pour que l'utilisateur, après être entré dans le système, y reste. Un cookie est une sorte de système de stockage d'informations sur l'état de session pour le protocole HTTP qui traite chaque requête, même provenant du même navigateur, comme complètement indépendante des autres.

Les cookies sont utilisés pour résoudre trois tâches principales:

• Gestion de session. L'utilisation de cookies est basée sur des mécanismes tels que les systèmes d'accès aux applications Web, les paniers d'achat dans les magasins en ligne, le stockage des points gagnés dans les jeux par navigateur. Il s'agit de stocker tout ce que le serveur doit savoir pendant que l'utilisateur travaille avec lui.
  
• Personnalisation Les cookies sont utilisés pour stocker des données sur les préférences de l'utilisateur, sur les thèmes qu'il choisit pour concevoir le site et sur d'autres choses similaires.
  
• Surveillance des utilisateurs. Les cookies enregistrent et analysent le comportement des utilisateurs.
  

À une certaine époque, les cookies étaient utilisés comme entrepôt de données à usage général. Bien qu'il s'agisse d'une manière tout à fait normale d'utiliser les cookies, en particulier lorsqu'ils étaient le seul moyen de stocker des données sur un client, il n'est pas recommandé de les utiliser en tant que tels à notre époque, préférant une API plus moderne. Les cookies sont envoyés à chaque demande, de sorte qu'ils peuvent dégrader les performances (en particulier sur les appareils mobiles).

Il existe deux types de cookies:

• Cookies de session. Ils sont supprimés après la session. Les navigateurs Web peuvent utiliser la technique de récupération de session, grâce à laquelle la majorité des cookies de session sont stockés en permanence, à la suite de la session, ils sont enregistrés même après la fermeture et le redémarrage du navigateur et l'ouverture de la page correspondante.
  
• Cookies permanents. Les cookies persistants ne perdent pas leur pertinence après la session. Ils ont une certaine période de stockage, qui est déterminée soit par une certaine date (attribut Expires ) ou une certaine période de temps (attribut Max-Age ).
  

Veuillez noter que les informations confidentielles ou importantes ne doivent pas être stockées dans les cookies ni transmises dans les cookies HTTP, car tout le mécanisme de travail avec les cookies est intrinsèquement dangereux.

Si nous parlons de la prise en charge des cookies, alors, comme vous l'avez probablement déjà compris, tous les navigateurs les prennent en charge.

API de cache

L'interface Cache fournit un mécanisme de stockage de données pour les paires mises en cache d'objets Request / Response . Cette interface est définie dans les mêmes spécifications que les travailleurs de service, mais elle est accessible non seulement aux travailleurs. L'interface de Cache est également disponible dans la portée de l'objet window ; il n'est pas nécessaire de l'utiliser uniquement avec des travailleurs de service.

Une certaine source peut avoir plusieurs objets de Cache nommés. Le développeur est responsable de l'implémentation de la façon dont son script (par exemple, dans un technicien de service ) maintient le cache à jour. Les éléments stockés dans le cache ne sont pas mis à jour jusqu'à ce qu'une demande explicite de mise à jour soit faite, leur période de stockage n'expire pas, ils ne peuvent être supprimés du cache. Afin d'ouvrir un objet de cache nommé, vous pouvez utiliser la commande CacheStorage.open () , après quoi vous pouvez accéder aux commandes de gestion du cache en y accédant.

De plus, le développeur est responsable de l'effacement périodique du cache. Chaque navigateur a une limite codée en dur sur la taille du cache alloué à une source spécifique. Vous pouvez utiliser l'API StorageEstimate pour connaître le quota de cache estimé.

Le navigateur fait tout ce qui est en son pouvoir pour maintenir une certaine quantité d'espace de cache disponible, mais il peut supprimer le cache pour une source. En règle générale, le navigateur supprime l'intégralité du cache ou ne le concerne pas du tout. Lorsque vous utilisez des caches, n'oubliez pas de les distinguer selon les versions de vos scripts, par exemple, y compris la version du script dans le nom du cache. Ceci est fait afin d'assurer le fonctionnement sûr de différentes versions de scripts avec un cache. Les détails peuvent être trouvés ici .

L'interface CacheStorage fournit un stockage pour les objets Cache . Voici les tâches dont cette interface est responsable:

• Fournir une liste de tous les caches nommés avec lesquels un travailleur de service peut travailler, ou un autre type de travailleur. Vous pouvez également travailler avec le cache via l'objet fenêtre .
  
• Prend en charge le mappage entre les noms de chaîne et les objets correspondants de type Cache .
  

Pour obtenir une instance de l'objet Cache , utilisez la commande CacheStorage.open () .

Pour savoir si un objet Request particulier est la clé d'un objet Cache géré par CacheStorage , utilisez la méthode CacheStorage.match () .

CacheStorage pouvez accéder à CacheStorage via la propriété globale des caches .

API IndexedDB

L'API IndexedDB est un SGBD qui vous permet de stocker des données à l'aide d'un navigateur. Étant donné que cela vous permet de créer des applications Web capables de travailler avec des ensembles de données complexes même sans connexion Internet, ces applications peuvent se sentir aussi bien avec et sans connexion au serveur. IndexedDB est utilisé dans les applications qui doivent stocker de grandes quantités de données (par exemple, une telle application peut être quelque chose comme un catalogue de films d'un certain service de location), et qui n'ont pas besoin de maintenir une connexion constante au réseau pour un fonctionnement normal (par exemple, ce sont des clients de messagerie , gestionnaires de tâches, cahiers, etc.).

Ici, nous accorderons à IndexedDB un peu plus d'attention que les autres technologies de stockage de données client, car, d'une part, d'autres API sont plus largement connues, et d'autre part, car le SGBD IndexedDB devient de plus en plus populaire en raison de la complexité toujours croissante des applications Web. .

▍ Mécanismes internes IndexedDB

L'API IndexedDB vous permet d'enregistrer des données d'objet à l'aide de la «clé» dans la base de données et de les lire. Toutes les modifications apportées à la base de données se produisent dans les transactions. Comme la plupart de ces solutions, IndexedDB suit une politique de source unique . Par conséquent, une application ne peut accéder qu'aux données appartenant à son propre domaine, mais pas aux données d'autres domaines.

IndexedDB est une API asynchrone qui peut être utilisée dans la plupart des contextes, y compris les travailleurs Web . Auparavant, il existait une version synchrone de cette API destinée aux travailleurs Web, mais elle a été supprimée de la spécification car elle n'était pas particulièrement intéressante pour les développeurs Web.

IndexedDB avait un concurrent face à la base de données WebSQL, mais le travail sur cette norme a été interrompu par le W3C il y a de nombreuses années. Bien qu'IndexedDB et WebSQL soient des solutions pour stocker des données sur le client, leur fonctionnalité est différente. WebSQL est un SGBD relationnel et IndexedDB est un système basé sur des tables indexées.

Vous ne devez pas commencer à travailler avec IndexedDB, sur la base des idées tirées de l'expérience avec d'autres SGBD. Au lieu de cela, il sera utile de lire attentivement la documentation de cette base de données et d'utiliser les méthodes avec lesquelles elle est conçue. Voici un bref aperçu des concepts de base d'IndexedDB:

• Les bases de données IndexedDB stockent les données au format clé / valeur. Les valeurs peuvent être des objets structurés complexes et les clés peuvent être des propriétés de ces objets. Les index peuvent être créés en fonction de n'importe quelle propriété de l'objet, ce qui peut accélérer la recherche de données et simplifier leur tri. Les clés sont également des objets binaires.
  
• Le SGBD IndexedDB est construit sur la base d'un modèle transactionnel. Toutes les opérations effectuées avec la base de données se produisent toujours dans le contexte de la transaction . Par conséquent, par exemple, vous ne pouvez pas exécuter des commandes ou ouvrir des curseurs en dehors des transactions. De plus, les transactions sont confirmées automatiquement; elles ne peuvent pas être confirmées manuellement.
  
• L'API IndexedDB, pour la plupart, est asynchrone. Cette API ne fournit pas les données demandées, les renvoyant simplement en réponse à une commande. Au lieu de cela, lors de la demande de données, vous devez passer une fonction de rappel à la méthode correspondante. L'approche synchrone n'est utilisée ni pour enregistrer les données dans la base de données ni pour les charger à partir de celle-ci. Au lieu de cela, l'application effectue une requête de base de données décrivant l'opération requise. Une fois l'opération terminée, un événement se produit qui informe l'application que l'opération s'est terminée ou non. Cette approche n'est pas particulièrement différente de l'API XMLHttpRequest ou de nombreux autres mécanismes JavaScript.
  
• IndexedDB utilise de nombreuses requêtes. Les demandes sont des objets qui reçoivent des événements concernant le succès ou l'échec d'une opération. Ils ont les propriétés onsuccess et onerror auxquelles vous pouvez affecter des écouteurs pour les événements correspondants, ainsi que les readyState , result , errorCode , qui peuvent être analysées pour connaître l'état de la demande.
  
• IndexedDB est une base de données orientée objet. Ce n'est pas un SGBD relationnel dont les tables sont des collections de lignes et de colonnes. Cette fonctionnalité fondamentale affecte la façon dont vous concevez et créez des applications à l'aide d'IndexedDB.
  
• IndexedDB n'utilise pas SQL. Ce SGBD applique des requêtes d'index qui renvoient des curseurs utilisés pour travailler avec des ensembles de données qui sont des résultats de requête. Si vous n'êtes pas familier avec les systèmes NoSQL, jetez un œil à ce matériel.
  
• Les stockages IndexedDB appliquent une stratégie de source unique. Une source est une combinaison du domaine, du protocole et de l'URL du port du document dans lequel le script est exécuté. Chaque source ne peut fonctionner qu'avec son propre ensemble de bases de données, tandis que chaque base de données a un nom unique qui l'identifie dans les bases de données d'une source.
  

▍ Limitations de IndexedDB

Le système IndexedDB est conçu dans l'espoir que ses capacités devraient être suffisantes pour résoudre la plupart des tâches de stockage de données côté client. Il est clair qu'il ne s'agit pas d'un système universel adapté à tout cas d'utilisation. Voici quelques situations pour lesquelles il n'est pas conçu:

• Tri des données selon les caractéristiques des différentes langues. Pas dans toutes les langues, les chaînes sont triées de la même manière et IndexedDB ne prend pas en charge le tri en fonction des caractéristiques des différentes langues. Dans le même temps, bien que la base de données ne puisse pas effectuer un tel tri, les informations obtenues à partir de la base de données peuvent être triées par l'application.
  
• Sync L'API n'a pas été conçue en tenant compte de la possibilité de synchroniser la base de données locale avec le serveur. Une telle synchronisation, bien sûr, est possible, mais le développeur devra mettre en œuvre les mécanismes appropriés de manière indépendante.
  
• Recherche plein texte. L'API IndexedDB ne prend pas en charge quelque chose comme l'instruction LIKE de SQL.
  

De plus, lorsque vous travaillez avec IndexedDB, n'oubliez pas que le navigateur peut supprimer la base de données dans les cas suivants:

• L'utilisateur a donné une commande pour supprimer les données. De nombreux navigateurs ont des sections de paramètres, dans lesquelles il existe des outils qui permettent à l'utilisateur de supprimer toutes les données stockées pour un site Web, y compris les cookies, les signets, les mots de passe enregistrés et les données IndexedDB.
  
• Le navigateur fonctionne en mode anonyme. Ces modes sont appelés différemment dans différents navigateurs. Dans Chrome, c'est le «mode incognito», dans Firefox, c'est le «mode privé». Une fois la session anonyme terminée, le navigateur supprimera la base de données.
  
• Débordement de disque ou atteinte d'une limite prédéterminée.
  
• Corruption des données.
  

En général, on peut noter que les développeurs de navigateurs s'efforcent de ne pas supprimer les bases de données IndexedDB sauf en cas de nécessité absolue.

Voici des informations sur la prise en charge d'IndexedDB dans divers navigateurs.


Prise en charge d'IndexedDB par divers navigateurs

Choisir un système de stockage

Comme déjà mentionné, compte tenu des besoins de l'application, il est préférable de choisir les systèmes de stockage qui prennent en charge un large navigateur et fonctionnent en mode asynchrone, ce qui minimise leur impact sur l'interface utilisateur. Ces critères conduisent tout naturellement aux technologies suivantes:

• Pour le stockage hors ligne d'informations, utilisez l'API Cache . Il est disponible dans n'importe quel navigateur prenant en charge les travailleurs de service , qui sont nécessaires pour créer des applications Web pouvant fonctionner sans connexion Internet. L'API Cache est un choix idéal pour stocker certaines ressources associées à une page.
  
• Pour stocker des données qui forment l'état de l'application ou certaines informations créées par les utilisateurs, utilisez IndexedDB. Cette technologie, par rapport à la mise en cache, prend en charge davantage de navigateurs, ce qui augmente la capacité des utilisateurs d'applications basées sur IndexedDB à travailler hors ligne.
  

Résumé

, SessionStack API . , , - , . , , , - .

Chers lecteurs! -?