Say You Need a Persistent Data Store Entirely on the Client-Side

April 12, 2017 0 Comments

Say You Need a Persistent Data Store Entirely on the Client-Side



You got your localStorage. You got your IndexedDB. Those are both client side and capable of storing data, but they are limited to a single browser. I can't store data there from my laptop then come back later on my phone and have the same data. That's the kind of thing websites have back-end databases for. The data is stored elsewhere, so you have access everywhere.

But what if you don't want to deal with a back end? There are third-party solutions for this.


Firebase has a "Realtime Database" feature, so not only can you gather, store, and send data from the client side, that data is synced across any other device currently connected to the same database (if you care to do that).

Instead of typical HTTP requests, the Firebase Realtime Database uses data synchronization—every time data changes, any connected device receives that update within milliseconds.

That's just one of Firebase's many features. It also has things like authentication, messaging, and file storage, which all adds up to a pretty compelling infrastructure to spin up an app with.


We've covered how to use Airtable as a front-end developer here before. It's a really nice spreadsheet-like interface for storing any sort of data. You can definitely enter that data yourself, the UI is great for that, or collect it via automatically-created forms based on the structure of your data you set up. It also connects with loads of other apps for collecting data.

You can also send and retrieve data through API's that can work entirely client side. Cool.


Fieldbook is also for data storage, but starting with that spreadsheet UI. I love this idea of empowering people to think about the data behind their business and giving them the control to organize, connect, collect, and use that data.

Fieldbook has APIs that allow you to work with the data entirely client-side.

Ben Orozco wrote up an article about using it to power an Ember.js app. That's exactly the sort of thing that feels so cool and powerful to me. These services have JSON APIs, and so many modern frameworks have JSON-based state management, they seem like they could be a match made in heaven and be ultra empowering for front-end folks.

Choosing Something

I don't have nearly enough experience with these products to give you advice on using one over another. They all look impressive to me and worth checking out their pricing and feature sets and the free trials and whatnot.

One pretty important distinction is the auth.

Airtable has "simple token-based authentication", meaning a API key. If you use that from a website, anyone who can see that website can see that key and has access to do whatever to that "table".

Fieldbook has Basic auth, meaning you have to pass auth heads in the Ajax requests to do things. That ends up being about the same, as the headers are generated from an API key and secret key, and anyone who can see the website using the API will have that info and has access to that "book".

Firebase, I believe, has the most robust auth system. They offer auth as part of the package, like for users of your application itself. For example "Sign in with Twitter!" (or Facebook, or Google, or whatever oAuth provider. Then you can use that same system for giving different access levels to different users, including yourself. For example, if you auth as yourself, you could build/see a different UI that allows you do to more things in your app as an admin, but other folks auth'd as regular users, see your regular site.

Tag cloud