DEV Community

Cover image for Saving Data in JavaScript Without a Database

Saving Data in JavaScript Without a Database

Andrew Healey on June 03, 2019

You've just written a great piece of JavaScript. But when the running process stops, or the user refreshes, all of that nice data disappears into t...
Collapse
 
michi profile image
Michael Z • Edited

Another way is (or will be) kv storage. It's the first built in module for the web.

below code copied from article:

import {storage} from 'std:kv-storage';

const main = async () => {
  const oldPreferences = await storage.get('preferences');

  document.querySelector('form').addEventListener('submit', async () => {
    const newPreferences = Object.assign({}, oldPreferences, {
      // Updated preferences go here...
    });

    await storage.set('preferences', newPreferences);
  });
};

It uses indexedDb under the hood, but provides a convenient API similar to localStorage. With the main difference that it is asynchronous and therefore doesn't block the main thread.

Collapse
 
ahmadawais profile image
Ahmad Awais ⚡️ • Edited

Big fan of lowdb with file sync adapter

// Database.
const path = require('path');
const low = require('lowdb');
const FileSync = require('lowdb/adapters/FileSync');
const adapter = new FileSync(path.resolve(`${__dirname}/database.json`));
const db = low(adapter);

module.exports = db;
Collapse
 
edgarbarrantes profile image
Edgar Barrantes

I've also used dexie in order to interact with IndexedDB in the browser, highly recommend it.

Collapse
 
meduzen profile image
Mehdi M.

If you don't need more then key-value storage, idb-keyval is light and has a very similar API to localStorage.

LocalStorage should be avoided unless very specific use case (see this comment).

Collapse
 
edgarbarrantes profile image
Edgar Barrantes

I'm not really sure of your point here, I'm recommending the use of IndexedDB not local storage.

Thread Thread
 
meduzen profile image
Mehdi M.

The LocalStorage comment is for the author of the article.

Collapse
 
madelinecodes profile image
Madeline (Reeves) Healey

So I pretty much exclusively use SQLite, just wondering when you would use a different option? Is it all personal preference, depends on the scope of the project, ease of use...? How do you decide what you're going to use when you start a (say small) project?

Collapse
 
healeycodes profile image
Andrew Healey

If you plan on having more than one process needing to make database calls or if you're expecting periods of very high traffic*.

SQLite works great as the database engine for most low to medium traffic websites (which is to say, most websites). The amount of web traffic that SQLite can handle depends on how heavily the website uses its database. Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite. The 100K hits/day figure is a conservative estimate, not a hard upper bound. SQLite has been demonstrated to work with 10 times that amount of traffic.

More info here.

Collapse
 
ahferroin7 profile image
Austin S. Hemmelgarn

So I pretty much exclusively use SQLite, just wondering when you would use a different option? Is it all personal preference, depends on the scope of the project, ease of use...? How do you decide what you're going to use when you start a (say small) project?

Unless I actually need some functionality that's provided by having an SQL interface, I try to avoid it. I have no issue 'speaking' basic SQL, it's just that in most cases, you don't actually need it, so ti largely just adds overhead (SQL is complicated from an implementation perspective). See for example all of the major FOSS web browsers historically using SQLite for their cache, when all they really need is flat files with directory hashing and a simple 1:1 index.

Other disadvantages to SQLite specifically include it not being truly concurrent-access safe, and reimplementing much of the work the underlying filesystem is already doing.

Personally, if it's just simple data serialization, I'm a fan of YAML. It's reasonably lightweight, easily extensible, widely supported, and most importantly, can be debugged even by non-programmers. It does, of course, have it's own issues, but most of them are non-issues for my typical usage.

Collapse
 
adam_cyclones profile image
Adam Crockett 🌀

Indexedb with pouch in browser is quite interesting as a level up from session or local storage, or there is even sqlite WebAssembly! So stored much Database.

Collapse
 
sustained profile image
sustained

I recommend something called json-server for prototyping, it's fantastic.

Collapse
 
healeycodes profile image
Andrew Healey

This is awesome. Thanks for the resource!

Collapse
 
js2me profile image
Sergey S. Volkov

What about IndexedDB in the browsers for client-side storage?

developer.mozilla.org/en-US/docs/W...

But it have bad supporting in browsers like IE

Collapse
 
kpennell profile image
Kyle

This article is right to the point.thx

Collapse
 
healeycodes profile image
Andrew Healey

Thanks Kyle!

Collapse
 
isabolic99 profile image
isabolic99
Collapse
 
shayau profile image
Shaya

Found small typo:
"fs.readFile('user.json'..." shuold be: "users.json".
Thanx for the great article!

Collapse
 
healeycodes profile image
Andrew Healey

Fixed! Thanks for the good spot 👍

Collapse
 
garador profile image
Garador

Lovely!

I recently deployed a system for a client with SQLite, and it thruly is a great DB system even in production environment. 100% recommended.

Collapse
 
bbarbour profile image
Brian Barbour

Thank you so much for this. It's nice to know I can prototype stuff without having to figure out a database.