Service worker support

[mitar]

Migrated from: meteor/meteor#5982

[mitar]

Related: #19

[ilan-schemoul]

Just FYI as Meteor has refused Mitar's implementation just because Apple weren't supporting the Service Worker API, they've started doing it . BTW, IMHO, refusing the ability for package creators to register a SW, pushing for the deprecated AppCache instead, wasn't a bright idea.

[benjamn]

Apple this week began work toward integrating Service Workers

That's not much to get excited about, IMHO. We're still a long way away from Service Workers being generally available in all browsers.

Here are my thoughts on this topic, in tweet form: https://twitter.com/benjamn/status/872510575850475520

We're not refusing anything. Mitar never claimed anything approaching a complete implementation of service worker support, and you're not helping on that front, either.

Re: your humble opinion, maybe take some time to imagine how this would actually work, in detail, and then we can continue the discussion. Empty hype is useless here.

[mitar]

And just to be clear, I am advocating for #19, not that Meteor should be built around service workers (that can be done in the future, maybe, like @benjamn is saying). (#19 would open doors for 3rd party service worker experimentation, but also web workers and others.)

[ilan-schemoul]

Okay. I'm not advocating that Meteor should be built around service workers like create react app did I just thought of Meteor when I see the news about SW being implemented in Safari as it's the only big con that existed as it has been pointed out in the original thread. For me PWA are definitively the way-to-go and the future for web development and I was just excited about publishing my first own package based on my repository for Meteor service worker but with a clean API.

Mitar never claimed anything approaching a complete implementation of service worker support, and you're not helping on that front, either.

I'm probably not (yet ?) experienced enough to make such an important commit to a framework and in any way.

Bottom line : I just really thought that you were waiting for Safari implementation of SW to start letting devs register SW. I don't mean to argue about it with you. Personally I could always manually register SW I would just like having packages proposed on Atmosphere/npm to register SW.

[ilan-schemoul]

Well maybe as it's an open-source am I supposed to find a way to implement this feature, perhaps it's not as hard as I think and I could learn from that experience even though if my PR could not make it through. Yup definitively something to think about.

[mitar]

this feature

I think the main question is, what exactly is "this feature". I think we should define this before we start working on PRs.

[mitar]

(This is why this issue is not yet "pull requests encouraged".)

[ilan-schemoul]

For me this feature is not about Meteor having a SW by default but it is about adding the ability for package developers to register a Service Worker.

[dohomi]

I would love to see an implementation running a Meteor-App as a PWA.

[CaptainN]

Service Workers would be great! But it's really a set of uses/features that I'm personally after, some of which require Service Workers, others of which probably don't need it:

Offline caching - Meteor has appcache package (which should be deprecated given it's known problems - or maybe updated to implement a superior solution on top of indexedDB), and it's own custom caching through indexedDB. It would be great if the newer indexedDB solution could be extended and interfaced with by app devs - I'd like to know more about what is cached (is my entire app bundle ready for offline support? How can I ensure that things are prefetched, etc.). Is that possible now - is there an API for that?

I use Ground:DB for collection caching, which also uses indexedDB behind the scenes (through localforage) - but I don't have a solution for caching images and fonts.

In short - it'd be great if Meteor had some kind of robust offline plugin with some kind of interface, maybe similar to Service Workers' cache API, but which could use Service Workers if needed, but probably doesn't even need that.

Push notifications - This is a similar area where it may make more sense to implement a standalone solution, which uses cordova and whatever else is out there for push notifications, but also can support Service Workers notifications. (raix:push maybe offers the bones of this)

A feature by feature consideration may be the way forward. On the other hand, Android through the various browsers (even Firefox) does properly support Service Workers now, making PWAs almost first class citizens on that platform (if listed in the Play store they would be). It's easy to envision a situation like - implement Cordova for iOS (there is a SW polyfill for Cordova), and PWA for Android.

Anyway, Service Workers are kind of supported now - just add sw.js to the public directory, and register the worker - it'd be great if .js files served from there were served with the correct content-type header. Is there a way to add content-types to meteor?

It'd also be great if there was a way to register new bundles and entry points. I already see a way to register a new end point file through the connect backend, but figuring out how to get a file built seems harder. This could probably be used for things beyond Service Workers.

[CaptainN]

TLDNR : With support for additional build targets, we could implement this as a standalone package, and not require any changes to core.

More: In the most recent version of Chrome for Android, Google has removed the "Add to Homescreen" option from the drop down. Now the only way to get an app added to the desktop is to pass their validation heuristics, which includes a requirement for a service worker, and the deprecation of the appcache manifest.

I'd say that makes this more urgent now.

I'll also say that I think adding support requires only one missing feature, which would help for other important hard to implement features in Meteor - namely, web workers. All we need is a way to implement additional build packages, since each worker requires its own built .js file.

Shorter term workaround - actually, it's possible to implement this now. We can use feature detection in the main bundle to detect whether we are running in a web worker or service worker context, and then dynamically load the service worker or web worker specific scripts (I'm assuming the dynamic module system will work within workers - I think they should). There is just a bit of overhead with this approach (unless your actual application mostly does its own loading dynamically too - though there are downsides with that approach).

Additionally, some kind of easier to find (and configure) server side routing system would be great to have in Meteor.

[mitar]

BTW, support for new targets is being done as part of: https://github.com/meteor/meteor/pull/9439

[dr-dimitru]

@dohomi @CaptainN

I would love to see an implementation running a Meteor-App as a PWA.

Here you go : https://files.veliov.com

1. On the latest Chromium it asks me if I want to install it as App (on MacOS, at least)
2. It's open source - https://github.com/VeliovGroup/Meteor-Files-Demos/tree/master/demo
3. sw.min.js is served with right CT header: content-type:application/javascript; charset=utf-8

wdyt?

[CaptainN]

@dr-demitru neat! Looks like you've taken care of a bunch of the issues I've raised. How did you get it to serve the correct content type?

It looks like we are still missing a build system for sw.js - though it also seems like we have a solution in the works in meteor/meteor@9439. Sweet!

[dr-dimitru]

I'm letting my nginx to serve static files. Actually I'm thinking to write a comprehensive series of articles covering our 3 year production experience with Meteor. Can't cover everything in a single comment on GitHub :)

So in short:

1. Do not serve static files with node (meteor)
2. Everything under public directory should be manually built. Btw ostrio:files package uses WebWorkers to handle files upload with no UI freezes, it's just defined as asset

It's working this way with no issues for last 2-3 years.

[splitified]

According to the Meteor doc: [...] All files inside a top-level directory called public/ are served as-is to the client.

For my meteor app, working with service-workers is just as simple as adding a sw.js and a manifest.json file in the public directory. (plus a href to the json file in header) and it works really well (cache files + allow me to enable web push notifications which is a really cool feature :) ).

(The sw.js file content is inspired by nitrobay example)

The only missing part for my app to work offline is to cache data but I know there are some packages to persists collections using localforage. So just a matter of free time I think.

[dr-dimitru]

@splitified

For my meteor app, working with service-workers is just as simple as adding a sw.js and a manifest.json file in the public directory. (plus a href to the json file in header) and it works really well (cache files + allow me to enable web push notifications which is a really cool feature :) ).

Note: Manifest should have .webmanifest extension and served with appropriate mime-type.

[splitified]

Some precisions about that last point :)

According to google doc the name of the manifest doesn't really matter :

You can call the manifest whatever you want. Most people use manifest.json.

Plus according to the mozilla doc the mime type is optional :

Manifests should be served using the application/manifest+json MIME type. However, it is optional to do so.

[dr-dimitru]

@splitified you can argue with specs.

The text from Google and Mozilla simply means they don't strictly follow specs and forgive dev(ops) mistakes.

[CaptainN]

Being able to add content-type headers to content in the public directory is something we should have in Meteor in any case. Is it possible to reach into the connect.js API and add stuff that way? I sort of remember seeing something like a router API for the server side of Meteor in the docs somewhere.

[arggh]

@CaptainN That's exactly what I did to load a service worker. I couldn't figure out a better way and judging by this thread, there maybe isn't one?

Here's the code: (maybe should also set cache headers to max-age 0)

const { connectHandlers } = WebApp;

const serviceWorkerJS = Assets.getText('service-worker.js');

connectHandlers
  .use('/service-worker.js', function (req, res, next) {
    res.setHeader('Content-Type', 'application/javascript; charset=UTF-8');
    return res.end(serviceWorkerJS);
  });

This was the first time in a few years I was actually having hard time getting stuff done with Meteor.

First I tried to add my service worker to /public, but the MIME type was off. Then I tried a bunch of other stuff before finally getting it to work using the connect API, like demonstrated above.

[trusktr]

The single-most reason for having Service Workers, even if all browser don't have it (do they now?) is PWAs on Android (the user adding a web app to their list of "installed applications" right from the browser so that it appears in the app drawer).

Meteor aims to make web-based app deployment a breeze, so this is a must for this reason alone, regardless of what other browsers and OSes do with Service Workers. It will increase audience reach, which equals money $$$...

Okay, I think I've said too much. If I say more I might spill all the good ideas!

[vuhrmeister]

If you only need to have a Service Worker for installing to home screen then you can do this right now already. The SW is not breaking any other functionality. We do that also for our apps without any caching logic.

[dandv]

The single-most reason for having Service Workers, even if all browser don't have it (do they now?)

https://jakearchibald.github.io/isserviceworkerready/

[msavin]

With the new modern and legacy builds feature, Meteor seems more ready than ever for this

[smeijer]

Let's get going then. Can't wait for having push notifications.

[dr-dimitru]

@smeijer @msavin almost a year ago, I've told how we are dealing with Service/Web workers support. What is so much different now?

[msavin]

iOS 12 is coming with some big PWA updates

https://twitter.com/mhartington/status/1089292031548145666

[awatson1978]

Hi, just now familiarizing myself with service workers. I'm wondering what the limitations are of the NPM package?

https://www.npmjs.com/package/register-service-worker

[awatson1978]

Update.... yeah, the register-service-worker NPM package works just fine. Was able to use it to pass the Lighthouse PWA audit and confirm that service workers are registered and working correctly.

[mullojo]

This tutorial guide shows how easy it is to turn any Meteor app into a PWA. It includes the steps to implement @NitroBAY's sw.js (Service Worker) and the basics of setting up a manifest.json file. Passes Google's Lighthouse test with flying colors when running via SSL on Galaxy for me.

I've been using this for a month now in my Meteor w/ Vue app, and it couldn't really be any easier. Thanks @NitroBAY for the work on that Service Worker 👍

And it's 2020 now, Service Workers are supported everywhere, but Apple is still behind on what they allow for web push notifications, but some people are speculating that could change with iOS 14.

I'm really happy with the PWA experience testing on my iOS device and I love having an installable desktop and mobile app. It's very cool. Go Meteor ☄️

[StorytellerCZ]

@mullojo Can we get a starting skeleton with it?

[mullojo]

We probably could, perhaps we could configure a PWA skeleton meteor create --pwa that would allow devs to add any view layer they like, or we could possibly add these couple default files to every view layer skeleton by default. We'll have to look into this some more. In Meteor 1.10.3, the Vue skeleton is going live with meteor create --vue.

There are performance gains for every Meteor project by just having that Service Worker, it reduces the load on the server for connected users. It has other benefits too, even if someone didn't care about officially getting the PWA status.

There could be some drawbacks to trying to support a PWA skeleton across all view layers based on how people like to structure their projects, it might be too early for me to give a qualified opinion on all view layers. I need to spend a bit more time with the various view layers & their default configs.

We are planning to cover this in the docs to start. I'm looking at adding a PWA section to the Meteor Docs or Guide. It might fit best as a Guide that can evolve faster than a skeleton to start.