ember-service-worker

[nathanhammond]

We should come up with a default story for a ServiceWorker, beyond just a simple application shell and the toolbox strategies. We need to draft an RFC that describes a complete implementation inside of ember-cli, specified well enough that it can be implemented by anybody.

This issue will be updated after the face-to-face and exists for collecting thoughts. @nathanhammond will serialize earlier conversations into this thread, no need to try and reproduce that information.

/cc @jkleinsc @runspired @stefanpenner

[runspired]

Warning: Brain dump, likely incoherent thoughts ahead

The ServiceWorker needs to be very easy to extend, because ServiceWorker exposes too many abilities for us to reasonably account for every app's needs.

• asset caching
• push notifications
• offline support
• data-storage
• fetch

It seems our primary interest in it at the moment is for:

• serving assets from a local cache
• application shell architecture
• module patching

I would propose that each of these three abilities is some form of a Mixin that can be added to a WorkerAppShell as desired.

We should build a generic WorkerAppShell that simply handles nice ES6 modularization, exposes a nice interface for extending / working with the abilities of a ServiceWorker, and likely exposes nice primitives for communication with the EmberApp. This is the goal behind Skyrocket, although Skyrocket is primarily focusing on the WebWorker story: https://github.com/runspired/skyrocket

It seems that some of our needs/wants are deeply connected with a server that understands our ServiceWorker. We'd likely want to build a lightweight asset server for Ember that's a breeze to deploy using a Heroku build-pack and ember-cli-deploy or similar. The server would want to handle / know about deployment module revisioning / be able to generate the patches for updating modules cached by the ServiceWorker etc.

[nathanhammond]

Server architecture could also simply mean specifying CDN locations for the pre-gen'd module files. Agreed that we should specify the server API contract in the RFC as well.

[jkleinsc]

I saw discussion on Twitter about concerns of app cache support being removed and I wanted to weigh in here vs Twitter. broccoli-serviceworker as it currently stands replicates all of what Application Cache does and puts it in a service worker for Ember apps. Beyond that broccoli-serviceworker gives Ember developers access to build their own service worker logic. That means that if app cache were to disappear from certain browsers today, we can easily replicate anything currently being done with app cache with service workers. And in browsers that don't support service workers we can fallback to application cache.

Secondly, there seems to be an impression that service workers are hard to work with. After working with them for well over a year, I have to disagree with that, particularly when it comes to debugging. App Cache's declarative nature means you don't have much visibility on why something isn't working but in a service worker you have full access to the developer tools allowing you to do single step debugging so if something isn't working you know why.

I've got more to say here but hopefully this adds some clarity to the current landscape. The sky isn't falling, it is getting bluer!

[runspired]

@jkleinsc

there seems to be an impression that service workers are hard to work with.

You are very likely referring to my (and @tomdale's) discussion of them. It has very little to do with them being hard; they aren't hard if you know the features and APIs they have, and have a build system to enable the full suite of ES6 features. But it does require replication of behavior (as you noted), while AppCache does not require additional build tooling and feature learning.

My points on twitter boiled down to (1) SW is not a 1:1 replacement for app-cache, even when you port over the functionality, and (2) because of that using SW to provide a "universal solution" for cacheing for Ember apps is difficult.

Bringing SW to everyone in the EC is going to necessitate adding first class tooling for it, as well as figuring out the right API to ensure that it's easy to use and extend while still providing behaviors that we're able to identify as common to all (or nearly all) Ember applications and build solutions for.

[jkleinsc]

As you may have seen Maximiliano Firtman recently wrote a Medium post titled Service Workers replacing AppCache: a sledgehammer to crack a nut. His point is that we should have a new high level API that gives Web App cache support without the need of low level code. His post seems targeted at browser vendors, but I think there are some takeaways that could be applied to this effort (particularly application shell). He goes on to further describe his new API:

A new high level API should have: A manifest file (in JSON format?) to declare all your resources. Right now, the recommendation is: “do it yourself”. I think we need an standard format.

Maybe this is getting into the weeds, but I think this is something that belongs in the environment/config.js. In the case of an Ember app we know the resources to cache so developers don't need to explicitly declare stuff in the dist dir, but for other resources we need a way to declaratively include them.

A simple way on that manifest file to declare cache policies per resource or per package (Network First, Cache First, etc.)

broccoli-serviceworker routing options currently does this and is absolutely something this effort should tackle. This goes beyond application shell and gives developers an easy way to dictate what network strategy a particular server url should use

A simple way on that manifest to declare timestamps or versions so the browser will know when to update it.

I think in Ember apps this means every time a build happens, a new service worker is generated and that the service worker can either inform the Ember app that there is a new build and/or automatically load the new build. Making sure that service workers work well with live reload is important as well.

No need to write a Service Worker (if the implementation wants to use a SW, it’s up to the User Agent.)

I think this already implicit, but this effort would aim to build the service worker for you.

No need to serve the files from the cache myself; it’s a browser’s job!

Again, this is something that most developers shouldn't have to worry about for this effort, but at the same time developers should have some programmatic access to the cache API through their Ember app.

Simple events per resource of operation to know the status of the installation/update process.

Being able to fire standard events from the service worker to the Ember app is crucial and something that needs to be clearly defined.

[runspired]

Addon of note: https://github.com/DockYard/ember-service-worker

cc @martndemus

[ghost]

Yes, I'm sorry that we didn't pick up that you guys are working on it too. Let's now collaborate and drive it into the right direction. I'm sure we all have the same goal in this.

[rwjblue]

We are working on closing the ember-cli/rfcs repo in favor of using a single central RFC's repo for everything. This was laid out in https://emberjs.github.io/rfcs/0300-rfc-process-update.html.

Sorry for the troubles, but would you mind reviewing to see if this is still something we need, and if so migrating this over to emberjs/rfcs?