Cas d’usage
Des pièces jointes à côté des données
Les blobs qu’une app détient, transportés comme des objets, avec les enregistrements qui les désignent dans le snapshot.
// Each blob becomes an object; the record keeps the key.
const stored = await store.upload(blob, { filename: 'scan.pdf', prefix: `attachments/${code}` })
record.attachmentKey = stored.key
// The snapshot carries the records, not the bytes.
await store.putSnapshot(code, { records }, { expiresIn: 3600 })
// On the other device, fetch on demand.
const url = await store.getUrl(record.attachmentKey, { expiresIn: 600 })La situation
Ce qui se passe vraiment.
Le problème
IndexedDB stocke les Blobs nativement, donc les apps local-first finissent par garder des images, des enregistrements et des PDF à côté de leurs données. Du base64 dans un snapshot JSON les gonfle d’un tiers et neutralise gzip : trois façons d’atteindre le plafond de taille en même temps.
Ce que s3nd y fait
Utilisez l’API de fichiers sous les snapshots. Envoyez chaque blob comme un objet, gardez sa clé dans l’enregistrement, et laissez le snapshot transporter des références. L’appareil qui reçoit récupère ce dont il a besoin, quand il en a besoin, via une URL présignée si vous préférez que les octets ne transitent jamais par votre serveur.
À surveiller
Les choses faciles à rater.
Même préfixe, même cycle de vie
Placez les pièces jointes sous un préfixe qui partage la règle d’expiration du transfert, sinon elles survivent au snapshot auquel elles appartenaient.
Les streams ont besoin d’une longueur
Un PutObject unique ne peut pas utiliser l’encodage par morceaux. Passez contentLength pour un stream ; les buffers et les Blobs connaissent déjà leur taille.
Voir aussi
D’autres formes de la même primitive.
Déposez un fichier. Donnez le code.
Pointez-le sur le bucket que vous payez déjà. Rien à déployer, aucune inscription, personne au milieu.