Intent to Prototype: fetchLater API

[Ming-Ying Chung]

Hi Team,

We plan to prototype the fetchLater API, which is the successor of the previous PendingBeacon API (intent to prototype mail, intent to OT mail). The fetchLater API is the result of discussion with users and other browser vendors.

Contact emails

my...@chromium.org

deno...@chromium.org

pending-beac...@google.com

Explainer

https://github.com/WICG/pending-beacon/blob/main/docs/fetch-later-api.md

Chromium Design Doc

https://docs.google.com/document/d/1U8XSnICPY3j-fjzG35UVm6zjwL6LvX6ETU3T8WrzLyQ

Specification

https://whatpr.org/fetch/1647/094ea69...152d725.html#fetch-later-method (draft PR)

Summary

fetchLater() is a JavaScript API to request a deferred fetch. Once requested, the deferred request is queued by the browser, and will be invoked in one of the following scenarios:

• The document is destroyed.
• The document is bfcached and not restored after a certain time.

The API returns a FetchLaterResult that contains a boolean field sent that may be updated to tell whether the deferred request has been sent out or not. On successful sending, the whole response will be ignored, including body and headers. Nothing at all should be processed or updated, as the page is already gone.

Note that from the point of view of the API user, the exact send time is unknown.

Blink component

Blink>Network>FetchAPI

Motivation

Web developers have a need for ‘beaconing’ - that is, sending a bundle of data to a backend server, without expecting a particular response, ideally at the ‘end’ of a user’s visit to a page. Existing beacon APIs are all based around a developer constructing and sending a beacon, and there's no good time for that "send" call to be made.

This API delegates the sending to the browser itself, so it can support requests on page unload or on page hide, without the developer having to implement send calls at exactly the right times.

Initial public proposal

https://discourse.wicg.io/t/proposal-stateful-javascript-page-unload-beacon-api/5776

TAG review

TAG review status

Pending (for PendingBeacon, not fetchLater)

Risks

Interoperability and Compatibility

Gecko: Pending

WebKit: Supportive

Web developers: No signals

Other signals:

WebView application risks

No

Debuggability

fetchLater requests should be shown in the DevTool's network tab, similar to other network requests.

Is this feature fully tested by web-platform-tests?

Not yet. But there are tests for PendingBeacon to convert from.

Flag name

FetchLaterAPI

Requires code in //chrome?

False

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5690553554436096 (old entry for PendingBeacon API)

[Yoav Weiss]

Thanks for working on this!! (and iterating on the solution based on feedback)

[Alex Russell]

I'm surprised not to see a discussion of the (poorly named, but heavily overlapping) Background Sync API that we've shipped for many years in the Explainer:

https://developer.chrome.com/blog/background-sync/

Best,

Alex

On Wednesday, July 19, 2023 at 1:26:42 AM UTC-7 Yoav Weiss wrote:

Thanks for working on this!! (and iterating on the solution based on feedback)

On Tue, Jul 18, 2023 at 4:23 AM Ming-Ying Chung <my...@chromium.org> wrote:

Hi Team,

We plan to prototype the fetchLater API, which is the successor of the previous PendingBeacon API (intent to prototype mail, intent to OT mail). The fetchLater API is the result of discussion with users and other browser vendors.

Contact emails

my...@chromium.org

deno...@chromium.org

pending-beacon-experiment@google.com

Explainer

[Kenji Baheux]

The BG sync API requires the presence and control over a service worker.

This isn't possible for third parties, and therefore not solving their needs.

But I agree that the explainer could go a bit deeper on those aspects.

On Sun, Jul 23, 2023 at 1:43 AM Alex Russell <sligh...@chromium.org> wrote:

I'm surprised not to see a discussion of the (poorly named, but heavily overlapping) Background Sync API that we've shipped for many years in the Explainer:

https://developer.chrome.com/blog/background-sync/

Best,

Alex

On Wednesday, July 19, 2023 at 1:26:42 AM UTC-7 Yoav Weiss wrote:

Thanks for working on this!! (and iterating on the solution based on feedback)

On Tue, Jul 18, 2023 at 4:23 AM Ming-Ying Chung <my...@chromium.org> wrote:

Hi Team,

We plan to prototype the fetchLater API, which is the successor of the previous PendingBeacon API (intent to prototype mail, intent to OT mail). The fetchLater API is the result of discussion with users and other browser vendors.

Contact emails

my...@chromium.org

deno...@chromium.org

pending-beac...@google.com

Explainer

--
You received this message because you are subscribed to the Google Groups "blink-network-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-network-...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-network-dev/ded76e5a-a388-4685-a36c-5cdb92093f15n%40chromium.org.

--

Kenji BAHEUX (my how-to)

Product Manager - Chrome

Google Japan

[Ming-Ying Chung]

Thanks Kenji! I've added an "Alternative Considered" section to the explainer mentioning why not using background fetch & background sync APIs.