Asynchronous client javascript process to talk to server

Question

I'm considering developing a web app with offline capability. I'm considering formatting all client form postbacks as JSON objects, and writing these direct to HTML5 LocalStorage on a form postback. I'll then have a separate process that asynchronously polls the LocalStorage for JSON entries and submits these to the server. This server-sync process will not have any UI context. The actual user UI can then be very responsive. (I'll use cache manifest files to deal with other offline issues).

Is this a sound plan, and what would be the best technical implementation of the asynchronous JSON post process? (perhaps a timer, polling LocalStorage and checking the server connection every second?) Is there a better way to implement the server sync (if I was implementing this on a server, I'd write a service - is there an equivalent javascript mechanism?)

Thanks.

Answer 1

In the end I just used a simple setInterval, as follows:

setInterval("SyncLocalStorageToServer()", 4000); // Loop at 4 second intervals

which then calls a function that loops around the localStorage entries, sending each one in turn to the server.

Answer 2

I did some testing last year to run our app offline, for HTML5 browsers only.

The app is based on JSON services, and rendered client side using our lib: pure.js. You get a very responsive app just using a similar architecture, even without offline access.

If the JSON service call failed, it assumed we were offline, and used local storage instead.
When a call was done online, it checked the status of the offline queue and sync it if needed.

But then I started to replicate some server validation logic on the client. And discovered the data stored were not encrypted. Even with something like javascrypt you need the key somewhere or set a password key, etc...
Then what do you keep to the client? Everything? The last viewed items? How to you handle data change collisions?

My bet is with today's mobile networks, which are online in general, it is easier to make the app runs well on a mobile instead of trying to get it offline.
We dropped our offline efforts for now.