Design Review #887

#887: Specification Review: FetchLater API

Opened Aug 28, 2023

こんにちは TAG-さん!

I'm requesting a TAG review of Fetchlater API.

This is a proposal for FetchLater API. It is a system for sending beacons when pages are discarded, that uses a stateful API rather than having developers explicitly send beacons themselves.

Explainer¹ (minimally containing user needs and example code): https://github.com/WICG/pending-beacon/blob/main/docs/fetch-later-api.md
Specification URL: Spec PR/Diff Preview (may be outdated)
Tests: https://github.com/web-platform-tests/wpt/tree/master/fetch/fetch-later
User research: positive feedback from various RUM providers testing Pending Beacon API's Origin Trial
Security and Privacy self-review²: https://github.com/WICG/pending-beacon/blob/main/docs/security-privacy-questionnaire.md
GitHub repo (if you prefer feedback filed there): explainer: WICG/pending-beacon/Spec: whatwg/fetch
Primary contacts (and their relationship to the specification):
- Ming-Ying Chung (@mingyc), Google - designing/implementing in Chrome
- Noam Rosenthal (@noamr), Google - API specification
Organization(s)/project(s) driving the specification: Google (BFCache team)
Key pieces of existing multi-stakeholder review or discussion of this specification: https://github.com/whatwg/fetch/pull/1647 Context when pivoted from PendingBeacon API
External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/4654499737632768

Further details:

[✓] I have reviewed the TAG's Web Platform Design Principles
Relevant time constraints or deadlines: BY Q4 2023
The group where the work on this specification is currently being done: whatwg/fetch
The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue):
Major unresolved issues with or opposition to this specification: The PR is not approved yet.
This work is being funded by: Google

You should also know that...

[please tell us anything you think is relevant to this review]

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

☂️ open a single issue in our GitHub repo for the entire review

💬 leave review feedback as a comment in this issue and @-notify @mingyc, @fergald, @noamr

Discussions

2023-09-04

Minutes

Sangwhan: I have looked at this... I like it.

Dan: It's WICG .. it's BFCache ... It's WHATWG...

Sangwhan: if you have a document and user closes the tab... if you have a fetch in flight you can't know if it happened. So there is the beacon api... which didn't follow the fetch pattern. So they redesigned it... New name is FetchLater. Less confusing... It implies it's a delayed fetch but what it really does is add a guarantee... The part where I have questions is the use cases.. They provide a high level use but not a real application use - what kinds of user-facing functions would this be used for? It's clear what the telemetry use cases are... I don't see it as harmful.

Dan: adds complexity to the web platform - if it's only for telemetry ... then is it worth it?

Sangwhan: they could also use it in cases where they haven't finished sending the final state of the app back to the server - e.g. writing a form and therte is a heartbeat where it's saving your current progress... Some anti-patterns such as "do you want to close this tab?" blocking - could go away.

Sangwhan: will leave comment and speak to the requestor

2023-10-09

Minutes

Dan: we had a reply 3 weeks ago.. clarifying naming

Sangwhan: fetch later means any time between now and destruct.. but in reality it's as late as possible.. I'm okay with this

Yves: Same. When we first reviewed this we were concerned they were exchanging state using get and they seem to have fixed this. Okay to close.

agreed to close - Sangwhan to leave closing comment