Even when the world has progressed towards high-speed internet connectivity, a constant internet connectivity has always been a challenge. A lot of apps be it like games, e-commerce, music, video, productivity tools are aimed towards an engaging user experience. Any network fluctuation is bound to disrupt user’s attention and severely impact user engagement.
So how do we design an offline-enabled app (this design philosophy is also termed as “offline first” apps.)? Well there are multiple design approaches each having their pros and cons.
Firebase is a very popular storage service providing real-time access to data and also support offline sync.
In this approach, the application will create listeners to various pieces of data in firebase, firebase will sync this data locally and provide a callback with the result to the application. Same happens in reverse when the application wants to update any information on the server.
Benefits of this approach are:-
1. A lot of boilerplate code of network detection is taken care by the framework.
2. A universal approach to access and update data from the app.
3. Faster development of the application, technically it removes the API layer.
4. Data updates will be instantly reflected in the App, without the need of refreshing screen by the user or background polling of data.
Benefits of this approach are:-
1. The app is no longer a presentation specific layer with API based backend, it stores complete logic and any minor change will require a re-release of application. Also same logic needs to be duplicated across both Android and iOS App.
2. Any third party integration over HTTP will still need to handle gracefully in case of offline experience. We can either design the app to explicitly tell the user about the limited availability of some features or store the API calls in a local Queue which will be consumed when App comes online.
3. App also becomes tightly coupled with the underlying storage framework, and moving to another storage becomes a significant re-write of the application.
In this design, the app has two methods to access and update data. If the app is online then API is invoked as and when required by the API, response of this API will be stored in local DB against a unique request key. If App is offline then API call fallbacks to local DB. For API’s which updates the data, it will update local DB and add all the APIs in a queue which will get consumed when App comes online.
Advantages of this approach are :-
1. Abstraction layer of business logic and database is in API’s. This is also good for the security of data.
2. We have more control over data management and apply some custom logic to it as well, otherwise, in case of firebase, a lot of data management happens under the hood.
Major Disadvantages of this approach are:-
1. This is a complex design which definitely addresses some of the disadvantages of “Design 1”, but the complexity of this approach is a major trade-off.
2. We need to handle read /write differently depending on App is online or offline.
3. API’s tend to become more monolithic to avoid the problem of chaining and interdependency of API responses to next API request.
For both the above designs, it should be carefully considered at the beginning of app development. If we want to provide an offline capability for an existing working App then it becomes more of error handling design and leads more complex data consistency issues.