Upload blobs straight to R2 with presigned URLs

Aperta
  • Qualcosa non va?
#49 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
aws, typescript
Ambito
backend-api-design, cloud

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
TypeScript
Stelle
8
Fork
0
Merge medio
2g 10h
PR unite (30g)
40

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di voidzero-dev/vite-plus-remote-cache-cloudflare

Tutte le issue di voidzero-dev/vite-plus-remote-cache-cloudflare

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.