Upload blobs straight to R2 with presigned URLs

Offen
  • Stimmt etwas nicht?
#49 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 2 Tagen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
25/100
Issue-Typ
Feature
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
aws, typescript
Bereich
backend-api-design, cloud

Rechercherichtung

Read the server’s blob store and publish flow, then compare the store protocol in the vite-plus and vite-task repositories; the issue does not name specific files or tests. Map how R2 signing credentials, generation reservation, direct upload, and publish verification would work across all three parts. Done means clients can upload to a presigned R2 URL and publish only after the server verifies the object.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

The idea. Let a client upload a blob straight to R2 with a presigned URL, so that the blob's bytes never pass through the Worker.

Why. Today every byte of a blob streams through the Worker. Because R2's multipart upload needs parts of at least 5 MiB, uploadBlob() buffers 5 MiB per store in flight. Isolate memory is what bounds concurrent stores (Admission, 2 per isolate), and refused stores are lost, since the client doesn't retry a 503.

With presigned uploads:

  • the Worker only reserves the generation, signs a URL for blob_object, and later publishes after checking the object's size;
  • concurrency is then bounded by the rate limit, not memory;
  • large blobs (we see up to 13 MB) cost the Worker nothing.

What it needs.

  • Server: an endpoint that reserves a generation and returns a presigned R2 PUT URL, with the size limit enforced on the signed request or checked at publish, and a publish step that verifies the object.
  • Client (vite-plus / vite-task): the store protocol has to change to send the metadata and get a URL back, then PUT the blob, then publish. So this is a protocol change across both repos, not just this one.
  • Credentials: signing needs R2 S3 API credentials as Worker secrets, which the current binding-only setup doesn't need.

A smaller step that helps today, without a protocol change, is https://github.com/voidzero-dev/vite-plus-remote-cache-cloudflare/issues/48.

Vorherrschende Sprache
TypeScript
Sterne
8
Forks
0
Ø Merge
2 T. 10 Std.
Gemergte PRs (30 T.)
40

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus voidzero-dev/vite-plus-remote-cache-cloudflare

Alle Issues in voidzero-dev/vite-plus-remote-cache-cloudflare

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.