DEV Community

loading...

Offline PWAs and JSON Limitation Issue

Desolo Sub Humus 🌎🌍
Learned Fortran on an old TI-99; forgot Fortran; learned to draw, paint, sculpt, and play violin; learned how to merge code and art, turned it into my UX/Front-end dev Frankenthing.
・Updated on ・4 min read

Offline PWAs and JSON Limitation Issue

The addition of a simple Service Worker and a JSON file to save us from writing the same tags over and over again in every head element on every page and to make our web apps load even faster is a wonderful idea, though I've encountered a huge issue with the implementation.

I tried to turn my Azure Alphant repo on GitHub into a fully-fledged PWA, however this is not possible for apps which will be used offline at all. The issue is a bit complex, and involves a built-in security feature for JSON use.

Each page in the app needs to be able to use the Service Worker in order to tell the browser the conditions which should be met for certain events to take place. (Example: What the browser should detect before installing, how it should allow the app to be installed, determining it the app has finished installing and whether it has installed properly, and to apply the manifest.JSON file when everything checks out.) Each page also needs to reference the manifest.JSON file. So far, so good.

The problem I found became apparent when I tried to test-use the app offline. In order to use JSON, certain CORS requirements need to be met, and the pages can only load the JSON file(s) specified, assuming you want to keep a tighter handle on security. The problem lies in the fact that the only acceptable files must begin with HTTP://, HTTPS://, and a few others like data- which do not apply to JSON files. Now, a truly offline app will need access to all necessary files locally, as trying to access them online while you are completely offline simply will not work. This means the manifest JSON file must be accessible online only for CORS requirements to be satisfied, but must be accessible as a local file only when offline. Either CORS will break when the file location begins with C:// (or whichever drive you have it on) or it will break when it can't find the JSON file online when there is no online connection.

The opposite of SchrΓΆdinger's Cat
Instead of the app working both online and offline, its ability to fetch the manifest file is broken both as online and local files

I've wondered, is there a way around this problem? So far, I haven't found a solution that actually works (saving a file that was semantically JSON as manifest.js didn't work at all during testing). However, since we are still pushing for apps to feel more native, and it just makes sense to give users some control over what happens locally (for example, not specifying a font-family on a website allows the site to display either the default font or a user-specified font as per the user's browser settings), could there be a possible future in which a user could choose manifest file settings to be used for their installed apps directly in the browser?

Sure, I'd have my work cut out for me in that scenario in that I'd have to write code that allowed for those user settings and still keeps the app running and displaying as intended, but doing so could allow for a system that relied on local security instead of on the current CORS system, which is built to keep the online JSON files we need a bit more secure. In the event that an offline JSON file or browser manifest settings could even be fetched, the manifest JSON file would have to be swapped out locally, or the settings changed locally for security issues to crop up locally. This seems to me to be a much more secure option than trying to secure online files online from online viruses, hacking attempts, and such.

Granted, there's still quite a bit that would be app-dependent and couldn't be added as a local setting, but perhaps we could still put that on every page (I know, ugh, no), but at least we wouldn't be dealing with an app-breaking mess where important information couldn't be loaded (breaking the entire app) due to CORS vs. JSON issues.

I could be wrong (I do not work in any Security capacity in terms of coding and I'm fairly new to dealing with CORS), so take this as a fairly random idea that isn't actually in the works anywhere (that I know of), and of course, if I am wrong, please let me know that I am and explain to me what I'm missing in the comments. In the unlikely event that I've come up with the most perfect and unbreakable solution to this conundrum, feel free to let me know about that in the comments, too.

Mind you, I do understand that the 'W' in PWA is for Web, which implies this is for online purposes, but even Google gives tutorial instructions on how Developers should set up offline use for PWAs. This was how I found the issue in the first place - by researching why Azure Alphant did not work as a PWA and instead threw a list of errors in the DevTool panel while refusing to load after I had followed the PWA tutorial perfectly.

All I DO know absolutely for sure is that there has to be a better way to set up PWAs.

Discussion (0)