Files SDK

Was ist Files SDK?

Files SDK ist ein einheitliches Storage-SDK mit einer einzigen, konsistenten API für die Interaktion mit Objekt- und Blob-Storage-Backends. Ziel ist es, dieselben High-Level-Operationen wie Upload, Download, List, Delete und zugehörige Hilfsfunktionen aufzurufen, während unterschiedliche Anbieter im Hintergrund genutzt werden.

Es funktioniert über einen anbieterspezifischen Adapter. Dadurch bleiben die gemeinsamen Teile der Storage-Workflows stabil, während anbieterspezifische Unterschiede (etwa URL-bezogene Verhaltensweisen oder bestimmte Edge-Cases) im Adapter behandelt werden, ohne dass die Aufrufstellen geändert werden müssen.

Wichtige Funktionen

• Einzelne Files-Klasse für alle Anbieter: Eine API-Oberfläche für gängige Storage-Operationen (Upload, Download, List, Delete, Head, Exists, Copy und URL-Hilfsfunktionen) nutzen, statt für jedes Backend anbieterspezifischen Code zu schreiben.
• Adapter-basierte Auswahl des Anbieters beim Erstellen: Der Adapter wird beim Instanziieren von new Files({ adapter: ... }) festgelegt, damit keine „Anbieter pro Aufruf“-Muster entstehen, die die Nutzung erschweren.
• Unterstützung web-standardisierter Inputs: Akzeptiert File, Blob, ReadableStream, ArrayBuffer und string als Input für Uploads.
• Läuft überall dort, wo fetch verfügbar ist: Entwickelt für Umgebungen wie Node, Bun, Workers und Vercel (wie auf der Seite angegeben), um konsistentes Runtime-Verhalten zu gewährleisten.
• Anbieter-Escape-Hatch über files.raw: Bei Bedarf anbieterspezifischer Funktionen kann über eine Eigenschaft (files.raw) auf den nativen Client zuge<|eos|>

Alternativen

• Anbieterspezifische Storage-SDKs (z. B. S3/GCS/Azure-Native-Clients): Diese bieten vollständige Anbieterabdeckung, erfordern jedoch in der Regel unterschiedliche Codepfade für jedes Backend und eine separate Handhabung gängiger Aufgaben.
• Objektspeicher-Abstraktionsschichten ohne web-standards-konforme Eingaben: Einige Abstraktionen stellen eine einheitliche Schnittstelle bereit, unterstützen jedoch möglicherweise nicht dieselbe Auswahl web-nativer Eingabetypen oder fetch-orientierte Laufzeitannahmen.
• Serverseitige Datei-Upload-Bibliotheken mit Storage-Backend-Option: Nützlich, wenn das Hauptziel die Upload-Verarbeitung ist, aber sie geben möglicherweise nicht denselben Satz standardisierter Operationen (Head/Exists/Copy/URL-Helfer) und den Escape-Hatch-Zugriff auf den nativen Client frei.
• Direkte HTTP-Integration zu Object-/Blob-Endpunkten: Wenn Sie maximale Kontrolle benötigen, vermeidet die direkte Nutzung der HTTP-APIs der Anbieter eine Abstraktion, verlagert jedoch Listing, Signing, Fehler-Normalisierung und Anbieterunterschiede in Ihre Anwendung.