Wichtigste Erkenntnisse
- Benennen Sie den Bytepfad explizit: Weiterleitung durch die Anwendung, direkter Objektspeicher, direkter Verarbeitungsdienst oder Import aus einer Remote-Quelle.
- Behandeln Sie fortsetzbare Uploads, vollständige Wiederholungsversuche, Idempotenz und Ablaufzeiten als separate Zuverlässigkeitsmechanismen mit unterschiedlichem Fehlerverhalten.
- Belassen Sie die Upload-Autorisierung auf dem Server, validieren Sie die ermittelten Dateieigenschaften und veröffentlichen Sie ausschließlich aus einem kontrollierten dauerhaften Speicher.
Die Wahl einer Datei-Upload-API ist eine Architekturentscheidung, kein Vergleich von Widgets. Das richtige Design steuert, wohin Bytes übertragen werden, wer eine Übertragung autorisieren darf, wie unterbrochene Vorgänge fortgesetzt werden, wann eine Datei als vertrauenswürdig gilt, wo dauerhafte Kopien gespeichert sind und wie Verarbeitungsergebnisse an das Produkt zurückgegeben werden.
Worauf es besonders ankommt
- Entscheiden Sie sich für Eigenentwicklung, Zukauf oder ein hybrides Betriebsmodell, indem Sie die Anforderungen an Wiederherstellung, Sicherheit, Verarbeitung und Betrieb testen, nicht nur die Demo für den Idealfall.
- Verwenden Sie frameworkspezifische Beispiele nur, wenn deren Lebenszyklus, Serverautorisierung und Wiederherstellungsverhalten gewartet und getestet werden können.
Den Upload-Auftrag vor der Auswahl eines Widgets definieren
Ein produktiver Upload beginnt, bevor das erste Byte übertragen wird. Die Anwendung identifiziert den Nutzer, entscheidet, welcher Vorgang zulässig ist, legt die erlaubte Anzahl und Größe der Dateien fest und erstellt einen Datensatz, der länger als ein Browser-Tab bestehen kann. Die Übertragung ist nur eine Phase. Validierung, Verarbeitung, Export, Benachrichtigung und Abgleich bestimmen, ob das Produkt die Datei anschließend sicher verwenden kann.
Formulieren Sie einen Abschlussvertrag aus Produktsicht. „Die Anfrage gab 200 zurück“ ist wenig aussagekräftig; „Das Original und die erforderlichen Derivate sind unter diesem Mandanten gespeichert, der Asset-Datensatz nennt ihre Versionen und ein doppelter Callback ändert nichts“ ist testbar. Halten Sie fest, bei welchen Fehlern Nutzer einen erneuten Versuch starten dürfen, welche einen neuen Upload erfordern und welche einen für den Operator sichtbaren Zustand zur Wiederherstellung hinterlassen.
Steuerungsebene
Überträgt Identität, Autorisierung, Limits, Workflow-Auswahl, Metadaten, Status und Ergebnisreferenzen, nicht den Dateiinhalt selbst.
Datenebene
Überträgt Dateibytes zwischen Nutzer, Anwendung, Upload-Dienst, Verarbeitungsebene und dauerhaftem Speicherziel.
Vertrauensübergang
Kennzeichnet, wann ein nicht vertrauenswürdiger Upload die für Verarbeitung, Speicherung, Vorschau oder öffentliche Auslieferung erforderlichen Prüfungen bestanden hat.
Einen von vier expliziten Byte-Pfaden auswählen
Bei einer Weiterleitung über die Anwendung sendet der Browser die Datei an Ihren Server, der sie weiterleitet oder speichert. Das ist nachvollziehbar und gibt der Anwendung unmittelbare Kontrolle, doch jedes Byte beansprucht eingehende Bandbreite, Arbeitsspeicher oder temporären Festplattenspeicher, Verbindungszeit und ausgehende Bandbreite. Dieses Modell eignet sich für kleine, selten übertragene Dateien, wenn der vorhandene Server Limits durchsetzen und Daten sicher streamen kann, ohne vollständige Inhalte zwischenzuspeichern.
„Direkt in die Cloud“ ist mehrdeutig, benennen Sie daher das Ziel. Ein Browser kann mit kurzlebigen Zugangsdaten direkt in einen Objektspeicher oder direkt zu einem Verarbeitungsdienst wie Transloadit hochladen. Alternativ kann er einen Dienst anweisen, eine vorhandene Remote-URL zu importieren. Die direkte Speicherung minimiert Übertragungsstationen, wenn die dauerhafte Speicherung die einzige Aufgabe ist. Bei der direkten Verarbeitung bleibt die Anwendung außerhalb des Datenpfads, während ein Workflow Dateien validiert, transformiert und in einen eigenen Speicher exportiert.
Weiterleitung über die Anwendung
Geeignet für überschaubare Workloads und einfache Richtlinien, doch die Anwendung ist für Übertragungskapazität, Zeitüberschreitungen, temporäre Dateien und Skalierung verantwortlich.
Direkte Objektspeicherung
Optimal, wenn die erste dauerhaft gespeicherte Kopie das Hauptergebnis ist und die spätere Verarbeitung zuverlässig durch ein Speicherereignis oder eine Warteschlange ausgelöst werden kann.
Direkter Verarbeitungsdienst
Geeignet, wenn Upload und asynchrone Validierung, Derivate, Metadaten oder der Export an mehrere Ziele zu einem einzigen beobachtbaren Verarbeitungsvorgang gehören.
Import aus Remote-Quellen
Überträgt Bytes von Server zu Server. Das schont die Verbindung des Nutzers, erfordert jedoch eine explizite Autorisierung der Quelle und Abruflimits.
Wiederaufnahme getrennt von Wiederholungsversuchen konzipieren
Ein Wiederholungsversuch startet einen Vorgang erneut; eine fortsetzbare Übertragung setzt dagegen einen bestehenden Upload ab einem vom Server bestätigten Byte-Offset fort. Bei tus behält der Client die Upload-URL, fragt den Server nach Upload-Offset und sendet nur die verbleibenden Bytes. Speichern Sie diese URL außerhalb des flüchtigen Komponentenzustands, wenn nach einem Neuladen oder Absturz eine Wiederherstellung möglich sein soll. Erstellen Sie zudem sorgfältig Fingerprints der Dateien, damit die lokale Datei eines Nutzers niemals der Upload-Ressource eines anderen zugeordnet wird.
Fortsetzbare Uploads bedeuten weder unbegrenzte Zeit noch eine idempotente Verarbeitung. Eine Transloadit Assembly hat ab ihrer Erstellung weiterhin acht Stunden Zeit, um den Upload abzuschließen. Das Erstellen einer Ersatz-Assembly kann Arbeit duplizieren, sofern die Anwendung die alte Kennung nicht abgleicht. Legen Sie fest, wie der Client mit Pausen, Offline-Zeiten, abgelaufenen Ressourcen, geänderten Dateien, abgebrochenen Uploads und einer verlorenen Abschlussantwort umgeht, nachdem der Server die letzten Bytes akzeptiert hat.
Identität für die Fortsetzung
Speichern Sie die vom Server ausgegebene Upload-URL zusammen mit dem authentifizierten Nutzer, dem Fingerprint der lokalen Datei, der erwarteten Länge und dem Vorgangsdatensatz dauerhaft.
Ablaufpfad
Wenn die Upload-Ressource oder Assembly abgelaufen ist, erstellen Sie einen neuen Vorgang und mustern Sie die veraltete Kennung aus, statt es unbegrenzt erneut zu versuchen.
Abgleich des Abschlusses
Fragen Sie nach mehrdeutigen Netzwerkfehlern den dauerhaft gespeicherten Status ab, damit der Client aus einer fehlenden Antwort nicht auf fehlende Bytes schließt.
Die Absicht serverseitig autorisieren und den Bytes misstrauen
Ein öffentlicher Auth Key darf im Browsercode enthalten sein, das Auth Secret von Transloadit oder dauerhafte Zugangsdaten für den Speicher jedoch niemals. Authentifizieren Sie den Nutzer in Ihrer Anwendung, wählen Sie serverseitig ein gespeichertes Template aus und geben Sie kurzlebige signierte Parameter mit einer eindeutigen nonce zurück. Setzen Sie allow_steps_override auf false, wenn es keinen legitimen Grund dafür gibt, dass der Browser Steps ersetzt, da ein vom Client ausgewählter Step-Graph andernfalls die Verarbeitung oder das Exportverhalten ändern könnte.
Eine gültige Signatur belegt, dass die Parameter-Nutzlast autorisiert wurde. Sie belegt nicht, dass die hochgeladenen Bytes mit einem Dateinamen, einer Dateiendung, einem deklarierten MIME-Typ, einem Mandanten oder einer Moderationsrichtlinie übereinstimmen. Begrenzen Sie Anfrageinhalte vor rechenintensiven Arbeiten, untersuchen Sie die ermittelten Dateieigenschaften, lehnen Sie nicht unterstützte Inhalte ab und führen Sie Scans durch, wenn das Bedrohungsmodell dies erfordert. Halten Sie außerdem nicht vertrauenswürdige Ausgaben von öffentlichen Speichern fern, bis der Workflow einen genehmigten Zustand erreicht.
Kurzlebige Autorisierung
Erteilen Sie die Upload-Berechtigung erst nach der Authentifizierung durch die Anwendung, beschränken Sie sie zeitlich und begrenzen Sie ihren Umfang auf einen serverseitig ausgewählten Vorgang.
Ermittelte Eigenschaften
Verwenden Sie den erkannten Typ, die Abmessungen, die Dauer und weitere untersuchte Metadaten für die Weiterleitung, statt allein der Dateiendung zu vertrauen.
Quarantäne vor Veröffentlichung
Trennen Sie den Empfang von der öffentlichen Auslieferung, damit ungültige, schädliche oder aufgrund von Richtlinien abgelehnte Dateien nicht standardmäßig zu Assets der Anwendung werden.
Dauerhaften Speicher von der Upload-Verarbeitung trennen
Ein Upload-Endpunkt ist nicht automatisch ein führendes System. Legen Sie fest, welchem Bucket oder welcher Asset-Datenbank das Original zugeordnet ist, wie Derivate damit verknüpft sind, welche Kennungen Umbenennungen überdauern und wer jede Kopie löscht. Wenn eine Transloadit Assembly keinen Export-Step enthält, werden temporäre Dateien nach 24 Stunden gelöscht, und ihre Zugriffs-URLs können nach wenigen Stunden ablaufen. Die URLs sind nur für den kurzfristigen Abruf vorgesehen, nicht für das Einbetten oder die wiederholte Auslieferung im Produkt.
Integrieren Sie den Export in die Assembly, wenn der Workflow nur bei erfolgreicher Verarbeitung und dauerhafter Speicherung als erfolgreich gilt. Ein Export-Robot kann gespeicherte Template-Zugangsdaten verwenden, um Ergebnisse im Rahmen des Workflows an das ausgewählte Ziel zu schreiben. Alternativ können Sie Dateien zunächst direkt in einen eigenen Speicher hochladen und die Verarbeitung durch ein kontrolliertes Ereignis auslösen. Dieser Pfad erzeugt frühzeitig eine dauerhafte Kopie, erfordert jedoch zusätzliche Orchestrierung und eine weitere Übertragung an den Verarbeitungsdienst.
Zuständigkeit für das Original
Legen Sie fest, ob und wie lange das Original aufbewahrt wird, unter welchem Mandantenschlüssel dies geschieht und ob spätere Workflows erneut darauf zugreifen dürfen.
Abstammung der Derivate
Speichern Sie die Quellkennung, die Workflow-Konfiguration, die Rolle der Ausgabe, die Abmessungen, das Format und die Prüfsumme, die zur Nachvollziehbarkeit jedes Ergebnisses erforderlich sind.
Auslieferungsgrenze
Liefern Sie genehmigte Assets aus dauerhaftem Speicher und über eine bewusst gewählte Auslieferungsschicht statt über temporäre Verarbeitungs-URLs aus.
An der Eigentumsgrenze zwischen Eigenentwicklung und Zukauf entscheiden
Entwickeln Sie den Übertragungspfad selbst, wenn die Anforderungen eng begrenzt sind und das Team bereit ist, den gesamten Lebenszyklus zu verantworten. Ein kleines authentifiziertes Formular, das kurze Dateien per Streaming in einen bestehenden Bucket überträgt, rechtfertigt möglicherweise keine weitere Plattform. Die Schätzung muss dennoch Multipart-Parsing, Backpressure, die Durchsetzung von Größenlimits, fortsetzbare Uploads oder deren bewussten Verzicht, Bereinigung, Schutz vor Missbrauch, Beobachtbarkeit, Upgrades und die Behandlung von Fehlern außerhalb der Lebensdauer der Anfrage berücksichtigen.
Ein verwalteter Dienst wird attraktiver, wenn der Workflow unzuverlässige Netzwerke, große Dateien, Browser-UX, Remote-Quellen, Medienprüfung, Transformation oder mehrere Speicherziele kombiniert. Der Zukauf entbindet Sie nicht von der Verantwortung für Ihre Anwendung: Mandantenprüfungen, Autorisierung, Asset-Datensätze, Aufbewahrung, Veröffentlichung und Vorfallbehandlung bleiben in Ihrer Hand. Oft eignet sich eine hybride Architektur am besten, bei der eigener Speicher und der Geschäftszustand eine verwaltete Übertragungs- und Verarbeitungsebene umgeben.
Kosten der Eigenentwicklung
Berücksichtigen Sie Entwicklung, Infrastruktur, Bereitschaftsdienst, Protokollwartung, Sicherheitsprüfungen und Nutzersupport, nicht nur die Gebühren für Objektspeicher.
Kosten des Zukaufs
Modellieren Sie Upload-Bytes, Verarbeitungsvorgänge, Wiederholungsversuche, Speicherübertragungen, Mindestgebühren, Supportniveau und erwartetes Wachstum.
Hybride Zuständigkeit
Behalten Sie Identität, Richtlinien, Metadaten und dauerhaften Speicher in Ihrem Produkt, während Sie den spezialisierten Datenpfad und die Verarbeitung delegieren.
Anbieter mit Fehlertests statt anhand der Funktionsanzahl vergleichen
Erstellen Sie eine Bewertungsmatrix anhand der tatsächlichen Auslastung Ihres Produkts. Vergleichen Sie Browser- und mobile Clients, die Unterstützung offener Protokolle, die maximale Dateigröße, das Verhalten bei parallelen Vorgängen, geografische Endpunkte, Remote-Importe, den Verarbeitungsumfang, Speicherziele, die Isolierung von Zugangsdaten, die Webhook-Verifizierung, die Aufbewahrung von Statusdaten, den Support und Ausstiegsoptionen. Kennzeichnen Sie jede Funktion als erforderlich, optional oder irrelevant, bevor Sie sich Anbieterseiten ansehen.
Testen Sie jeden ernst zu nehmenden Kandidaten mit denselben Testdaten. Unterbrechen Sie einen großen Upload, laden Sie die Seite neu, senden Sie ein doppeltes Abschlussereignis, widerrufen Sie Speicherzugangsdaten, lehnen Sie eine Datei nach dem Empfang ab, überschreiten Sie einen Grenzwert und lassen Sie die abschließende Antwort verloren gehen. Messen Sie die für Nutzer sichtbare Wiederherstellung, erneut übertragene Bytes, die Zeit bis zu einem dauerhaft gespeicherten Ergebnis, Nachweise für den Betrieb und die Bereinigung. Eine ausgereifte Dateiauswahl sagt wenig darüber aus, wie sich das System unter echten Produktionsbedingungen verhält.
Protokollportabilität
Ein offenes Protokoll für fortsetzbare Uploads und austauschbare Clients verringern die Migrationskopplung, doch Workflow- und Ergebnisschemata erfordern weiterhin eine Migrationsplanung.
Betriebliche Nachweise
Fordern Sie stabile Auftragskennungen, Endzustände, Zeitstempel, verwertbare Fehlermeldungen, verifizierte Callbacks und ein dokumentiertes Verfahren zur erneuten Ausführung.
Gesamtwirtschaftlichkeit
Vergleichen Sie bei einem repräsentativen monatlichen Volumen die Kosten für Übertragung, Verarbeitung, Speicher, Auslieferung, Support, Entwicklung und Wiederherstellung nach Fehlern.
Einen signierten Upload mit Uppy und Transloadit implementieren
Im Browserbeispiel übernimmt Uppy die Dateiauswahl und die tus-Übertragung, während das Transloadit-Plugin Assembly-Parameter von Ihrer Anwendung anfordert. Der Serverendpunkt muss den aktuellen Nutzer authentifizieren, bevor er das Objekt aus calcSignature zurückgibt. Er sollte das Template selbst auswählen, statt beliebige Steps oder ein vom Aufrufer vorgegebenes Speicherziel zu akzeptieren, und er sollte die Anfragerate für Autorisierungen unabhängig vom Upload-Datenverkehr begrenzen.
Der Auth Key identifiziert den Workspace und kann in den zurückgegebenen Parametern enthalten sein; das Auth Secret verbleibt im Serverprozess. Deaktivieren Sie im gespeicherten Template Step-Überschreibungen, sofern sie nicht für einen geprüften Anwendungsfall erforderlich sind. Legen Sie fest, ob die Benutzeroberfläche auf das Encoding wartet oder nach dem Upload zurückkehrt. Speichern Sie die Assembly ID in beiden Fällen, damit ein Hintergrundprozess oder ein verifizierter Webhook das Endergebnis abgleichen kann.
import Uppy from '@uppy/core'
import Transloadit from '@uppy/transloadit'
const uppy = new Uppy().use(Transloadit, {
async assemblyOptions() {
const response = await fetch('/api/transloadit-params', {
credentials: 'same-origin',
})
if (!response.ok) {
throw new Error('Could not authorize this upload')
}
return response.json()
},
waitForEncoding: true,
})
uppy.on('transloadit:complete', (assembly) => {
console.log(assembly.assembly_id, assembly.results)
})import { randomUUID } from 'node:crypto'
import { Transloadit } from 'transloadit'
function requiredEnvironmentValue(name: string): string {
const value = process.env[name]
if (value == null) throw new Error(`Missing environment variable: ${name}`)
return value
}
const transloadit = new Transloadit({
authKey: requiredEnvironmentValue('TRANSLOADIT_KEY'),
authSecret: requiredEnvironmentValue('TRANSLOADIT_SECRET'),
})
export function createAuthorizedUploadParameters() {
// Call this only after the server has authenticated the request and authorized the operation.
return transloadit.calcSignature({
auth: {
expires: new Date(Date.now() + 5 * 60 * 1000).toISOString(),
nonce: randomUUID(),
},
template_id: requiredEnvironmentValue('TRANSLOADIT_UPLOAD_TEMPLATE_ID'),
})
}Annahme, Validierung, Verarbeitung und Export verbinden
Das Template nimmt Browser-Uploads über /upload/handle an, prüft die erkannte MIME-Familie mit /file/filter, erstellt über /image/resize eine begrenzte Vorschau und exportiert mit /s3/store sowohl das akzeptierte Original als auch die Vorschau. Mit den benannten Template-Zugangsdaten bleiben die Bucket-Zugangsdaten aus den Browserparametern heraus, während allow_steps_override verhindert, dass ein Aufrufer dieses Ziel durch eine Step-Überschreibung ersetzt.
Betrachten Sie dies als minimales Architekturbeispiel und nicht als allgemeingültige Sicherheitsrichtlinie. Ergänzen Sie gemäß dem Bedrohungsmodell des Produkts Regeln für die maximale Upload-Größe, die Dateianzahl, Virenprüfungen, Moderation, Benennung, Aufbewahrung und Ziele. Speichern Sie die Assembly ID und die Datensätze der exportierten Ergebnisse unter dem authentifizierten Mandanten. Prüfen Sie außerdem, ob jede erwartete Ausgabe den dauerhaften Speicher erreicht hat, bevor die Anwendung das Asset als bereit markiert.
{
"allow_steps_override": false,
"steps": {
":original": {
"robot": "/upload/handle"
},
"accepted_images": {
"use": ":original",
"robot": "/file/filter",
"accepts": [
["${file.mime}", "regex", "^image/"]
],
"error_on_decline": true
},
"preview": {
"use": "accepted_images",
"robot": "/image/resize",
"resize_strategy": "fit",
"width": 1600,
"height": 1600
},
"exported": {
"use": ["accepted_images", "preview"],
"robot": "/s3/store",
"credentials": "my_s3_credentials",
"path": "uploads/${file.id}/${file.url_name}"
}
}
}Wissenswerte technische Details
- Bei einem Upload vom Browser an die Anwendung wird der Anwendungsserver Teil des Datenpfads. Ein Konzept mit direkter Speicherung oder direkter Verarbeitung hält die Dateibytes dagegen aus diesem Request-Handler heraus.
- Das tus-Kernprotokoll setzt einen unterbrochenen Upload fort, indem es den serverseitigen
Upload-OffsetmitHEADausliest und mitPATCHweiterüberträgt; die gesamte Datei erneut zu senden ist ein Wiederholungsversuch, keine Wiederaufnahme. - Das Transloadit-Plugin von Uppy verwendet tus für die Dateiübertragung und kann mithilfe seiner Funktion
assemblyOptionssignierte Assembly-Parameter von einem Anwendungs-Backend anfordern. - Transloadit Signature Authentication signiert die JSON-codierten Parameter auf einem vertrauenswürdigen Server mit dem Auth Secret; das Geheimnis selbst darf niemals an Browsercode gesendet werden.
- Ein gespeichertes Template, bei dem
allow_steps_overrideauf false gesetzt ist, verhindert, dass ein nicht vertrauenswürdiger Client die zugehörigen Steps ersetzt oder durch Überschreibungen von Steps ein anderes Speicherziel auswählt. - Ohne Export-Robot löscht Transloadit temporäre Dateien nach 24 Stunden. Ihre temporären URLs können bereits nach wenigen Stunden ablaufen und sind nur für einen begrenzten, kurzfristigen Abruf vorgesehen.
- Bei tus-Uploads an Transloadit wird die Assembly erstellt, bevor die Dateibytes eintreffen, und verbleibt in
ASSEMBLY_UPLOADING, bis die deklarierten Uploads abgeschlossen sind. - Das Zeitfenster für Uploads bei Transloadit beträgt ab der Erstellung der Assembly acht Stunden. Daher benötigt auch ein Client für fortsetzbare Uploads einen ausdrücklich vorgesehenen Ablauf für einen Neustart, wenn die Assembly abgelaufen ist.
Ein praxisnaher Ansatz
- 1
Dokumentieren Sie den Bytepfad, die Vertrauensübergänge, den dauerhaften Eigentümer und den Abschlussvertrag, bevor Sie einen Dateiuploader auswählen.
- 2
Testen Sie Optionen für die Weiterleitung, den direkten Speicher und die direkte Verarbeitung mit repräsentativen Dateien und Netzwerkausfällen.
- 3
Implementieren Sie kurzlebige serverseitige Autorisierung, fortsetzbare Uploads, Validierung, Export und eine idempotente Ergebnisverarbeitung.
- 4
Führen Sie Lasttests für den gewählten Pfad durch und proben Sie abgelaufene Autorisierungen, doppelte Callbacks, widerrufene Zugangsdaten und Teilausfälle.
Wann Transloadit hilfreich ist
Verwenden Sie Transloadit, wenn Uploads mit tus fortsetzbar sein müssen oder wenn Sie die Browser-UX von Uppy, den Import aus Remote-Quellen, eine mehrstufige Dateiverarbeitung oder Exporte in von Ihnen kontrollierten Speicher benötigen. Die genauen Parameterverträge finden Sie in der Robot-Dokumentation zu /upload/handle, /file/filter, /image/resize und /s3/store.
Architekturgrenze
Transloadit kann Dateien empfangen, asynchrone Verarbeitungsworkflows ausführen und Ergebnisse exportieren. Ihre Anwendung bleibt jedoch für die Nutzerauthentifizierung, die Mandantenautorisierung, den dauerhaft gespeicherten Datensatz des Assets, die Veröffentlichungsrichtlinie und die Auslieferung aus dem permanenten Speicher verantwortlich.
Häufig gestellte Fragen
Was bedeutet „direkter Cloud-Upload“?
Damit ist nicht nur eine Architektur gemeint. Es kann sich um eine Übertragung vom Browser in den Objektspeicher, vom Browser an einen Verarbeitungsdienst oder um einen Server-zu-Server-Import von einem anderen Anbieter handeln. Benennen Sie das tatsächliche Ziel der Bytes, den Autorisierungsmechanismus, den dauerhaften Eigentümer und den Verarbeitungsauslöser, bevor Sie Implementierungen vergleichen.
Sollten Dateien meinen Anwendungsserver durchlaufen?
Nur wenn der Vorteil für Richtlinien oder Einfachheit die Verantwortung für den Datenpfad überwiegt. Das Weiterleiten kann sich für kleine, seltene Uploads eignen. Bei der direkten Speicherung oder Verarbeitung werden jedoch nicht für jedes Byte Anwendungsbandbreite, Anfragezeit, temporärer Speicherplatz und Verbindungskapazität beansprucht.
Ist ein Wiederholungsversuch dasselbe wie ein fortsetzbarer Upload?
Nein. Ein Wiederholungsversuch startet die Übertragung normalerweise erneut, während bei der Wiederaufnahme eine vorhandene Ressource ab dem vom Server bestätigten Byte-Offset fortgesetzt wird. Der Client muss die Upload-Identität beibehalten und weiterhin mit Ablaufzeiten, geänderten lokalen Dateien und mehrdeutigen abschließenden Antworten umgehen.
Speichert Transloadit hochgeladene Dateien dauerhaft?
Nein, es sei denn, der Workflow exportiert sie an ein dauerhaftes Ziel. Ohne Export-Robot werden temporäre Dateien nach 24 Stunden gelöscht, und ihre URLs können nach wenigen Stunden ablaufen. Produktiv-Workflows sollten die Dateien in einen kontrollierten Speicher exportieren oder diese URLs nur verwenden, um sie kurzfristig und in begrenztem Umfang in die eigene Infrastruktur abzurufen.
Wann sollte ich eine Upload-API selbst entwickeln, statt sie zu kaufen?
Eine Eigenentwicklung kann für einen eng begrenzten Pfad mit kleinen Dateien, einem Speicherziel, vorhersehbaren Netzwerken und einem Team sinnvoll sein, das Sicherheit und Betrieb vollständig verantworten kann. Verwaltete Infrastruktur rechtfertigt ihre Kosten, wenn fortsetzbare Uploads, Remote-Quellen, große Dateien, Verarbeitung, mehrere Ziele oder die Wiederherstellung nach Fehlern sonst zu einem eigenen Produkt würden.
Was gehört in einen frameworkspezifischen Upload-Leitfaden?
Ein Framework-Leitfaden sollte sich auf wartbaren Code, das Lebenszyklusverhalten, die serverseitige Autorisierung, die Wiederherstellung und Tests für dieses Framework konzentrieren. Die verlinkten Referenzen zur Wiederaufnahme und API enthalten die genauen Protokoll- und Anfrageverträge. Bewerten Sie Anbieter anhand der weiter oben beschriebenen umfassenderen Architekturanforderungen.