random gathering of use cases

[gr2m]

Offline, unsynched changes

I guess that's the first use case that comes to people's mind when they think about oflline-first.

In minutes.io, I show a blue bar at the top of the browser window, telling the user that she/he is working offline, and that there are X unsynched changes.

In Hoodie, devs can subscribe to these events

• disconnected
• reconnected

and get locally changed objects with hoodie.store.changedObjects()

Signed in, but invalid session

with offline first, you can be signed in and work with the app, but your authentication against the backend might be invalidated.

At minutes.io, I show a yellow exclamation mark sign asking the user that she/he needs to reauthenticate.

In Hoodie, we have an extra events for that

• unauthenticated
• reauthenticated

[gr2m]

Sign out, but has local changes

With offline-first, there can be a state that changes are stored and visible locally, but have not yet been synchronized to the backend. In that case, you app should defer the sign out and try to push local changes first. But if that doesn't work, the user should be warned about data loos and asked if she/he really wants to sign out

[gr2m]

Anonymous users

When your app works offline, you can use it without a sign up. But if the app supports user accounts, you might run into the issue of forgetting to sign in, creating data, but then wanting to move it to your real account

[gr2m]

Maintenance

The "Offline for Maintenance" is very common in traditional web apps. The cool thing about offline-first apps is, that we now can separate Backend from Frontend, also if we have to do maintenance on the server. There will be zero interruption for both existing as well as new users. The only limitation would be that they would work in "offline-mode", meaning they won't be able to sign up / in, background tasks will get queued etc. But still way better experience than seeing an "we are down for maintenance" message.

[michielbdejong]

yes, first three are very familiar topics from remotestorage.js development as well :) the way we did it there is with a library-provided UI element (the remoteStorage widget), which displays these exact same modes you describe: "anonymous (click to log in)", "offline" (grey), "unauthorized" (clickable error text), "busy" (icon transparency increases and decreases, looks a bit like a throbbing heart).

we expose the events to the app, but it's not necessary to listen to them, because the widget already informs the user about the connection state.

eventually i think this functionality should become part of the browser (!)

Live demo

Some anonymous users (see above) might be visitors visiting your app for the first time. Lower the barrier for trying out for them! When implemented on the serverside, live demos usually require complex changes to your codebase. With offline-first, you get them for free.

security

Now that browsers are shipping with native crypto primitives, offline-only (with optional upgrades for new versions) should be the secure way of delivering javascript payloads. We'll still need to build auditing systems, but this is a reasonable place to start. Otherwise the server could send a malicious payload at any time that compromises the users's private keys.

[brandonzylstra]

With offline-first, there can be a state that changes are stored and visible locally, but have not yet been synchronized to the backend. In that case, you app should defer the sign out and try to push local changes first. But if that doesn't work, the user should be warned about data loos and asked if she/he really wants to sign out

@gr2m why should logging out cause a loss of locally-stored data? Why can't this data be persisted locally even when the user is logged out?