I have a data-driven legacy system (has a Java Swing client and a JavaEE application server) in my workplace, This system uses a single database for querying and modifying data.
Recently we've been asked to write a new web application that implements some of the already-existing features of the legacy system.
The application should work both online and offline - offline times can be for an hour or so but might as well be for a few minutes.
This is what we thought to implement for offline only functionality:
- Using Service Worker to store static app files (so we could access it when offline).
- Fetching data when going to offline mode and storing it inside the local db.
- Reading from the local db (IndexedDB).
- Performed operations will reside in the local database in a queue form.
- Syncing back performed operations from the queue when going back online (as a one batch, some actions may have a dependency on others).
To let the application be as general as possible and prevent repeating offline/online checks, we thought about this solution for adding online functionality:
- Requests to fetch data (upon page or component load) will go to the remote server and update the local database, which will be requested afterwards.
- Performed operations will be added to the operations queue (same as the offline one).
- Polling the queue and invoking the remote server, updating the client in an async manner.
Assume that only one client can update a certain set of data, so no server-side synchronization problems here.
Is this a maintainable and scalable approach ?
There is also another consideration here - the REST api that the server exposes. If i use the same api for batching operations and single operations, it should be a general api that accepts different types of actions, command-like principle.
I didn't hear much about this kind of service which leads me to think this isn't a good REST design, is there another way of implementing it?