Django einfache Thumbnails vs Sorl-Thumbnail Unterschiede

Ich habe über verschiedene Thumbnail-Apps für Django gelesen und sie ausprobiert. Dies sind die Anforderungen:

• Alle generierten Miniaturansichten müssen getrennt von den ursprünglichen Bildern in einem S3-Bucket gespeichert werden, d. h. separate Speicherklasse

• Wenn die Bildinstanz gelöscht wird, muss die ursprüngliche Bilddatei zusammen mit allen generierten Miniaturbildern ebenfalls gelöscht werden

• Minimieren Sie teure Ineffizienzen, z. Das Abrufen der URL eines Miniaturbildes, das in DRF serialisiert werden soll, sollte nicht im S3-Bucket aussehen, um zu sehen, ob es jedes Mal existiert, usw.

VersatileImageField schlägt die erste Anforderung fehl. ImageKit erfüllt die zweite Anforderung nicht. Die dritte Voraussetzung ist, wo ich am meisten verwirrt bin; Ich versuche mich über Best Practices zu informieren, aber die Informationen sind fragmentiert und ich bin nicht zuversichtlich, eine Entscheidung zu treffen, die auf dem basiert, was ich bisher gelernt habe.

Nach dem, was ich gelesen habe, ist mein Eindruck, dass das effizienteste Verhalten wie folgt aussehen würde:

• Erzeugen Sie das Vorschaubild unmittelbar nach dem Speichern und nehmen Sie an, dass es immer existiert
• Um auf das Thumbnail zuzugreifen, generieren Sie die URL basierend auf dem Dateinamen des ursprünglichen Bildes und der Thumbnail-Dimensionen / Qualität, da wir wissen, dass es definitiv existiert
• post_delete löscht alle Vorschaubilder und die Originaldatei

Ich würde am meisten daran interessiert sein, etwas über die Unterschiede in den Ansätzen zu lernen, die einfache thumbnails und sorl-thumbnail brauchen (wenn sie mit dem oben kurz beschriebenen Prozess übereinstimmen oder wenn sie etwas effizienteres haben) und die Vorteile / Nachteile in jeder ihrer Methoden.