unhosted web apps

dev tools

User-centric sync for the web

Nowadays, users of mobile apps, but also of some desktop applications, expect their data to be synced to the cloud, and to other their devices. The web has traditionally solved this by storing data at the application provider's server. But with the new tools listed on this page, you can also allow users to sync data from your app to their own storage server. Straight from any modern browser (using CORS), without passing through your application server first.

Choosing a client library for per-user storage

You can build an unhosted web app in Vanilla JavaScript. But there are also client libraries that can make your life easier if you want to support per-user storage. Depending on what type of per-user storage account you expect your prospective users to have, you can use this table to see which library you can use to support that:

If you choose to use Solid, you will have Solid-specific JS libraries at your disposal, see https://solidproject.org/for-developers/apps/tools.

The reason that none of these client libraries support for instance Apple iCloud, is that those services don't provide a cross-origin 'REST+CORS' API. Dropbox and GoogleDrive do (and nowadays Microsoft OneDrive and GitHub do as well, by the way), all remoteStorage providers do (this is what the remoteStorage specification was designed for), and Hoodie does as of version 1.0 (still in beta as of October 2014).

Instant Data Import

Most of these libraries also have a domain-specific 'data modules' system that allow your app not only to store data, but also to indicate that something is a photo, a contact, or a calendar event. That means that your app will be pre-filled with the user's existing photos, contacts, and calendar events, even on first use. No need for cumbersome import wizards anymore!

Offine-first

remotestorage.js and hoodie.js were both developed with offline-first design principles in mind: if the network is flaky, requests will be automatically queued for when connectivity comes back, without throwing Exceptions that interrupt the flow of the user experience.

Free your user's data

As already explained on the first page, storing data on the user's storage instead of on your server as an app provider puts the user, not you as an app provider, in control of their data. You may also adopt a hybrid approach: host a default remoteStorage or Hoodie server for users who sign up at your site, but allow free birds to override that default if they want to specify their own storage server.

Full listing of relevant tools

+ add yours

• 

  remoteStorage

  user data modules

• 

  PouchDB

  in-browser CouchDB

• 

  NimbusBase

  per-user MVC

• 

  Hoodie

  noBackend architecture

• 

  Sockethub

  polyglot messaging

• 

  5apps

  app deployment

• 

  Harp Server

  static web server

See also: noBackend and Offline First