Offline: Hell or Heaven?
"Enough Bandwidth Still Insufficient", often we come across this, especially in the world of internet. No network, poor connection, data not available etc. are often the frustration points of customers. This gives up way for systems architected to work offline and sync online when network comes back. Sounds so simple, isn't it?
"a simple architecture that helps in achieving this, called Store and Forward (SAF), by replicating a limited amount of model functionalities within the client"
This is certainly an amazing thing for a developer to put the transaction in the queue that later gets synchronised via a cron job. Like a magic, the queue keeps diminishing. For a customer user, this looks amazing as the system works without network and in addition it is super fast.
And it takes not much time to develop in this architecture!!!
But "devil is in the detail"... really. When you implement this design, then you know the innumerable scenarios that arise that needs to be taken care while doing this offline architecture.
Here you find 8 such scenarios...
- validations are many to avoid inconsistencies of the application; you need to replicate server side validations on to the client; beware of database level validations
- you need to download the reference tables on to the client and keep it refreshed whenever a change happens at the server side; timestamp management is a key to this concept; more challenge when you have multiuser clients
- upgradations are to be kept in mind each time when a release is made; backward compatibility of code, backward compatibility of local database etc.
- you need to provide users some control over cached data, to view what's pending, to delete what's not required
- you need to develop remote control options over client's device in order to trouble shoot; with ability to extract data on demand for further analysis
- security of data is a major concern when it comes offline; encryption of records in the tables is better in addition to database access security
- transparency of what's pending to be synced is important to the customer; always await a delay in the transaction timestamp between client and finally when it gets into the database
- ensuring end to end integrity of data is a key aspect that needs to be kept highly consistent; be ready to invest a lot on this aspect
This listing grows still, newer and newer scenarios arise, only option is to "be ready".
When you want your customer to have offline functionality, you need to be more online!
Good Article Mani! I think SAF is a technique very specific to telecommunications where we can keep short messages in a queue for sometime while it waits for restoring the internet connection in the client and do '3a.Refresh' (from above pricture). We need similar technique for web applications too especially in those countries where internet exists 24X7 but with low bandwidth and not enough speed and business sees a great need to reach out large customer base. Another challenge in case of web application is to keep all resource available in the client / browser to be able for customers to keep playing around it if internet breaks down in middle. Your thoughts please :)