Dodano obsługę SQLite WASM do korzystania z DBMS w przeglądarce internetowej

L Deweloperzy SQLite opracowują projekt do wdrożenia możliwość skompilowania biblioteki do pośredni kod WebAssembly który można uruchomić w przeglądarce internetowej i nadaje się do organizowania pracy z bazą danych z poziomu aplikacji webowych w języku JavaScript.

Cel z projektu jest dostarczenie funkcjonalnego linku JavaScript który jest identyczny pod względem funkcjonalności z API SQLite. Deweloperzy stron WWW mają do dyspozycji wysokopoziomowy interfejs obiektowy do pracy z danymi w stylu sql.js lub Node.js, opakowujący niskopoziomowe API C oraz API oparte na mechanizmie Web Worker pozwalające na tworzenie asynchronicznych kontrolery działające w osobnych wątkach.

Aby ukryć złożoność wątków w interfejsie API opartym na Web Worker, Wariant interfejs programistyczny oparty o mechanizm Obietnica.

Dane, które aplikacje internetowe przechowują w wersji SQLite WASM, mogą znajdować się w bieżącej sesji (utracone po ponownym załadowaniu strony) lub utrwalone po stronie klienta (utrzymywane w wielu sesjach).

W celu trwałego przechowywania, backendy zostały przygotowane do umieszczania danych w lokalnym systemie plików za pomocą OPFS (Origin-Private FileSystem, rozszerzenie interfejsu API dostępu do systemu plików, obecnie dostępne tylko w przeglądarkach opartych na WebKit i Chromium) i lokalnej pamięci przeglądarki opartej na interfejsach API window.localStorage i window.sessionStorage.

Podczas korzystania z localStorage/sessionStorage dane są mapowane do odpowiednich magazynów klucza/wartości, podczas gdy w przypadku korzystania z OPFS istnieją dwie opcje: symulacja wirtualnego FS za pomocą WASMFS i oddzielna implementacja sqlite3_vfs, która oferuje warstwę VFS opartą na SQLite. .

Kompilator Emscripten służy do budowania SQLite w reprezentacji WASM. Wynikiem są pliki sqlite3.js i sqlite3.wasm, które można dołączyć do projektu JavaScript (przykład HTML i JavaScript).

celów szczegółowych tego projektu są wymienione:

O ile nie zaznaczono tego w elementach innych niż docelowe, zapewnij mniej lub bardziej kompletne opakowanie funkcji dla API sqlite3 C, w takim zakresie, na jaki pozwala parzystość funkcji WASM z C. W rzeczywistości zapewnij co najmniej następujące interfejsy API .

• Powiąż niskopoziomowy interfejs API sqlite3, który jest jak najbardziej zbliżony do natywnego pod względem użytkowania.
• API wyższego poziomu OO, bardziej podobne do implementacji w stylu sql.js i node.js.
• Interfejs API oparty na procesach roboczych, który komunikuje się z powyższymi interfejsami API za pośrednictwem komunikatów procesu roboczego. Jest to przeznaczone do użycia w wątku głównym, z interfejsami API niższego poziomu zainstalowanymi w wątku roboczym i komunikowania się z nimi za pośrednictwem komunikatów roboczych.
• Wariant Worker API oparty na obietnicy, który całkowicie ukrywa aspekty komunikacji między wątkami użytkownika.
• O ile to możliwe, obsługa trwałej pamięci masowej po stronie klienta przy użyciu dostępnych interfejsów API JS. W chwili pisania tego tekstu obejmuje to prywatny system plików źródłowych (OPFS) i (bardzo ograniczoną) pamięć masową za pośrednictwem zaplecza window.localStorage i .window.sessionStorage

Jeśli chodzi o cele niespecyficzne:

• Ponieważ WASM jest technologią zorientowaną na sieć, a UTF-8 jest królem kodowania w tej dziedzinie, nie ma obecnie planów obsługi interfejsów API sqlite3 związanych z UTF16.
• Chociaż obsługa środowisk uruchomieniowych WASM poza przeglądarką jest szeroko rozpowszechniona, ten projekt jest obecnie (pod koniec 2022 r.) skoncentrowany tylko na celach przeglądarek. Chociaż szczegóły implementacji związane z siecią mają pierwszeństwo, a komponenty JavaScript interfejsu API koncentrują się w szczególności na klientach przeglądarek, moduł WASM niższego poziomu „powinien” działać w środowiskach WASM innych niż sieci Web.
• Kompatybilność ze starymi lub niszowymi platformami. WASM jest przeznaczony do nowoczesnej sieci i wymaga nowoczesnych platform. Podobnie, przestarzałe opcje biblioteki sqlite3 zostaną całkowicie usunięte z interfejsu WASM.

Kod obsługi WebAssembly został dodany do głównego repozytorium projektu. W przeciwieństwie do API WebSQL, które jest oparte na SQLite, WASM SQLite jest całkowicie odizolowany od przeglądarki i nie wpływa na jej bezpieczeństwo (Google zdecydowało się zrezygnować z obsługi WebSQL w Chrome po kilku lukach w SQLite, które mogą być wykorzystane przez WebSQL do ataku na Navigatora ).

w końcu jeśli jesteś chcesz dowiedzieć się więcej na ten tematmożesz sprawdzić szczegóły W poniższym linku.