search

jamesplease / orbit-examples

Examples showing common use cases for Orbit.js
MIT License
1 stars 0 forks source link

Example configurations: rest + memory + localStorage #5

Open jamesplease opened 9 years ago

jamesplease commented 9 years ago

I surveyed some developers and asked how they've used local storage in the past (I haven't used it too extensively), and two general use cases came out of the responses.

They are read-heavy apps, and write-heavy apps.

Ready-heavy apps

These are applications that primarily read data from a REST source. In these apps, a user may request information that is then stored in local storage. That way, if the user travels to a new location and their connection is lost, they can continue using the data that they had calculated previously. An application that gives travel information is one example use case for this.

Write-heavy apps

A dashboard that allows you to configure something is another example of using localstorage. If it is designed to support offline usage, then the user can make changes even while offline. When the application comes back online, the offline changes will be pushed up.

Supporting the read-heavy case should just involve a fallback system where the memory source tries to fetch in local storage if the API can't be reached.

The write-heavy case needs a way to propagate the state of the local source to the rest source when a connection is re-established. I'm still a noob @ orbit, so I'm not sure if an API exists that lets you say, "Hey source A, update yourself right now with the state of source B' or something like that. @dgeb does that exist? Or how would you go about doing this?

//cc @gnarf

dgeb commented 9 years ago

@jmeas I think there can be benefits to using local storage in almost every type of app, regardless of whether it is read-heavy, write-heavy, or balanced. Certainly, the more an app is dependent on a server, the more it can benefit from offline capabilities.

I agree that usage patterns differ for reading vs. writing as you've described.

The read-pattern is handled currently with request connectors as you've described.

The write-pattern involves queueing of operations that can't be completed immediately and then retrying them when possible. This is partially implemented (every source maintains a queue that can be paused and restarted) but is still a work in progress.

jamesplease commented 9 years ago

This is partially implemented (every source maintains a queue that can be paused and restarted) but is still a work in progress.

Cool. I'll work on the other use case for now, then.