Das Grundziel ist und sollte aus meiner Sicht bleiben ein Monolith bereitzustellen um ehemaligen CE Nutzer * innen eine kostenlose Alternative bereit zu stellen.
Ein Monolith wird nie ein Themenbereich in der Tiefe abdecken können und es wird je nach Priorität des einzelnen Händler * in erforderlich machen sich seinen Online-Shop in den Themenbereichen erweitern zu lassen.
Der USP von O3 Shop könnte, wie bereits von den Machern im Hintergrund von O3 angedeutet, darin liegen die Community wieder mehr in den Mittelpunkt zu stellen und die Zusammenarbeit mehr zu fördern.
Die Philosophie kein kommerzielles Konkurrenz Produkt in Form einer höheren Lizenzform anzubieten kommt dem entgegen. So bietet O3 Shop Agenturen, Händler * innen und Programmierer * innen genügend Freiraum um kleine bis große Projekte damit umsetzen - eine gemeinsame Basis.
Um den “kleinen” Händler mit geringerem Budget bedienen zu können, benötigt man den Monolith - ein Monolith schließt aber nicht grundsätzlich headless und co aus.
Auch muss man nicht jedes Shopprojekt mit einer PWA erschlagen, da muss man auch einmal die kirche im Dorf lassen.
Der Schlüssel für einen neuen Admin, PIM/ERP Anbindungen ist hier immer eine performante rest api welche absolut die höchste Priorität hat - damit kannst du einen Monolith auch 100% aus dem ERP/PIM/MDM verwalten, im täglichen Betrieb gibt es hier keinen Grund den Shop-Admin zu verwenden, bei vernünftiger Anbindung.
Um O3 im Grundsatz von einem Monolithen in eine wirklich moderne API First Plattform zu wandeln, gäbe es meiner Meinung nur einen weg, einen rewrite from Scratch.
Ich glaub, wir reden hier in unterschiedlicher Bedeutung von “Monolith”
Für mich ist ein Monolith eine Software, die im Inneren “aus einem Stück” besteht. Heisst konkret im O3-Shopumfeld (überzogen ausgedrückt): Um nur ein einziges Smiley im Browser auszugeben, muss man das gesamte Framework hochfahren. Mit dem entsprechenden Overhead und der Zeit, die das kostet.
Wenn man im Inneren sauber und geschickt modularisiert, in Komponenten teilt und die Komponenten geschickt miteinander kommunizieren lässt, kann man dasselbe Smiley ausgeben, indem man nur die Komponenten hochfährt, die dafür gebraucht werden.
Und das kann dann sackschnell werden - was sich auf die Time-To-First-Byte auswirkt und damit auf die Conversion Rate. Alleine dafür schon muss die Software schnell sein.
Gleichzeitig bin ich dafür, das Ganze “an einem Stück” auszuliefern. Der Auslieferungszustand hat nix mit der inneren Architektur zu tun.
Am Ende wird das, da geb ich @o3shop recht, auf einen kompletten Rewrite rauslaufen.
Und ich denke, dass es möglich ist das ganze Peu-à-Peu zu machen.
Mit “FTP” entpackst du das Archiv gleich wo du willst; öffnest das “Setup” und Gut ist.
Nun ist es gefühlt ein Mehraufwand und irgendwas klemmt mit Composer immer.
Es ging und geht auch ohne Composer. Das ist ein “Entwicklerspielzeug”.
Shopbetreiber haben oftmals keine Zeit oder Interesse.
Sorry, das ist aber ein Schmarren. Moderne Projekte setzen Composer ein.
Ob dieser für die Installation unbedingt sichtbar sein muss ist eine andere Frage. Wir haben keine Investoren im Rücken. Alles zu seiner Zeit.
Ich nehme mal deine Worte: Sorry, das ist aber ein Schmarren.
Nicht alles “Modernes” ist für uns ein Fortschritt.
Wir brauchen dabei nicht mal soweit nach hinten blicken.
Und bieten auch Archive an. Nicht nur um die alten Hasen nicht zu verschrecken.
