Migration von Filestack zu Transloadit

Filestack bietet Dateiauswahl, Uploads, Speicherung und CDN-Transformationen⁠ sowie asynchrone Workflows⁠. Bei Transloadit übernimmt Uppy die Dateiauswahl im Browser, und Robots übernehmen die Dateiverarbeitung. Definieren Sie einen unterstützten Workflow in einem Template und verwenden Sie dann ein SDK, Uppy oder die REST-API, um Assemblies zu erstellen. Prüfen Sie die von Ihrer Anwendung genutzten Aufgaben einzeln; die folgende Zuordnung verspricht keine vollständige Funktionsparität.

Dieser Leitfaden behandelt die Verarbeitung und den Export von Dateien in einen Speicher, den Sie selbst kontrollieren. Er implementiert keine gehostete Transloadit-DAM-Migration. Der Import in eine gehostete Media Library, der Erhalt ihrer Ordner und Metadaten, die Auslieferung über tlcdn.com, Migrations-Testläufe und Manifeste sowie Media-Library-Rollen, Widgets und CMS-/Editor-Integrationen erfordern einen separaten Migrationsplan. Das im Folgenden beschriebene Inventar ist ein anwendungsseitig geführtes Migrationsprotokoll, kein gehostetes DAM-Migrationstool.

Migrationszuordnung

Filestack-Storage-Aliase machen bestehenden externen Speicher für den Verarbeitungsdienst zugänglich, ohne einen Upload über Filestack. Wenn Sie den Quell-Bucket bereits selbst besitzen, entscheiden Sie, ob Originale dort verbleiben können, während Sie neue Derivate verarbeiten und exportieren. Bei von Filestack verwaltetem Speicher laden Sie autorisierte Originale über das CDN⁠ herunter, bevor Sie das Konto stilllegen. Dieser Leitfaden stellt kein Skript für einen Massenexport oder die Asset-Erkennung des Kontos bereit.

Bewahren Sie den Katalog separat auf. Erfassen Sie vor dem Kopieren der Bytes Ihre Asset-ID, das Filestack-Handle, die ursprüngliche Download-URL, den Speicherort/Container/Pfad, den Dateinamen, den MIME-Typ, die Größe, die Prüfsumme und die benötigten Derivate. Der Metadaten-Endpunkt⁠ von Filestack kann Dateifakten, Speicherinformationen und Hashes zurückgeben; er erzeugt diese Informationen bei Bedarf. Bewahren Sie das Quellinventar und die fertige Assembly-/Export-Zuordnung in Ihrer eigenen Datenbank auf.

Die Picker-Upload-Tags⁠ von Filestack werden in Upload-Antworten und Webhooks zurückgegeben. Mit dem DAM⁠ können Benutzer außerdem Asset-Tags und Asset-Beschreibungen bearbeiten. Bewahren Sie diese Datensätze getrennt von den Dateimetadaten auf; die folgenden Templates kopieren und verarbeiten Bytes, nicht Katalog-Tags oder -Beschreibungen. Verwenden Sie erfasste Speicherpfade, um zu entscheiden, wie Ziel-Objektschlüssel Ordner bewahren; diese Beispiele erzeugen neue Pfade. Erfassen Sie alle Collections und Revisionsbeziehungen, die Ihre Anwendung nutzt, einschließlich ihrer Reihenfolge und Berechtigungen. Die Überschreib-Operation⁠ von Filestack ersetzt die Datei hinter einem Handle, sodass ein Download kein Export der Versionshistorie ist. Dieser Leitfaden exportiert weder Collection-Zugehörigkeit noch historische Revisionen; beziehen Sie diese bei Bedarf vor dem Wechsel aus Ihrer Anwendung oder dem bestehenden Archiv.

Ein Template für jeden Workflow erstellen

Übersetzen Sie Transformationsrezepte. Die Processing Engine⁠ von Filestack akzeptiert Tasks in CDN-URLs, während ihre Workflows Tasks und bedingte Logik definieren. Erfassen Sie die vollständige Task-Kette, Parameter, benannte anwendungsspezifische Voreinstellungen, Workflow-IDs und Bedingungen, die von jeder Ansicht der Anwendung genutzt werden. Bauen Sie die benötigten Rezepte als Templates nach, erzeugen Sie die Derivate und vergleichen Sie repräsentative Bilder und Dokumente hinsichtlich Zuschnitt, Seitenverhältnis, Ausrichtung, Seitenauswahl, Qualität und Format. Ein Thumbnail-Robot ersetzt nicht den interaktiven Filestack Document Viewer⁠; wählen Sie einen separaten Viewer, falls Ihre Anwendung einen benötigt. Die folgenden Beispiele decken Bild-/PDF-Vorschauen und eine generische Dateivorschau ab; sie bilden nicht jede Filestack-Transformation oder -Intelligence-Task nach.

Dieses Template prüft den erkannten MIME-Typ, erstellt ein Bild-Thumbnail oder ein Thumbnail der ersten PDF-Seite und speichert akzeptierte Originale und Vorschauen. Andere MIME-Typen beenden die Assembly mit einem Fehler. Dies ist eine Typfilterung, kein Malware-Scan; fügen Sie /file/virusscan hinzu, falls Ihr Workflow dies erfordert:

{
  "steps": {
    ":original": {
      "robot": "/upload/handle"
    },
    "accepted_files": {
      "use": ":original",
      "robot": "/file/filter",
      "accepts": [["${file.mime}", "regex", "^(image/[^/]+|application/pdf)$"]],
      "error_on_decline": true
    },
    "images": {
      "use": "accepted_files",
      "robot": "/file/filter",
      "accepts": [["${file.mime}", "regex", "^image/"]]
    },
    "pdfs": {
      "use": "accepted_files",
      "robot": "/file/filter",
      "accepts": [["${file.mime}", "=", "application/pdf"]]
    },
    "image_thumb": {
      "use": "images",
      "robot": "/image/resize",
      "width": 600,
      "height": 600,
      "resize_strategy": "fit",
      "format": "webp",
      "result": true
    },
    "document_thumb": {
      "use": "pdfs",
      "robot": "/document/thumbs",
      "format": "jpg",
      "page": 1,
      "width": 600,
      "resize_strategy": "fit",
      "result": true
    },
    "exported": {
      "use": ["accepted_files", "image_thumb", "document_thumb"],
      "robot": "/s3/store",
      "credentials": "YOUR_AWS_CREDENTIALS",
      "path": "filestack-import/${unique_prefix}/${file.url_name}",
      "url_prefix": "https://cdn.example.com/",
      "acl": "bucket-default"
    }
  }
}

Die beiden Routing-Filter verwenden MIME-Typen, um Bilder und PDFs auf getrennten Vorschauzweigen zu halten. Abgelehnte Originale gelangen nie in den Export-Step. Eine Assembly ist keine Transaktion: bereits exportierte akzeptierte Dateien werden nicht zurückgerollt, wenn eine andere Datei fehlschlägt. Fehler ignorieren unterdrückt Fehlschläge; dies ersetzt nicht Routing oder Validierung.

Verfolgen Sie die von jedem Backfill-Versuch geschriebenen Speicherobjekte. Bevor Sie eine fehlgeschlagene Assembly erneut ausführen, gleichen Sie deren Teilexporte ab oder löschen Sie sie, damit erneute Versuche keine doppelten oder verwaisten Objekte hinterlassen. Veröffentlichen Sie fehlgeschlagene Versuche in Ihrer Anwendung nicht, selbst wenn einige Dateien erfolgreich exportiert wurden.

Konfigurieren Sie Ihr CDN so, dass es die Bucket-Wurzel liest; url_prefix ändert nur die zurückgegebenen URLs. acl: "bucket-default" sendet keine Objekt-ACL; konfigurieren Sie den Zugriff über Ihre Bucket-Richtlinie und den CDN-Ursprungszugriff. Nach ASSEMBLY_COMPLETED lesen Sie akzeptierte Originale aus results.accepted_files und Vorschauen aus results.image_thumb und results.document_thumb. Der Export fügt Einträge unter den im Parameter use genannten Steps hinzu oder aktualisiert sie, sofern dieser Step nicht ausdrücklich result: false setzt. Speichern Sie nur Einträge mit is_temp_url: false. Temporäre Transloadit-URLs laufen nach 24 Stunden ab; siehe Ergebnisse der Konvertierung speichern.

Dateiauswahl ersetzen

Ersetzen Sie für Browser-Integrationen den Filestack-Picker durch Uppy. Uppy kann lokale Dateien auswählen, Uploads per Drag-and-Drop entgegennehmen und Remote-Quellen verbinden. Das Transloadit-Plugin sendet Dateien mit Ihrem Template an eine Assembly. Aktivieren Sie waitForEncoding, um fertige Verarbeitungsergebnisse im Browser zu erhalten, oder setzen Sie notify_url in Ihrer signierten Assembly-Anfrage und verarbeiten Sie Assembly Notifications auf Ihrem Backend. Überprüfen Sie Notification-Signaturen und verlangen Sie einen erfolgreichen Abschluss, bevor Sie Ihre Datenbank aktualisieren.

Die Picker-Antwort⁠ von Filestack enthält Datei-Handles, URLs und Upload-Metadaten; onUploadDone meldet hochgeladene und fehlgeschlagene Dateien. Schreiben Sie Handler, die diese Antwortform erwarten, neu und testen Sie Abbruch, Wiederholungsversuche, erlaubte Dateitypen/-größen, Barrierefreiheit und jeden Autorisierungsablauf für Remote-Quellen. Bewahren Sie Katalog-Tags auf Ihrem Backend auf und verknüpfen Sie sie mit Ihrer Asset-ID, anstatt anzunehmen, dass Picker-Metadaten den Export überdauern.

Ersetzen Sie Automatisierung und Sicherheit bewusst. Die Webhooks⁠ von Filestack haben ereignisspezifische Payloads und verwenden die Header FS-Timestamp und FS-Signature zur Verifizierung. Die Workflow-Job-Ergebnisse sind kein Assembly-Status-Payload. Implementieren Sie den Transloadit-Empfänger anhand seines eigenen dokumentierten Vertrags und Signaturschemas. Gestalten Sie Datenbankaktualisierungen idempotent, bewahren Sie die Assembly-ID auf und gleichen Sie Teilexporte ab, bevor Sie die Verarbeitung erneut ausführen. Trennen Sie den Upload-Abschluss von erfolgreicher Verarbeitung und Export, bevor Sie ein Asset veröffentlichen.

Die Sicherheitsrichtlinien⁠ von Filestack verwenden mit HMAC-SHA256 signierte Base64URL-Richtlinien und können Ablaufzeit, Aufrufe, Handles, Upload-Pfade/-Container und Größe einschränken. Upload- und Auslieferungsauthentifizierung sind konfigurierbar; erfassen Sie, was Ihre Anwendung tatsächlich durchsetzt. Bauen Sie die Upload-Autorisierung mit Transloadit-Authentifizierung auf Ihrem Backend nach und konfigurieren Sie die Download-Autorisierung über Ihren Speicher/CDN. Bestehende Filestack-Richtlinien und -Signaturen autorisieren den Ersatzdienst nicht. Machen Sie private Exporte niemals nur deshalb öffentlich, um eine signierte Quell-URL zu ersetzen. Die S3-Upload-Zugriffseinstellung⁠ von Filestack steuert den Zugriff auf gespeicherte Objekte; überprüfen Sie Ziel-Bucket-Richtlinie, CDN-Ursprungszugriff und jedes signierte Download-Schema getrennt von der Assembly-Authentifizierung. Die Export-Beispiele setzen acl: "bucket-default"; überprüfen Sie die Zielrichtlinie vor der Migration.

Die Virus Detection⁠ von Filestack läuft nach dem Upload in den Speicher asynchron über Workflows. Falls Sie diese Funktion nutzen, entwerfen und testen Sie das Ersatz-Scan-/Quarantäne-Gate, bevor Sie Originale oder Vorschauen veröffentlichen. Weder die MIME-Filterung noch ein erfolgreicher Upload belegt, dass eine Datei sicher ist.

Berücksichtigen Sie Agent-Tooling. Das Filestack Claude Plugin⁠ stellt Tools für Uploads, Transformationen, Richtliniensignierung, Workflow-Ausführung und Webhook-Verifizierung bereit. Erfassen Sie die tatsächlichen URLs und Workflows, die von diesen Tools erzeugt oder aufgerufen werden. Bauen Sie benötigte Operationen mit überprüften Template-Definitionen und SDK-/API-Aufrufen nach; dieser Leitfaden bietet keinen direkten Ersatz für das Plugin oder dessen Intelligence-Modelle. Bewahren Sie Template-Revisionen, Assembly-IDs, Ausgabeprüfungen und Wiederholungsentscheidungen für Support und Überprüfung auf. Schätzen Sie Verarbeitungs- und Speicherkosten für eine Stichprobe, begrenzen Sie Backfill-Parallelität und -Wiederholungen und prüfen Sie regionale Datenflüsse, Aufbewahrung und Compliance-Anforderungen, bevor Sie die vollständige Migration autorisieren. Dieser Leitfaden stellt weder regulatorische Konformität noch eine Konfiguration für regionales Routing her.

Bestehende Filestack-URLs importieren

Die CDN-URLs⁠ von Filestack identifizieren Dateien anhand eines Handles. Wählen Sie die autorisierte Original-URL ohne Transformations-Tasks aus und stellen Sie bei Bedarf eine gültige Leserichtlinie/Signatur bereit, falls die Quellsicherheit dies erfordert. Wählen Sie eine Ablaufzeit, die lang genug für den eingereihten Download ist, und halten Sie signierte Quell-URLs aus Protokollen und öffentlichen Manifesten heraus. Wenn sie zu einer herunterladbaren HTTPS-URL aufgelöst wird, migrieren Sie sie mit 🤖/http/import:

{
  "steps": {
    "imported": {
      "robot": "/http/import",
      "url": "${fields.filestack_url}"
    },
    "preview": {
      "use": "imported",
      "robot": "/file/preview",
      "result": true
    },
    "exported": {
      "use": ["imported", "preview"],
      "robot": "/s3/store",
      "credentials": "YOUR_AWS_CREDENTIALS",
      "path": "filestack-backfill/${unique_prefix}/${file.url_name}",
      "acl": "bucket-default"
    }
  }
}

Wählen Sie autorisierte filestack_url-Werte aus dem Asset-Inventar Ihres Backends. /file/preview befindet sich in der Beta-Phase und greift auf ein generisches Dateityp-Symbol zurück, wenn kein Inhalts-Thumbnail erzeugt werden kann. Führen Sie begrenzte Backfill-Jobs aus; /http/import akzeptiert auch ein Array von URLs. Bewahren Sie Quell-Handles und -URLs auf, bis Zugriff und Qualität des abgeschlossenen Exports überprüft sind. Private S3-Objekte benötigen einen autorisierten Download oder Ihr konfiguriertes CDN. Das Import-Template gibt exportierte Dateien unter results.imported und results.preview zurück.

Ersetzen Sie Auslieferungs-URLs erst nach der Überprüfung. Bewahren Sie eine Zuordnung von jedem alten Handle plus Transformationsrezept zu seiner neuen exportierten URL auf. Überprüfen Sie Original-Prüfsummen, das Erscheinungsbild der Derivate, MIME-Typen sowie autorisierten/öffentlichen Zugriff, bevor Sie Datenbankeinträge, gerenderten Markup, CSS, CMS-Inhalte und API-Antworten aktualisieren. Erzeugen Sie benötigte Derivate neu, anstatt Filestack-Tasks an den neuen CDN-Hostnamen anzuhängen. Bewahren Sie alte Datensätze und einen Lesepfad-Umschalter für ein Rollback, während neue Uploads den neuen Pfad verwenden.

Sie können von einer Domain, die Sie kontrollieren, bereitgestellte URLs umleiten. Wenn Sie den benutzerdefinierten CNAME⁠ von Filestack verwenden, ersetzen Sie dessen Ursprung erst, nachdem Ihre Auslieferungsschicht alte Handle-/Task-Pfade auflösen und die beabsichtigten Zugriffsregeln durchsetzen kann. Sie können Ihre Weiterleitungen nicht auf der gemeinsam genutzten Domain cdn.filestackcontent.com von Filestack installieren: ersetzen Sie diese Links in Inhalten, die Sie kontrollieren, und planen Sie fortgesetzten Quellzugriff für Verweise, die Sie nicht aktualisieren können. Testen Sie Cache-Verhalten und Zugriffskontrollen, bevor Sie Weiterleitungen dauerhaft einrichten.

Checkliste

Planungsschätzung. Für einen Picker, ein zugängliches Asset-Inventar, einige Vorschau-Rezepte und einen Bucket, den Sie kontrollieren, kalkulieren Sie mehrere Entwicklertage für einen getesteten Pilotbetrieb ein. Ein großer Backfill, Kompatibilität mit benutzerdefinierten Domains, private Auslieferung, Dokument-Viewer sowie anwendungsseitig geführte Katalog-/Versionsexporte können Wochen oder länger dauern. Dies sind Planungsschätzungen, keine gemessenen Migrations-Benchmarks; messen Sie die Zeit für einen repräsentativen Stapel und berücksichtigen Sie Übertragungslimits, Verarbeitungskosten, Validierung und Rollback.

1. Erfassen Sie Handles, Speicherpfade, Tags/Beschreibungen, Versionen, Picker-Callbacks, Sicherheitsregeln, Transformationsrezepte, Workflow-Tasks und die Nutzung von Agent-Tools. Klären Sie jede ausgeschlossene Funktion vor der Umstellung.
2. Wählen Sie Ziel-Objektschlüssel, Katalogspeicherung, Download-Autorisierung, CDN und die Strategie für alte URLs. Konfigurieren Sie Zugangsdaten von Drittanbietern mit dem benötigten Zugriff.
3. Erstellen und überprüfen Sie Templates mit repräsentativen Bildern, PDFs, nicht unterstützten Dateien und Fehlerfällen. Fügen Sie bei Bedarf ein Scan-/Quarantäne-Gate hinzu.
4. Ersetzen Sie Picker und Webhook-Empfänger in einem Pilotbetrieb. Überprüfen Sie die Abschlussbehandlung, Signaturprüfungen, Wiederholungsversuche, Idempotenz und den privaten Download-Zugriff.
5. Führen Sie einen begrenzten Backfill durch; protokollieren Sie abgeschlossene Exporte und gleichen Sie Teilversuche ab. Vergleichen Sie Original-Prüfsummen und Derivatqualität, bevor Sie den Lesepfad eines Assets umschalten.
6. Stellen Sie neue Uploads um, gleichen Sie das endgültige Quelldelta ab und migrieren Sie dann Lesevorgänge in Kohorten. Überwachen Sie Fehler, Kosten und den Verkehr auf alten URLs; bewahren Sie einen Rollback-Pfad und den Quellzugriff bis zur Freigabe auf.