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
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.
Airtable
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
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.
I haven’t actively used it yet, but graph.cool also looks promising, especially since it is using GraphQL to query data. It has a simple auth API itself I think, but can connect to other services like Auth0 for more elaborate implementations.
For those services which require you to expose auth credentials on the client-side, how about a simple proxy on the server that serves up your website? It doesn’t have to be complex; here’s a sample for Nginx users:
(where
_MY_AIRTABLE_API_KEY_and_MY_AIRTABLE_APP_ID_are swapped out for your own values, of course). Here’s a great little article that goes into more detail (it’s doing this for avoiding problems with cross-origin AJAX requests, rather than hiding secrets, but the implementation is similar)Yeah! If possible, that’s the way to go. That way you’re 99% client-side, but are still hiding the API keys and whatnot.
The only downside is you still need a server and server access then, meaning you can’t use like CodePen Projects or GitHub Pages or anything like that.
If you use a proxy to just hide the Key, but you basically just forward everything to the service, then what is to stop somebody from simply using your proxy to get and modify your data at will?
It seems to me that what you have on your server shouldn’t be just a proxy, but it should do authentication or at least some sort of server side validation. Or am I missing something?
I’m sure there is some kind of way to handle that too, depending on how fancy you want to get. You could check the referrer, and that would block general randos hitting the service, but not be perfect coverage because referrers can probably be faked. You could do some kind of nonce generation and check that. I’m sure back end nerds have this kind of thing largely sorted out.
Just curious on some privacy issues with these providers – say I have sensitive user data that I never want exposed to Google, or any other big-data aggregator, will these keep that user data private? I haven’t dug into the terms & conditions of each, but am keen to know.
Another one to think about!
Google Sheets is free (you make spreadsheets, just like Excel or whatever, plus Google Forms and output to it).
Google Sheets has an API (v4 is the latest: https://developers.google.com/sheets/api/) which allows you to read and write from it.
It has auth, and can be worked with with JavaScript: https://developers.google.com/sheets/api/quickstart/js
Sheetsu is a tool to (I think) make the API easier to deal with: https://sheetsu.com/