Dateisystem (Operationen) abstrahieren
Aktuell verwendet QUIQQER direkt das lokale Dateisystem und greift darauf via nativen PHP Methoden wie bspw. file_get_contents, mkdir, etc. zu.
Das bringt Nachteile bei der Austauschparkeit, Portierbarkeit, Testbarkeit und Sicherheit/Stabilität.
Es ist beispielsweise nicht möglich ein Windows Dateisystem zu verwenden (evtl. gilt das sogar für andere Linux Dateisysteme).
Ebenfalls müssen die Ordner des QUIQQER Systems immer lokal vorhanden sein. Es ist beispielsweise nicht möglich bspw. Mediendateien in einen S3Bucket zu schreiben oder die Config-Dateien direkt aus dem RAM (InMemory) zu lesen.
Bei der Verwendung der nativen PHP Funktionen wie bspw. file_get_contents oder mkdir gibt es einige Fallstricke, die vom Entwickler beachtet werden müssen. So sind die Rückgabewerte bspw. inkonsistent, es gibt nur umständliches Fehlerhandling oder es werden nur lokale Dateien unterstützt.
Der (für mich) wichtigste Punkt ist aber die komplizierte Testbartkeit. Im aktuellen Zustand müssen alle Dateisystem Operationen immer auf das lokale Dateisystem ausgeführt werden. So ist es drastisch schwieriger voneinander unabhängige Tests zu schreiben. Das ist beispielsweise der Fall, wenn ein Test prüfen soll, ob eine Datei geschrieben wurde. Der Test muss sicherstellen, dass keine Dateien überschrieben und die Änderungen nach dem Test rückgängig gemacht werden.
Eine Lösung für diese "Probleme"/Nachteile ist eine abstrakte Filesystem-Bibliothek wie bspw. league/flysystem.
Mit einer solchen Library wird das Dateisystem und die Operationen darauf durch eine simple, konsistente und getestete API abstrahiert.
Dem Entwickler kann das darunter liegende Speichersystem egal sein, da er nur die API verwendet und die Library die entsprechenden Operationen korrekt ausführt.
Das hat die folgenden Vorteile:
- Einheitliche API für alle Speichersysteme: Statt mehrere unterschiedliche APIs (z. B. für lokale Files, S3, FTP, etc.) zu lernen und zu verwalten, gibt es eine standardisierte Schnittstelle
- Austauschbarer Speicherort: Durch die einheitliche API kann der Speicherort einfach gewechselt werden (z. B. von lokal zu S3), ohne den Code anpassen zu müssen – ideal für Deployments, die später skalieren sollen.
- Besseres Fehlerhandling und sauberer Code: Statt direkter
file_put_contents,mkdiretc. Aufrufe bietet die API saubere Objektorientierung und konsistentes Fehlerhandling. Das macht den Code wartbarer und weniger fehleranfällig. - Bessere Testbarkeit: Durch die Abstraktion kann das Filesystem beim Testen einfach gemockt werden, was das Testing drastisch vereinfacht.
Bei Bedarf führe ich die genannten Vorteile gerne noch weiter aus.
tl;dr
Das Dateisystem und die Operationen darauf (bspw. file_get_contents, mkdir, etc.) sollten durch eine abstrakte Filesystem-Bibliothek wie bspw. league/flysystem abstrahiert werden.
Das bringt die folgenden Vorteile:
- Testbarkeit
- Unabhängigkeit vom Speichersystem
- Höhere Stabilität durch besseres Fehlerhandling und getestete Funktionalität