10 clientseitige Speicheroptionen und wann sie verwendet werden

Browserdatenspeicher und -Operationen, auch als Clientspeicher bezeichnet, sind nützlich, wenn Daten nicht benötigt werden oder nicht an einen Webserver gesendet werden können.

Szenarien für den Browserdatenspeicher und -betrieb gehören:

• Behalten Sie den Status der Client -Anwendung auf - wie der aktuelle Bildschirm, Eingabedaten, Benutzereinstellungen usw.
• Dienstprogramme, die auf lokale Daten oder Dateien mit strikten Datenschutzanforderungen zugreifen.
• Progressive Web Application (PWA), die offline funktioniert.

folgende zehn Browserdatenspeicheroptionen:

1. JavaScript -Variablen
2. DOM -Knotenspeicher
3. Webspeicher (LocalStorage und SessionStorage)
4. indexeddb
5. Cache -API (verwenden Sie AppCache nicht!)
6. Dateisystemzugriffs -API
7. Datei- und Verzeichniseintrag API
8. Cookie
9. Fenster.Name
10. websql

In diesem Artikel wird diese zehn verschiedenen Möglichkeiten zum Speichern von Browserdaten untersucht, die ihre Grenzen, Vor- und Nachteile und die besten Verwendungen jeder Technologie abdecken.

Vor dem Durchsuchen dieser Optionen sehen Sie sich die Datenpersistenz kurz an ...

Schlüsselpunkte

• JavaScript -Variable: Temporäre Daten sind am schnellsten, aber es wird gelöscht, wenn die Seite aktualisiert wird.
• DOM-Knotenspeicher: Ähnlich wie bei JavaScript-Variablen in Bezug auf Geschwindigkeit und Persistenz, ermöglicht jedoch den Zustandsspeicher in HTML-Elementen;
• Webspeicher (LocalStorage und SessionStorage): Geeignet für die anhaltende Speicherung kleiner Datenmengen (LocalStorage) oder SessionStorage (SessionStorage);
• IndexedDB: Beste für große Mengen strukturierter Daten, die bestehen müssen.
• zwischengespeicherte API: Idealerweise werden die Netzwerkantworten in PWA für die Offline -Verwendung gespeichert.
• Cookie: Nützlich für kleine Daten, die mit HTTP -Anfragen gesendet werden müssen.

Datenpersistenz

Normalerweise sind die von Ihnen gespeicherten Daten:

1. Beständigkeit : Es bleibt bis zum Löschen Ihres Codes oder
, oder
2. Volatilität
: Es bleibt bis die Browsersitzung endet, normalerweise, wenn der Benutzer die Registerkarte schließt.

Die tatsächliche Situation ist detaillierter.

Permanente Daten können jederzeit von Benutzern, Betriebssystemen, Browsern oder Plug-Ins blockiert oder gelöscht werden. Wenn sich der Browser der Kapazität nähert, die diesem Speichertyp zugewiesen wird, kann er entscheiden, ältere oder größere Elemente zu löschen.

Der Browser zeichnet auch den Seitenstatus auf. Sie können von der Website -Navigation abreisen und die Registerkarte zurückklicken und wieder eröffnen. Variablen und Daten, die nur als Sitzungssitzung betrachtet werden, sind weiterhin verfügbar.

1. JavaScript -Variablen

Metriken Anweisungen Die Kapazität ist nicht streng begrenzt, aber wenn Sie den Speicher ausfüllen Die schnellsten Optionen haben eine schlechte Beharrlichkeit: Daten werden vom Browser aktualisiert und gelöscht, um den Zustand in JavaScript -Variablen zu speichern, ist die schnellste und einfachste Option. Ich glaube, Sie brauchen kein Beispiel, aber ...

const
  a = 1,
  b = 'two',
  state = {
    msg:  'Hello',
    name: 'Craig'
  };

Profis:

• Einfach zu verwenden
• Schnell
• keine Serialisierung oder Deserialisierung
erforderlich

Nachteile:

• zerbrechlich: Erfrischen oder Schließen der Registerkarte wird alles löschen
• Skripte von Drittanbietern können globale Werte
überprüfen oder überschreiben.

Sie verwenden bereits Variablen. Sie können eine dauerhafte Speicherung des variablen Zustands bei der Seitentallation in Betracht ziehen.

2. DOM -Knotenspeicher

Indikator Anweisungen Die Kapazität ist nicht streng begrenzt, aber für große Datenmengen nicht geeignet Aktualisiert durch andere Skripte oder aktualisierte Löschen Die meisten DOM -Elemente (auf Seite oder im Speicher) können Werte in benannten Eigenschaften speichern. Es ist sicherer, Attributnamen zu verwenden, die mit Daten vorangestellt sind:

1. Attribute werden niemals die HTML -Funktionalität
zugeordnet haben
2. Sie können über das Dataset -Attribut anstelle der längeren .SetAttribute () und .GetAttribute () -Methoden auf die Werte zugreifen.

Werte werden als Zeichenfolgen gespeichert, daher kann eine Serialisierung und Deserialisierung erforderlich sein. Zum Beispiel:

// 定位<main>元素
</main>const main = document.querySelector('main');

// 存储值
main.dataset.value1 = 1;
main.dataset.state = JSON.stringify({ a:1, b:2 });

// 检索值
console.log( main.dataset.value1 ); // "1"
console.log( JSON.parse(main.dataset.state).a ); // 1

Profis:

• Sie können Werte in JavaScript oder HTML definieren - z. B.
• hilft dabei, den Zustand einer bestimmten Komponente zu speichern
• dom ist schnell! (Entgegen den Volksmeinungen)

Nachteile:

• zerbrechlich: Das Aktualisieren oder Schließen der Registerkarte löscht alles (es sei denn, der Wert wird vom Server in HTML gerendert)
Nur
• Zeichenfolgen: Serialisierung und Deserialisierung sind
erforderlich.
größeres DOM beeinflusst die Leistung
Drittanbieter-Skripte können Werte

überprüfen oder überschreiben

DOM -Knoten speichern langsamer als Variablen. Verwenden Sie es mit Vorsicht, wenn es nützlich ist, den Zustand einer Komponente in HTML zu speichern.

3. Webspeicher (LocalStorage und SessionStorage)

Indikator Anweisungen

Kapazität 5MB Lese-/Schreibgeschwindigkeitsynchronenbetrieb: Möglich So definieren Sie Namen/Wertpaare. Verwendung:

window.localStorage speichert persistente Daten und
window.SessionStorage behält nur Sitzungsdaten bei

Speicher oder Aktualisieren benannte Elemente mit .SetItem ():

localStorage.setItem('value1', 123);
localStorage.setItem('value2', 'abc');
localStorage.setItem('state', JSON.stringify({ a:1, b:2, c:3 }));

abrufen mit .getItem ():

const state = JSON.parse( localStorage.getItem('state') );

löschen Sie sie mit .RemoveItem ():

localStorage.removeItem('state')

Andere Eigenschaften und Methoden umfassen:

• .Length: Anzahl der gespeicherten Elemente
• .Key (n): Name des n -ten Schlüssels
• .clear (): Alle gespeicherten Elemente löschen

Ändern eines jeden Werts erhöht ein Speichereignis in anderen Browser -Registerkarten/Windows, die mit derselben Domäne verbunden sind. Ihre Bewerbung kann entsprechend antworten:

const
  a = 1,
  b = 'two',
  state = {
    msg:  'Hello',
    name: 'Craig'
  };

Profis:

• Einfacher Name/Wertpaar API
• Sitzung und persistente Speicheroptionen
• Good Browser Support

Nachteile:

Nur
• Zeichenfolgen: Serialisierung und Deserialisierung sind
erforderlich.
unstrukturierte Daten ohne Transaktionen, Indizes oder Suchvorgänge
Synchroner Zugriff beeinflusst die Leistung großer Datensätze

Webspeicher ist perfekt für einfachere, kleinere und temporäre Werte. Es ist nicht sehr geeignet, um große Mengen strukturierter Informationen zu speichern. Sie können jedoch Leistungsprobleme vermeiden, indem Sie Daten beim Entladen der Seite schreiben.

4. indexeddb

Anzeigen Anweisungen

Die Kapazität hängt vom Gerät ab. Mindestens 1 GB, aber bis zu 60% der verbleibenden Daten zur Lese-/Schreibgeschwindigkeit der Festplatte bleibt schnelle Persistenzdaten, bis die IndexedDB gelöscht wird, liefert eine ähnliche API auf niedriger Ebene, die NoSQL ähnlich ist, um große Datenmengen zu speichern. Der Speicher kann indiziert werden, kann mit Transaktionen aktualisiert und mit asynchronen Methoden durchsucht werden.

IndexedDB -API ist komplex und erfordert eine Ereignisverarbeitung. Die folgende Funktion öffnet eine Datenbankverbindung, wenn die Funktion des Namens, der Versionsnummer und der optionalen Upgrade -Funktion bestanden (wenn sich die Versionsnummer ändert):

// 定位<main>元素
</main>const main = document.querySelector('main');

// 存储值
main.dataset.value1 = 1;
main.dataset.state = JSON.stringify({ a:1, b:2 });

// 检索值
console.log( main.dataset.value1 ); // "1"
console.log( JSON.parse(main.dataset.state).a ); // 1

Der folgende Code stellt eine Verbindung zur MyDB -Datenbank her und initialisiert den Todo -Objektspeicher (ähnlich wie SQL -Tabellen oder MongoDB -Sammlungen). Anschließend definiert es einen automatischen Increment-Schlüssel mit dem Namen ID:

localStorage.setItem('value1', 123);
localStorage.setItem('value2', 'abc');
localStorage.setItem('state', JSON.stringify({ a:1, b:2, c:3 }));

Sobald die DB -Verbindung fertig ist, können Sie neue Datenelemente in einer Transaktion hinzufügen:

const state = JSON.parse( localStorage.getItem('state') );

Sie können Werte abrufen, z. B. das erste Element:

localStorage.removeItem('state')

Profis:

flexible Datenspeicherung mit maximalem Speicherplatz
Starke Transaktionen, Indizes und Suchoptionen
Good Browser Support

Nachteile:

Ein komplexer Rückruf und eine ereignisbasierte API

IndexedDB ist die beste Wahl für die zuverlässige Speicherung großer Datenmengen. Sie müssen jedoch eine Wrapper -Bibliothek wie IDB, Dexie.js oder JSstore verwenden.

5. cache api

Indikator Anweisungen

Die Kapazität hängt vom Gerät ab, aber Safari beschränkt jede Domäne auf 50 MB Lese-/Schreibgeschwindigkeit. Bietet Speicher für HTTP -Anforderungs- und Antwortobjektpaare bis zwei Wochen später in Safari. Sie können so viele Caches so viele erstellen, wie Sie eine beliebige Anzahl von Netzwerkdatenelementen speichern möchten.

Diese API wird häufig in Service -Mitarbeitern verwendet, um Netzwerkantworten für progressive Webanwendungen zu speichern. Wenn das Gerät vom Netzwerk getrennt wird, können die zwischengespeicherten Vermögenswerte wiederholt werden, damit die Webanwendung offline ausgeführt werden kann.

Der folgende Code speichert die Netzwerkantwort in einem Cache namens Mycache: <🎜>

const
  a = 1,
  b = 'two',
  state = {
    msg:  'Hello',
    name: 'Craig'
  };

Ähnliche Funktionen können Elemente aus dem Cache abrufen. In diesem Beispiel gibt es den Antwortkörpertext zurück:

// 定位<main>元素
</main>const main = document.querySelector('main');

// 存储值
main.dataset.value1 = 1;
main.dataset.state = JSON.stringify({ a:1, b:2 });

// 检索值
console.log( main.dataset.value1 ); // "1"
console.log( JSON.parse(main.dataset.state).a ); // 1

Profis:

• Speichern Sie eine Netzwerkreaktion
• kann die Leistung von Webanwendungen verbessern
• Erlauben Sie Webanwendungen, Offline auszuführen
• moderne versprechende API

Nachteile:

• nicht zum Speichern des Anwendungsstatus
geeignet
• Vielleicht weniger nützlich außerhalb von progressiven Webanwendungen
• Apple ist nicht freundlich zu PWA- und Cache -APIs

Die Cache -API ist die beste Wahl zum Speichern von Dateien und Daten, die aus dem Netzwerk abgerufen werden. Sie können es verwenden, um den Anwendungszustand zu speichern, es ist jedoch nicht für diesen Zweck konzipiert und es gibt bessere Optionen. 5.5 Appcache

Appcache ist der Vorgänger der Cache -API, die abgelaufen ist. Dies ist nicht die Speicherlösung, die Sie suchen. Hier gibt es nichts Gutes zu sehen. Bitte gehen Sie.

Dateisystemzugriffs -API

Metriken Anweisungen Die Kapazität hängt von der verbleibenden Festplattenspeicher -Lese-/Schreibgeschwindigkeit ab, die von den Daten des Dateisystems abhängen Browser zum Lesen, Schreiben, Ändern und Löschen von Dateien im lokalen Dateisystem. Der Browser wird in einer Sandbox -Umgebung ausgeführt, sodass der Benutzer einer bestimmten Datei oder einem bestimmten Verzeichnis Berechtigungen erteilen muss. Dadurch wird ein Dateisystem zurückgegeben, damit die Webanwendung Daten wie eine Desktop -Anwendung lesen oder schreiben kann. Die folgende Funktion speichert den Blob einer lokalen Datei:

Profis:

localStorage.setItem('value1', 123);
localStorage.setItem('value2', 'abc');
localStorage.setItem('state', JSON.stringify({ a:1, b:2, c:3 }));

Webanwendungen können sicher lokale Dateisysteme lesen und schreiben

• reduziert die Notwendigkeit, Dateien hochzuladen oder Daten auf dem Server zu verarbeiten
• Eine großartige Funktion von progressiven Webanwendungen
Nachteile:

Der Browser unterstützt minimal (nur Chrom)

• API kann
ändern
Diese Speicheroption ist für mich am aufregendsten, aber Sie müssen noch einige Jahre warten, bevor Sie sie zur Produktion verwenden können.

Datei- und Verzeichniseintrag API

Metriken Anweisungen Die Kapazität hängt von der verbleibenden Speicherplatz -Lese-/Schreibgeschwindigkeit ab. Unbekannte Persistenzdaten bleiben bis zur Löschung der Datei und der Verzeichniseintrags -API eine Sandbox bereitgestellt Dateisystem, das für Domänen verwendet werden kann, die Verzeichnisse und Dateien erstellen, schreiben, lesen und löschen. Profis:

Es kann einige interessante Verwendungszwecke geben

Nachteile:

Nicht standardmäßig, Inkompatibilität zwischen Implementierungen und Verhalten kann sich ändern.

mdn heißt deutlich:

Verwenden Sie diese Funktion nicht auf Produktionswebsites . Es wird mindestens ein paar Jahre dauern, bis die Unterstützung umfassend unterstützt wird.

8. Cookie

Indikator Anweisungen Kapazität 80 KB pro Domäne (20 Cookies, bis zu 4 KB pro Cookie) Schnelles Lese-/Schreibgeschwindigkeit und gute Haltbarkeit: Die Daten werden bis zum Aufbewahren Es sind gelöschte oder abgelaufene Cookies sind domänenspezifische Daten. Sie sind dafür bekannt, dass sie den Ruf der Menschen verfolgen, sind jedoch für jedes System, das den Serverstatus beibehalten, wie z. B. Anmeldung, unerlässlich. Im Gegensatz zu anderen Speichermechanismen werden Cookies normalerweise zwischen dem Browser und dem Server in jeder HTTP -Anforderung und -antwort übergeben. Beide Geräte können Cookie -Daten überprüfen, ändern und löschen.

document.cookie legt den Cookie -Wert in Client JavaScript fest. Sie müssen eine Zeichenfolge definieren, in der der Name und Wert durch ein gleiches Zeichen getrennt sind (=). Zum Beispiel:

const
  a = 1,
  b = 'two',
  state = {
    msg:  'Hello',
    name: 'Craig'
  };

Werte können keine Kommas, Semikolons oder Räume enthalten. Möglicherweise können comdeuricomponent () erforderlich sein:

// 定位<main>元素
</main>const main = document.querySelector('main');

// 存储值
main.dataset.value1 = 1;
main.dataset.state = JSON.stringify({ a:1, b:2 });

// 检索值
console.log( main.dataset.value1 ); // "1"
console.log( JSON.parse(main.dataset.state).a ); // 1

Andere Cookie -Einstellungen können mit Semikolon -Grenzen beigefügt werden, einschließlich:

; Domain =: Wenn nicht eingestellt, ist das Cookie nur in der aktuellen URL -Domäne erhältlich. Verwendung; path = mySite.com ermöglicht es, auf jeder Subdomain von mySite.com zu verwenden.
; Pfad =: Wenn nicht eingestellt, ist das Cookie nur im aktuellen Pfad und seinen Unterfassen erhältlich. Set; path =/ um einen beliebigen Pfad in der Domäne zuzulassen.
; max-agetal =: Cookie-Ablaufzeit (Sekunden)-zum Beispiel; max-altern = 60.
; läuft =: Cookie -Ablaufdatum - zum Beispiel; läuft = dhu, 04. Juli 2021 10:34:38 ​​UTC (verwenden Sie Datum.
; sicher: Der Keks wird nur über HTTPS übertragen.
;
; samesit =: steuert, ob eine andere Domäne auf Cookies zugreifen kann. Stellen Sie es auf LAX ein (Standard, Cookies teilen Sie die aktuelle Domäne frei), streng (blockiert das anfängliche Cookie, wenn Sie der Link aus einer anderen Domäne folgen) oder keine (unbegrenzt).

Beispiel: Stellen Sie ein Status Cookie ein, das nach 10 Minuten abläuft und in jedem Pfad zur aktuellen Domäne verwendet werden:

localStorage.setItem('value1', 123);
localStorage.setItem('value2', 'abc');
localStorage.setItem('state', JSON.stringify({ a:1, b:2, c:3 }));

document.cookie gibt eine Zeichenfolge zurück, die jedes Name und das Wertpaar enthält, das durch ein Semikolon getrennt ist. Zum Beispiel:

const state = JSON.parse( localStorage.getItem('state') );

Die Funktion unten analysiert die Zeichenfolge und konvertiert sie in ein Objekt, das ein Namenswertpaar enthält. Zum Beispiel:

localStorage.removeItem('state')

Profis:

Zuverlässige Möglichkeit, den Zustand zwischen Client und Server zu erhalten
Domäne und (optionale) Pfade nur
verwenden Sie max-Alter (Sekunden) oder Ablauf (Datum) für die automatische Ablaufregelung
• standardmäßig in der aktuellen Sitzung verwendet (setzen

Nachteile:

• Cookies werden oft von Browsern und Plugins blockiert (sie werden normalerweise in Sitzungs Cookies umgewandelt, damit die Website weiter funktionieren kann)
• ungeschickte JavaScript-Implementierung (es ist besser, Ihren eigenen Cookie-Handler zu erstellen oder eine Bibliothek wie JS-Cookie auszuwählen)
Nur
• Strings (erfordert Serialisierung und Deserialisierung)
• Speicherplatz ist begrenzt
• Cookies können von Drittanbieter-Skripten überprüft werden, es sei denn, Sie beschränken den Zugriff
• beschuldigt wegen Datenschutzverletzungen (regionale Gesetzgebung kann verlangen, dass Sie Warnungen vor nicht wesentlichen Cookies zeigen)
• Cookie-Daten werden an jede HTTP-Anforderung und -Anforderung beigefügt, die die Leistung beeinflussen kann (das Speichern von 50 KB Cookie-Daten und Anfordern von zehn 1-Byte-Dateien generiert eine Million Bytes Bandbreite)

Vermeiden Sie die Verwendung von Cookies, es sei denn, es gibt keine praktikable Alternative.

9. Fenster.Name

Metriken Anweisungen Kapazitätsänderungen, sollten jedoch in der Lage sein, mehrere Megabyte von Lese-/Schreibgeschwindigkeiten aufzunehmen. Die Daten zur Aufrechterhaltung der Sichtssitzung bleiben jedoch bis zum Fenster geschlossen, bis das Fenster geschlossen wird Die NAME -Eigenschaft setzt und erhält den Namen des Fenster -Browser -Kontextes. Sie können einen einzelnen String -Wert festlegen, der zwischen dem Auffrischen des Browsers oder dem Verknüpfen mit einem anderen Ort und dem Klicken zurück. Zum Beispiel:

const
  a = 1,
  b = 'two',
  state = {
    msg:  'Hello',
    name: 'Craig'
  };

Überprüfen Sie den Wert mit der folgenden Methode:

// 定位<main>元素
</main>const main = document.querySelector('main');

// 存储值
main.dataset.value1 = 1;
main.dataset.state = JSON.stringify({ a:1, b:2 });

// 检索值
console.log( main.dataset.value1 ); // "1"
console.log( JSON.parse(main.dataset.state).a ); // 1

Profis:

• Einfach zu verwenden
• Daten für nur Sitzung verfügbar

Nachteile:

Nur
• Zeichenfolgen: Serialisierung und Deserialisierung sind
erforderlich.
Seiten in anderen Feldern können Daten lesen, ändern oder löschen (verwenden Sie sie nicht für vertrauliche Informationen)

Fenster.Name wurde nie für die Datenspeicherung ausgelegt. Dies ist ein Trick und es gibt bessere Optionen für .

10. websql

Indikator Anweisungen Kapazität 5 MB pro Domänen lesen/schreiben langsame Persistenzdaten, bis das Löschen von WebsQL ein SQL-ähnlicher Datenbankspeicher ist, um Browser einzuführen. Beispielcode:

localStorage.setItem('value1', 123);
localStorage.setItem('value2', 'abc');
localStorage.setItem('state', JSON.stringify({ a:1, b:2, c:3 }));

Chrome und einige Versionen von Safari unterstützen diese Technologie, aber Mozilla und Microsoft lehnen sie ab und unterstützen stattdessen IndexedDB.

Profis:

• entwickelt für leistungsstarke Clientdatenspeicher und Zugriff
• vertraute SQL-Syntax, die häufig von serverseitigen Entwicklern
verwendet wird

Nachteile:

• Browserunterstützung ist begrenzt und es gibt Fehler
• Inkonsistenz zwischen SQL -Syntax zwischen Browsern
• asynchronen, aber ungeschickt Callback-basierte API
• schlechte Leistung

Verwenden Sie keine Websql! Es war keine praktikable Option, seit die Spezifikation von 2010 veraltet war.

Überprüfen Sie den Speicher

Speicher -API kann den verfügbaren Speicherplatz der APIs von Webspeichern, IndexedDB und Cache überprüfen. Alle Browser mit Ausnahme von Safari und IE unterstützen eine vielversprechende API, die eine .Sestimate () -Methode zur Berechnung von Quoten (den Raum für die Domäne) und die Verwendung (der verwendete Raum) bietet. Zum Beispiel:

const state = JSON.parse( localStorage.getItem('state') );

Es gibt zwei weitere asynchrone Methoden:

• .Persist (): Return true, wenn die Website die Erlaubnis hat, persistente Daten zu speichern,
• .Persisted (): Gibt true zurück, wenn die Website persistente Daten gespeichert hat.

Mit dem Anwendungsfeld im Browser -Entwickler -Tool (in Firefox genannt) können Sie LocalStorage, SessionStorage, IndexedDB, Websql, Cookies und Cache -Speicher anzeigen, ändern und löschen.

Sie können auch Cookie -Daten überprüfen, die in HTTP -Anforderung und Antwort -Header gesendet werden, indem Sie auf ein beliebiges Element im Webpanel des Entwickler -Tools klicken.

Storage Hotpot

Diese Speicherlösungen sind nicht perfekt, Sie müssen mehrere Lösungen in komplexen Webanwendungen einnehmen. Dies bedeutet, mehr APIs zu lernen. Aber es ist eine gute Sache, in jeder Situation eine Wahl zu haben - sagen wir natürlich, Sie können die richtige Option auswählen!

häufig gestellte Fragen zu lokalen Speicheralternativen

Was kann ich anstelle eines lokalen Speichers verwenden?

Bei der Suche nach Alternativen zum lokalen Speicher in der Webentwicklung können Optionen wie Sitzungsspeicher, Cookies und IndexedDB in Betracht gezogen werden. Der Sitzungsspeicher bietet einen temporären Speicher für Seitensitzungen, während Cookies kleine Daten sind, die mit jeder HTTP -Anforderung gesendet werden, die für die Sitzungsverwaltung und das Speichern von begrenzten Daten verwendet werden können. IndexedDB bietet eine leistungsstärkere Lösung für das Speichern strukturierter Daten auf der Client -Seite, sodass sie für Anwendungen geeignet sind, für die asynchrones Datenabruf erforderlich ist. Server-Seiten-Speicherlösungen (wie MySQL, PostgreSQL, MongoDB) oder Cloud-basierte Datenbanken (wie Firebase, AWS DynamoDB oder Google Cloud Firestore) können für eine breitere Datenspeicherung vorzuziehen oder wenn Sicherheit und Persistenz kritisch sind. Darüber hinaus bieten einige Client -Frameworks ihre eigenen staatlichen Verwaltungslösungen an, während Dienstangestellte Daten und Assets für Offline -Funktionen zwischenspeichern können.

Wann sollten Sie nicht den lokalen Speicher verwenden?

lokaler Speicher ist eine universelle Client -Speicherlösung, in einigen Fällen ist dies jedoch möglicherweise nicht die am besten geeignete Option. Erstens ist der lokale Speicher nicht für die Speicherung sensibler oder vertraulicher Informationen geeignet, da sie keine Verschlüsselungs- oder Sicherheitsmaßnahmen vorliegt, die sie für unbefugten Zugriff anfällig machen. Kritische Daten wie Passwörter oder persönliche Identitäten sollten mithilfe eines starken Sicherheitsprotokolls sicher auf der Serverseite gespeichert werden. Zweitens hat die lokale Lagerung eine begrenzte Kapazität, normalerweise etwa 5 bis 10 MB pro Domäne. Es ist nicht für Anwendungen geeignet, die große Datenmengen verarbeiten müssen. In diesem Fall sollten serverseitige Datenbanken oder leistungsfähigere Clientoptionen wie IndexedDB in Betracht gezogen werden, um größere Datensätze aufzunehmen. Schließlich kann ein lokaler Speicher zu Leistungsproblemen führen, insbesondere im Umgang mit großen Datensätzen, da er synchron ausgeführt wird und den Hauptfaden blockieren kann. Für leistungskritische Anwendungen können Sie asynchrone Speicherlösungen wie IndexedDB oder Implementierung von Speicher-Caching verwenden, um eine reibungslose Benutzererfahrung zu erhalten. Zusammenfassend ist die lokale Speicherung für die leichte, nicht sensitive Datenspeicherung wertvoll, die spezifischen Anforderungen des Projekts müssen bewertet werden. Für sensible Informationen, große Datensätze oder leistungskritische Anwendungen sollten alternative Speicherlösungen untersucht werden, um die Datensicherheit, Skalierbarkeit und die beste Benutzererfahrung sicherzustellen.

Was ist besser, LocalStorage oder SessionStorage?

Die Auswahl von LocalStorage und SessionStorage hängt hauptsächlich von der Dauer der Datenpersistenz und Ihrem spezifischen Anwendungsfall ab. LocalStorage ist eine bessere Wahl, wenn Sie Daten zwischen Browsersitzungen bestehen müssen. Es eignet sich zum Speichern von Daten wie Benutzerpräferenzen, Einstellungen oder Cache -Ressourcen, die an den Benutzer erhalten bleiben sollten, auch wenn der Benutzer den Browser schließt und später zur Website zurückkehrt. Seine Beharrlichkeit und eine größere Speicherkapazität machen es ideal für Szenarien, in denen eine langfristige Datenbindung erforderlich ist. SessionStorage hingegen ist ideal für Daten, die nur während der aktuellen Seitensitzung verfügbar sind. Wenn ein Benutzer einen Tab oder einen Browser schließt, werden die Daten automatisch gelöscht, um die Privatsphäre zu gewährleisten und das Risiko einer unbeabsichtigten Speicherung unnötiger Informationen zu verringern. Dies macht es ideal, um temporäre Daten wie Formdaten, CART -Inhalte oder Statusverwaltung in einer einzelnen Benutzerinteraktion zu verwalten.

Was ist eine Client -Datenbank?

Die

Client-Datenbank, auch als Front-End-Datenbank bezeichnet, ist eine Datenbank, die sich im Webanwendungs-Client befindet (normalerweise im Webbrowser des Benutzers) und wird dort ausgeführt. Es wird verwendet, um Daten auf Client -Geräten zu speichern und zu verwalten, Webanwendungen offline zu arbeiten, die Serverlast zu reduzieren und die Benutzererfahrung zu verbessern, indem die Notwendigkeit häufiger Serveranforderungen minimiert werden. Client -Datenbanken werden häufig in der Webentwicklung verwendet, um Daten direkt auf dem Gerät des Benutzers zu speichern und abzurufen. Eines der häufigsten Beispiele für Client-Datenbanken ist indexiert, eine JavaScript-API auf niedriger Ebene, die eine strukturierte Datenbank zum Speichern großer Datenmengen in einem Webbrowser bereitstellt. IndexedDB ermöglicht es Entwicklern, Daten zu erstellen, zu lesen, zu aktualisieren und zu löschen, wodurch sie für Anwendungen geeignet sind, für die Offline -Speicher und Verwaltung großer Informationsmengen erforderlich ist. Weitere Beispiele für Client-Datenbanken sind Webspeicher (LocalStorage und SessionStorage) zum Speichern kleiner Datenmengen sowie verschiedene In-Memory-Datenbanken, die in JavaScript für temporäre Datenspeicher während der Benutzersitzungen implementiert sind. Client -Datenbanken sind besonders nützlich für Webanwendungen wie progressive Webanwendungen (PWAs), bei denen die Funktionalität auch dann beibehalten werden muss, wenn der Benutzer offline ist oder eine begrenzte Internetverbindung hat. Sie ergänzen die serverseitige Datenbank, indem sie einen Mechanismus bereitstellen, um Daten lokal auf Benutzergeräten zu speichern und so die Latenz zu verringern und die Benutzererfahrung zu verbessern.

Was sind die verschiedenen Arten des Clientspeichers?

Es gibt viele Formen des Clientspeichers in der Webentwicklung, jeweils eigene Eigenschaften und Anwendungsfälle. Ein gängiger Typ ist der Webspeicher, der LocalStorage und SessionStorage umfasst. LocalStorage eignet sich zum Speichern kleiner Datenmengen, die in Browser -Sitzungen bestehen müssen, wodurch sie für Benutzereinstellungen oder Einstellungen geeignet sind. Stattdessen ist SessionStorage-Sitzungsbegrenzung und speichert Daten nur während einer einzelnen Seitensitzung, wodurch es für temporäre Daten ideal ist, z. B. Einkaufswagen-Inhalte oder Formulardaten, die während der Benutzerinteraktion mit Webseiten erforderlich sind. Eine weitere Option ist indexedDB, ein fortschrittlicheres Client -Datenbanksystem. IndexedDB bietet einen strukturierten Speicher für die Verwaltung großer Datenmengen auf Benutzungsgeräten. Es unterstützt asynchrones Datenabruf, Indexierung, Transaktionen und mehr. Damit ist es ideal für Anwendungen, die komplexe Datenverarbeitung und Offline -Funktionen wie progressive Webanwendungen (PWA) erfordern. Darüber hinaus sind Cookies kleine Datenfragmente, die auf dem Client -Gerät gespeichert und mit jeder HTTP -Anforderung an den Server gesendet werden können. Obwohl heute nicht in der allgemeinen Datenspeicherung verwendet werden, können Cookies dennoch für Aufgaben wie Sitzungsverwaltung, Benutzerauthentifizierung und Verfolgung der Benutzereinstellungen verwendet werden. Jede Art von Kundenspeicher verfügt über Vor- und Nachteile, und die Auswahl hängt von Ihren spezifischen Anforderungen wie Datengröße, Persistenzanforderungen und Anwendungsfällen ab.

Das obige ist der detaillierte Inhalt von10 clientseitige Speicheroptionen und wann sie verwendet werden. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!