Utilizza SQLite per gestire tutte le tue esigenze di spazio di archiviazione in modo efficiente sul web.
SQLite è un popolare sistema di gestione di database relazionali open source, leggero e incorporato. Molti sviluppatori lo utilizzano per archiviare i dati in modo strutturato e facile da usare. A causa delle sue dimensioni ridotte e dei requisiti di memoria ridotti, SQLite viene spesso utilizzato come motore di database in dispositivi mobili, applicazioni desktop e browser web.
Una delle caratteristiche principali di SQLite è che si tratta di un database serverless, il che significa che non richiede un processo del server separato per il funzionamento. Il database viene invece archiviato in un unico file sul dispositivo dell'utente, il che ne semplifica l'integrazione nelle applicazioni.
SQLite basato su Web Assembly
Esistono diverse versioni non ufficiali di SQLite basate su WebAssembly (Wasm), che consentono di utilizzarlo nei browser web, ad esempio sql.js. Il sottoprogetto sqlite3 WASM/JS è il primo impegno ufficialmente associato al progetto SQLite che esegue build Wasm della biblioteca elementi consolidati della famiglia di deliverable SQLite supportati. Gli obiettivi concreti di questo progetto includono:
- Associazione di un'API sqlite3 di basso livello il più simile possibile a quella C in termini di utilizzo.
- Un'API orientata agli oggetti di livello superiore, più simile a sql.js e implementazioni di tipo Node.js, che parla direttamente con l'API di basso livello. Questa API deve essere utilizzata dallo stesso thread dell'API di basso livello.
- Un'API basata su worker che comunica con le API precedenti tramite messaggi worker. Questa API è progettata per essere utilizzata nel thread principale, con le API di livello inferiore installate in un thread di lavoro e per comunicare con queste tramite i messaggi di lavoro.
- Una variante basata su Promise dell'API Worker che nasconde completamente all'utente gli aspetti della comunicazione tra thread.
- Supporto per lo spazio di archiviazione lato client permanente tramite le API JavaScript disponibili, incluso il file system privato dell'origine (OPFS).
Utilizzo di SQLite Wasm con il backend di persistenza del file system privato di Origin
Installazione della libreria da npm
Installa il pacchetto @sqlite.org/sqlite-wasm da npm con il seguente comando:
npm install @sqlite.org/sqlite-wasm
File system privato di Origin
Il file system privato di Origin (OPFS, parte dell'API File System Access) è integrato con una piattaforma speciale che offre un accesso molto efficiente ai dati. Questa nuova piattaforma si differenzia da quelle esistenti perché offre l'accesso in scrittura esclusivo e in-place ai contenuti di un file. Questa modifica, insieme alla possibilità di leggere in modo coerente le modifiche non annullate e alla disponibilità di una variante sincrona su worker dedicati, migliora significativamente le prestazioni e sblocca nuovi casi d'uso.
Come puoi immaginare, l'ultimo punto degli obiettivi del progetto, il supporto per l'archiviazione permanente lato client utilizzando le API JavaScript disponibili, prevede rigorosi requisiti di prestazioni per la conservazione dei dati nel file di database.
È qui che entra in gioco il file system privato dell'origine e, più specificamente, il metodo
createSyncAccessHandle()
degli oggetti
FileSystemFileHandle. Questo metodo restituisce una promessa che si risolve in un oggetto
FileSystemSyncAccessHandle
che può essere utilizzato per leggere e scrivere in modo sincrono in un file. La natura sincrona di questo metodo offre vantaggi in termini di prestazioni, ma pertanto è utilizzabile solo all'interno di web worker dedicati per i file all'interno del file system privato di origine, pertanto il thread principale non può essere bloccato.
Impostazione delle intestazioni richieste
Tra gli altri file, l'archivio SQLite Wasm scaricato contiene i file sqlite3.js
e sqlite3.wasm, che costituiscono la compilazione di sqlite3 WASM/JS. La directory jswasm contiene i componenti principali di sqlite3 e la directory di primo livello contiene app di dimostrazione e di test. I browser non pubblicano file Wasm da URL file://, pertanto tutte le app create con questo metodo richiedono un server web e questo server deve includere le seguenti intestazioni nella risposta quando pubblica i file:
Cross-Origin-Opener-Policyimpostato sull'istruzionesame-origin, che isola il contesto di navigazione esclusivamente ai documenti della stessa origine. I documenti multiorigine non vengono caricati nello stesso contesto di navigazione.Cross-Origin-Embedder-Policyimpostato sulla direttivarequire-corp, in modo che un documento possa caricare solo risorse dalla stessa origine o risorse contrassegnate esplicitamente come caricabili da un'altra origine.
Il motivo di queste intestazioni è che SQLite Wasm dipende da SharedArrayBuffer e l'impostazione di queste intestazioni fa parte dei suoi requisiti di sicurezza.
Se ispezioni il traffico con DevTools, dovresti trovare le seguenti informazioni:
Speedtest
Il team di SQLite ha eseguito alcuni benchmark sulla propria implementazione WebAssembly rispetto all'API SQL web deprecata. Questi benchmark mostrano che SQLite Wasm di solito è veloce quanto SQL web. A volte è un po' più lento, a volte un po' più veloce. Leggi tutti i dettagli nella pagina dei risultati.
Esempio di codice di inizio
Come accennato in precedenza, SQLite Wasm con il backend di persistenza del sistema di file privato di Origin deve essere eseguito da un contesto di worker. La buona notizia è che la libreria si occupa automaticamente di tutto questo e puoi utilizzarla direttamente dal thread principale.
import { sqlite3Worker1Promiser } from '@sqlite.org/sqlite-wasm';
(async () => {
try {
console.log('Loading and initializing SQLite3 module...');
const promiser = await new Promise((resolve) => {
const _promiser = sqlite3Worker1Promiser({
onready: () => {
resolve(_promiser);
},
});
});
console.log('Done initializing. Running demo...');
let response;
response = await promiser('config-get', {});
console.log('Running SQLite3 version', response.result.version.libVersion);
response = await promiser('open', {
filename: 'file:worker-promiser.sqlite3?vfs=opfs',
});
const { dbId } = response;
console.log(
'OPFS is available, created persisted database at',
response.result.filename.replace(/^file:(.*?)\?vfs=opfs$/, '$1'),
);
await promiser('exec', { dbId, sql: 'CREATE TABLE IF NOT EXISTS t(a,b)' });
console.log('Creating a table...');
console.log('Insert some data using exec()...');
for (let i = 20; i <= 25; ++i) {
await promiser('exec', {
dbId,
sql: 'INSERT INTO t(a,b) VALUES (?,?)',
bind: [i, i * 2],
});
}
console.log('Query data with exec()');
await promiser('exec', {
dbId,
sql: 'SELECT a FROM t ORDER BY a LIMIT 3',
callback: (result) => {
if (!result.row) {
return;
}
console.log(result.row);
},
});
await promiser('close', { dbId });
} catch (err) {
if (!(err instanceof Error)) {
err = new Error(err.result.message);
}
console.error(err.name, err.message);
}
})();
Demo
Guarda il codice riportato sopra in azione nella demo. Assicurati di controllare il codice sorgente su Glitch. Tieni presente che la versione incorporata di seguito non utilizza il backend OPFS, ma lo fa quando apri la demo in una scheda separata.
Eseguire il debug del file system privato di origine
Per eseguire il debug dell'output del file system privato dell'origine di SQLite Wasm, utilizza l'estensione di Chrome OPFS Explorer.
Dopo aver installato l'estensione, apri Chrome DevTools, seleziona la scheda OPFS Explorer e potrai controllare cosa scrive SQLite Wasm nel Origin Private File System.
Se selezioni uno dei file nella finestra Esplora OPFS in DevTools, puoi salvarlo sul disco locale. Puoi quindi utilizzare un'app come SQLite Viewer per ispezionare il database, in modo da verificare che SQLite Wasm funzioni effettivamente come promesso.
Ricevere assistenza e fornire feedback
SQLite Wasm è sviluppato e gestito dalla community SQLite. Ricevi assistenza e fornisci feedback cercando nel forum di assistenza e pubblicando post. La documentazione completa è disponibile sul sito SQLite.