Proposal for a Web Background Sync API

We’ve been working for a while on a Background Sync API, to allow websites with service workers schedule work to be performed later. As described in our explainer document:

If you write an email, instant message, or simply favourite a tweet, the application needs to communicate that data to the server. If that fails, either due to user connectivity, service availability or anything in-between, the app can store that action in some kind of ‘outbox’ for retry later.

Unfortunately, on the web, that outbox can only be processed while the site is displayed in a browsing context. This is particularly problematic on mobile, where browsing contexts are frequently shut down to free memory.

Native application platforms provide job scheduling APIs that enable developers to collaborate with the system to ensure low power usage and background-driven processing. The web platform needs capabilities like this too.

We propose a new API that extends Service Workers with a sync event and an API for signalling the desire for this event to fire.

The explainer mentions both one-off syncs as well as periodic syncs, although initially we’d like to focus on just the first one of those, since we think it has much less privacy/security implications, and already addresses a lot of the use cases we’re interested in. We’ve started writing a spec for one-off syncs, and hope to further evolve/incubate this API in the WICG.


+1 to this; exposing “sync” points (when the network is active) seems great. The spec desperately needs some usage examples, but I presume that whenever you have data to sync, you register() it with some tag; the UA periodically notices that there is registered sync requests and the network is up, and fires a sync event with the appropriate tag, so you can start performing network activity.

I presume that this is so you can, for example, generate a guid for a DB entry key, with the value being something like “user 1234 favorited tweet 5678”, and register() a sync with that guid, then when the sync event fires you can retrieve that information and make a request at the server?

+1 as well. I’d love to see this work move forward.

The spec seems to be in a fairly advanced state. Would you consider moving the repo to the WICG GitHub org?

I think moving this to the WICG GitHub org would make a lot of sense, yes. I assume it is possible to do so while keeping all the github issues (and maybe even links to other stuff) working?

Yeah. The repo remains the same, just changes ownership. I’ll ping you by mail for the gory details.

For people following along, the repo did get moved, so now the location of the spec is: