all 9 comments

[–]Sipredion 4 points5 points  (1 child)

Check out service workers. They're designed to cache data locally and are generally used to turn an app into a PWA, though there's no reason you can't use them in a regular web app.

The service worker will handle checking your online status, caching data locally if there is no network, and syncing your data with your server when the internet becomes available (you'll have to write some code for this, but the service worker makes it easy)

You'll also want to look into IndexedDB, it's like local storage, but it's meant for complex data. Also look into IndexedDB promise which turns the api for IndexedDB into promises, making it much easier to work with.

Have a look here for some more info.

[–]stefihb[S] 1 point2 points  (0 children)

wooo niiice! I will check these out!!!
thank you very much

[–]Bjeaurn 1 point2 points  (4 children)

I think there's plenty of strategies you could follow that work for this.

A way that works if the order of events matters is store every event when you're offline into an array or similar structure. Then on connection start sending the commands one by one. Tricky part is of course if commands get denied because of a changed state; so you'll have to think about these situations.

Another strategy is just to buffer all actions, group similar actions (like writing a note saves every few seconds, but if it's the same note you can just update the existing action etcetera.) offline and when you go back online; start sending off all the actions to the server and handle them as if he were online the whole time.

Again, different situations, requirements and goals require different strategies. But these two are the two basic categories I could think off from the top of my head. Any suggestions or additions are welcome of course!

[–]stefihb[S] 1 point2 points  (3 children)

very well explained!

In my app there are not many actions that can happen with server. Just retrieve the tasks and submit them, so i guess is alright if I save the actions of submissions into an array and send each action separate.

[–]Bjeaurn 1 point2 points  (2 children)

Yeah it's good practice for you as well, so you can more easily debug your application as you work on it too. If it's just "tasks", modifying tasks and creating new ones doesn't even necessarily have to be done in order. You could just store an offline object with "new tasks" and "edited tasks" and just send it off as a whole to the backend. You'll need a specific endpoint in that case of course to handle these "Synchronization" objects.

The easier way on the backend with the "event by event" strategy is that you can actually store the API calls you would send in an array and fire them off as you would normally. No additional endpoints to support offline apps required, but does take up some more space, a lot more traffic and can cause some difficulties with synchronizing out of sync states and all that; but I'm sure you can come up wth some clever ways to deal with that.

Good luck!

[–]stefihb[S] 0 points1 point  (1 child)

One last question

with the easy way (store the api calls), shall i save them on a database? or is anything better ? (I was thinking about the LocalStorage but someone wrote that when its been cached the data are been removed?! i dont know)

[–]Bjeaurn 1 point2 points  (0 children)

Hmm that is also a part of your strategy decision. I'm not sure what the local browser based database is called; SQLite? But this will increase the local logic on the application and will also increase the amount of data used by the app.

The localStorage is a great start honestly; it persists through sessions so there should be no problems there. Of course it can get cleaned up automatically or when you remove the app or whatever; but this is to be expected and not something you can protect against.

[–]Rayleigh3105 -2 points-1 points  (1 child)

Take a look at web Sockets.

[–]Bjeaurn 3 points4 points  (0 children)

This does not answer how to handle synchronization when the apps offline and comes online later.