How can a web app work correctly when Internet connection is lost for some hours?

Question

Our team wants to design a Web-Based retail pharmacy management system. A web based solution is good because no user installations are needed.

Some of the data fetched from central database are read-only and are shared between clients (5000 pharmacy users) and Clients maybe store their billing or anything else to a central database.

There is one challenge. The web app should have 100% up time.

• How can we handle hybrid online and offline mode when the Internet connection is lost?
• Is there any known method? Should we sync updates of database into local customer computer and work with that? The database size may be too big, for example 10 GB.

Answer 1

If the internet connection is lost, it's not your application that is bad, it's the internet connection. So it's the internet connection you need to focus on. if it's critical to be connected to internet all the time, this can easily be done by having two internet connections (redundancy) at each location. (should be from different operators)

in many cases a pharmacy would also need a internet connection to be able to handle credit card purchase, so even your application is a "locally installed desktop application" they might not actually be able to do very much with it without internet a connection.

Answer 2

From the information given, it is hard to give a proper answer. So I could only provide some thoughts:

The web app should have 100% up time

This is pretty hard to achieve. Even in a one machine local scenario.

You have to fight power outages, failing hardware etc. And as soon as network is involved you have more failing parts, not to speak of the internet and flaky connections.

To throw in some numbers:

• 99.999% availability means 0.87 seconds per day unavaiable
• 99.99% availability means 8.64 seconds per day unavailable

Taken from Google's SRE Book

So even if you could guarantee 99.99% availability on your part, the question is, whether the network the customer uses, is that available.

To decrease network problems you would need some kind of redundant network access for every customer.

A web based solution is good because no user installations are needed

That's true, but comes at the cost of hard(er) to achieve availability.

Some of the data fetched from central database are read-only and are shared between clients

Say you do an on premise installation:

• how were you doing upgrades?
• how do upgrades effect your goal of availability?
• how to deal with different update speeds in terms of consistency? Customer A has an up to date version of your database, while Customer B has not, since she/he is still updating?

So, even if you go for an on premise strategy with some "smart updates" the problem of consistency should be thought through.

Clients maybe store their billing or anything else to a central database

This is another interesting topic. Even if you manage the read part with an on premise installation of your data, the network problem for writes stays the same: unreliable connections.

What are the criteria for writes to be accessible by others?

As long as no other than the customer itself needs to have "immediate" access, you could defer the updating part.

---

How can we handle hybrid online and offline mode when the Internet connection is lost?

Regarding the "read part":

Do an installation of the DB on premise. This is the only chance to rule out network issues. Updates will be one-way and simple: As soon as network is available, updates will be pushed. Problem: eventual consistency.

Regarding the "write part": Write operations could be queued and delivered when network is available. When no other customer depends, you have no problems. But when others depend on the data published, you have again the problem of eventual consistency.

Is there any known method?

Yes and no.

There are several patterns available, but no one size fits all solution. To give good advice, the concrete scenario has to be known and the tradeoffs you/your customer are willing to accept.

Should we sync updates of database into local customer computer and work with that?

As written above: That seems the best solution so far.

One scenario I could think of would be to use a tablet as target platform. These are cheap devices, so your customer could afford more than one (buying or renting). More than one device increases redundancy in case one device fails to work. Devices could be connected via WiFi and 3/4G redundant to decrease probability of network issues.

Perhaps it would make sense from a security perspective, that you lock down the devices to your usecase, to prevent accidentially installed malware from acces to your data.

Answer 3

You may want to consider Progressive Web Apps (PWA): https://developers.google.com/web/progressive-web-apps/

https://en.wikipedia.org/wiki/Progressive_Web_Apps

https://scotch.io/tutorials/the-ultimate-guide-to-progressive-web-applications

UPDATE:

Both the comment to my original answer and the perspective of all the other answers had me thinking Does the question have a plausible, realistic answer or is it a question that should be down voted in the first place?

Obviously the team asking the question has a strong background developing desktop applications, which get installed in the client's computer and work offline with local data. As we all know, things have changed drastically with the advent of the web.

On the other hand, we all also know the extend by which the web has been abused over the years to accommodate to needs well beyong its nature in terms of both usability and functionality. There have been numerous attempts to force web applications imitate desktop applications. At the end of the day, it is us the developers who strive to make ends meet using all sorts of complicated tricks, hacks and proprietary solutions. All this leads to unmaintanable, unstable software that ignore web standards.

A lot of times, the source of the problem is bad design that originates from a lack of shift of mind on behalf of the designers. I am sure we all agree that one can neither design nor build a successful application for the web with a desktop application mindset.

Having said that, my honest answer to the design team would be to drop the "challenge" and re-design with the web in their minds. I do believe that at the end the so-called "challenge" will prove not to be a challenge at all because it is something imposed upon them by their desktop background.

Answer 4

Its not impossible for a website to continue operation in the absence of an internet connection.

Your client side javascript will still function and you can store data locally for processing when the connection returns.

However!! The inherent problem is that your client application is running in a web browser with a great big refresh page button, which will definitely break everything if its pressed.

For any degree of reliable offline functionality you need more control over the client than a simple webpage offers.

The downside is that any solution will require some form of installation.

I would focus on automating the installation rather than trying to avoid it entirely.

Answer 5

While web applications can operate offline (W3C; MDN), the goal is more to provide a service to mobile users, rather than to the desktop customers of a CRM.

Some of the limitations you'll encounter include:

• The memory restrictions and the volatility of the data. You haven't specified the size of the read-only data you were talking about, but you should understand that client-side SQL doesn't replace the server-side database. You can't store terabytes of data in the browser, and you can't be sure the user won't go and delete it at once one day (or tamper with it, by the way).

• Synchronization when going back online. This is the classical problem of a piece of data which was changed in two locations while offline: how the conflict should be handled?

• Cross-browser issues. Imagine your user accesses the application from a PC, as well as from a smartphone. The PC network connection goes down, but the user continues to use the application and generates a bill. Later on, he checks the list of bills on his smartphone, and notices that the bill is missing. This is not surprising for you as a developer, but most users won't understand why the online version, expected to be more up to date, doesn't have the data which was generated on an offline device.

  If you have data shared among customers, things could get even worse. For instance, a person could generate a piece of information on an offline device, the information being shared with another user, and then call the other user to discuss the piece of information just to find that he can't see it. Unless you are very careful with the user interface, the blame in such situations will be on your app “which is broken.”

If you're asking this question, I suppose that:

• Either you're hosting your application at home (at the office) where the internet connectivity is not particularly reliable. In this case, you should think about hosting it on Amazon AWS or a similar hosting provider, where you can be sure that your application will be online permanently.

• Or your customers don't have a reliable connection. In this case, there is not much you can do; it's their problems, and they should be expecting their business to stand by (or at least slow down) in a case of a network issue. Having a mobile-friendly version of your web application could help them stay operational in case of a network issue, by continuing to use the app on a smartphone.