Database-driven web app: How to handle offline use

问题:

I'm developing a web app using Laravel (a PHP framework). The app is going to be used by about 30 of my co-workers on their Windows laptops.

My co-workers interview people on a regular basis. They will use the web app to add a new profile to a database once they interview somebody for the first time and they will append notes to these profiles on subsequent visits. Profiles and notes are stored using MySQL, but since I'm using Laravel, I could easily switch to another database.

Sometimes, my co-workers have to interview people when they're offline. They might visit a group of interviewees, add a few profiles and add some notes to existing ones during a session without any internet access.

How should I approach this?

1. With a local web server on every laptop. I've seen applications ship with some kind of installer including a LAMP stack, but I can't find any documentation on this.
2. I could install the app and something like XAMPP on every laptop myself. That would be possible, but in the future more people might use the app and not all of them might be located nearby.
3. I could use Service Workers, maybe in connection with a libray such as UpUp. This seems to be the most elegant approach.

I'd like to give option (3) a try, but my app is database driven and I'm not sure whether I could realize this approach:

• Would it be possible to write all the (relevant) data from the DB to - let's say - a JSON file which could be accessed instead of the DB when in offline mode? We don't have to handle much data (less than 100 small data records should be available during an interview session).
• When my co-workers add profiles or notes in offline mode, is there any "Web Service" way to insert data into the db that has been entered?

Thanks
Pida

回答1:

You can build what you describe using service workers to cache your site's static content to make it available offline, and a specific fetch handler in the service worker to detect a failed PUT or POST and queue the data in IndexedDB. You'd then periodically check IndexedDB for any queued data when your web app is loaded, and attempt to resend it.

I've described this approach in more detail at https://developers.google.com/web/showcase/case-study/service-workers-iowa#updates-to-users-schedules

That article assumes the use of the sw-precache library for caching your site's static assets, and the sw-toolbox library to provide runtime fetch handlers that check for failed business-logic requests. It also uses a promise-based IndexedDB wrapper called simpleDB although I'd probably go with the more recent idb library nowadays.

回答2:

I would think of it as building the app in "two parts".

First, the front end uses ajax calls to the back end (which isn't anything but a REST API). If there isn't any network connection, store the data in the browser using local storage.

When the user later has network connection, you could send the data that exists in the local storage to the back end and clear the local storage.

If you add web servers on the laptops, the databases and info will only be stored on their local laptops and would not be synced.