Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Offline First – A Better HTML5 User Experience

joelambert.co.uk

Post reply on HN
Print view View original

71–80 of 150 posts

Re: Offline First – A Better HTML5 User Experience

#71

Post by mbrock »

Fiahil wrote: post #63
mbrock wrote: post #18

The most useful pattern I know of for offline web apps is the command queue. Basically, the rendered state of the client is the acknowledged server state plus the client-side command queue. User actions don't make a server request and then update the UI. Instead they directly append to the local command queue, which updates the UI state, and right away the client begins communicating with the server to make the local…

You still have to handle cases where the server state has been updated (possibly via another medium, event, ...) and when the user's internet comes back it's not a matter of pushing clients' commands anymore. Instead you have to merge changes (either backend or front end side) before fetching the new state. For example, I try to purchase an item on my desktop, but can't because I lost connectivity. So, I proceed to b…

Yeah, heavy transactions like purchases need special care, but that's true in general. At least you'd want a confirmation from the user.

In our case, a simple command queue solved the vast majority of use cases, and the corner cases were not disasters but at worst somewhat confusing.

Re: Offline First – A Better HTML5 User Experience

#72

Post by allannienhuis »

Pxtl wrote: post #52
yonkshi wrote: post #22

Earlier quoted context omitted.

Having recently built an offline first app (mobile app I'll admit), we didn't use a command queue, and I regret it deeply now. I advise everyone who's reading this to go for a command queue. Saves a lot of time debugging data sync. Our biggest challenge was to sync data with relationships, especially data with circular relationships. We couldn't come up with a generic way to sync circular relationships, so we ended u…

What was the challenge with circular relationships? I work on an offline-first system and all inter-object relationships are managed by GUIDs, so cyclical references don't present any problems - objects are sent and received as one big list keyed by guids, not as a tree.

"objects are sent and received as one big list keyed by guids, not as a tree"

That's an interesting pattern I've not heard of before - any links you could recommend for more details on it? It sounds really useful for moderate sized data sets.

Re: Offline First – A Better HTML5 User Experience

#73

Post by tyingq »

I would throw in some guidance that says "don't trust anything the client side sends to you". Developers used to server side MVC could expose themselves to client-side manipulation that open up some security issues.

I remember some early ecom cart implementations where you could "name your own price" as an unintended feature.

Re: Offline First – A Better HTML5 User Experience

#74

Post by sgk284 »

mbrock wrote: post #18

The most useful pattern I know of for offline web apps is the command queue. Basically, the rendered state of the client is the acknowledged server state plus the client-side command queue. User actions don't make a server request and then update the UI. Instead they directly append to the local command queue, which updates the UI state, and right away the client begins communicating with the server to make the local…

I'm a big fan of command queues, but if there is a chance of a server-side failure that can't be realized immediately on the client (e.g. an edit conflict with a different user editing a same piece of information), then I find that surfacing those errors in a meaningful way can be difficult and frustrating for the user.

By the time the client has synced with the server, the client could be doing something completely unrelated in an entirely different part of the app. Explaining to them that "the thing you were editing two hours ago has an issue, go here to resolve it" can be tricky.

Re: Offline First – A Better HTML5 User Experience

#75

Post by ksk »

AgentME wrote: post #64
ksk wrote: post #24

Earlier quoted context omitted.

They do, but they're convinced that asking people to install software is verboten.

Smart users don't like installing every little thing they want to try and giving them all full unsandboxed access to their computer. On the desktop, the easiest way to run an app in a sandbox is if it's a web app that runs in the browser's sandbox to begin with.

As long as we're trending towards web-apps having native apps' functionality then that distinction will soon be meaningless. Native apps are already sandboxed in various ways. Process integrity levels, VM protection, low privileged execution, call gating, ACLs, MAC, etc etc. All these technologies already exist and are already being used in various ways. Any systems level programmer should already be aware of those.

The browser is fast becoming the "OS" and most browsers are several order of magnitudes more bloated than mainstream kernels, not to mention horrendously insecure - if we're worried about security, then browser vendors are the last people I would trust for anything important.

Re: Offline First – A Better HTML5 User Experience

#76

Post by mbrock »

mark242 wrote: post #47
mbrock wrote: post #41

Earlier quoted context omitted.

Can you serialize a promise to localStorage? How do you deal with network failure in the middle of the promise array?

If a promise in the array is rejected, Promise.all (which returns a promise) rejects with (supposedly) the first rejected promise, but that's extremely hard to predict if you have two promises which could reject. Serializing a promise to localStorage; I get what you're trying to do, you want to have a worker pick up exactly where it left off when you left the app. This is where a service worker would help you. I supp…

Yeah, these kinds of issues were why I decided to manually manage an array of serializable commands instead of using Promise.all.

Also showing the state of the queue (Sims-style, or just a number of pending changes) is easier when you control the queue yourself.

Re: Offline First – A Better HTML5 User Experience

#77

Post by Senji »

GrinningFool wrote: post #21
ciconia wrote: post #6

Earlier quoted context omitted.

If you need to build cross-platform apps - and that is mostly the case nowadays - the web is actually not such a bad solution. I mean, what is the alternative?

Gtk Qt The list is actually quite extensive: https://en.wikipedia.org/wiki/List_of_platform-independent_G... -- For mobile, clean separations also helps. It is definitely possible - and less complex than you'd expect - to have core functionality in a shared library, wired up to platform-specific native GUI toolkits. But your question illustrates the problem. The pervasive presence of toolkits that add layer upon laye…

Have fun trying to convince people to download and run your app.

Re: Offline First – A Better HTML5 User Experience

#79

Post by kemayo »

allannienhuis wrote: post #72
Pxtl wrote: post #52

Earlier quoted context omitted.

What was the challenge with circular relationships? I work on an offline-first system and all inter-object relationships are managed by GUIDs, so cyclical references don't present any problems - objects are sent and received as one big list keyed by guids, not as a tree.

"objects are sent and received as one big list keyed by guids, not as a tree" That's an interesting pattern I've not heard of before - any links you could recommend for more details on it? It sounds really useful for moderate sized data sets.

I remember coming across it fairly heavily in react/redux stuff, mostly because it makes dealing with redux's stores a lot simpler if you avoid nested structures like that.

There's a library called normalizr[1], whose purpose is to take nested API responses and turn them into flat structures. Have an article[2] about it.

[1]: https://github.com/paularmstrong/normalizr

[2]: https://tonyhb.gitbooks.io/redux-without-profanity/content/n...

Re: Offline First – A Better HTML5 User Experience

#80

Post by mbrock »

sgk284 wrote: post #74
mbrock wrote: post #18

The most useful pattern I know of for offline web apps is the command queue. Basically, the rendered state of the client is the acknowledged server state plus the client-side command queue. User actions don't make a server request and then update the UI. Instead they directly append to the local command queue, which updates the UI state, and right away the client begins communicating with the server to make the local…

I'm a big fan of command queues, but if there is a chance of a server-side failure that can't be realized immediately on the client (e.g. an edit conflict with a different user editing a same piece of information), then I find that surfacing those errors in a meaningful way can be difficult and frustrating for the user. By the time the client has synced with the server, the client could be doing something completely…

Yeah, it can get tricky, but it's a tradeoff between working nicely in the majority of cases and being accurate in the corner cases.

If you make sure to show the user a clear warning that they're working offline, then they might be more understanding if their changes are rejected two hours later.

Post reply on HN