Wenn man einen Playground-Shop erstellt, dann wird eine Instanz “des Muttersystems” erstellt. Wie muss ich mir das technisch Vorstellen? Sind das VM’s? Wie skaliertbar ist das? z.b. 100xShop-Instanzen,auf 1 Server geht doch irgendwann in die Knie? Jeder Shop wird doch eine eigene DB erhalten (oder teilen die sich eine?), wie kann man Plugins bauen und auf DB zugreifen und dann sicher sein, dass die bei einem Update nicht flöten gehen? Versteht man meine Frage? Wenn es sowas wie eine Symbol-Landkarte gibt, wäre schön.
Danke und Gruss
EDIT: als nachtrag. Wenn der Shopbesitzer sagt, ich bin mit meiner Instanz zufrieden, es aber auch ein Update gibt, wie frei ist das? Habe irgendwie so ein gefühl man ist richtig abhängig. Gibt ja gutes und schlechtes daran.
wenn du auf den Knopf „Neue Instanz erstellen“ klickst, wird im Hintergrund eine Datenbank erstellt, welche ausschließlich dir gehört.
Das ganze System basiert nicht auf VMs, stattdessen werden die Amazon Web Services benutzt. Deine Playground Instanz läuft auch nicht auf einem Server, sondern in einem Cluster von ganz vielen Servern wo jeder Server für jede Instanz zuständig ist.
Sollte nun eine Instanz viel Last verursachen wird die Last auf mehrere Server aufgeteilt und ggf. werden neue Server hochgefahren.
Zum zweiten Teil deiner Frage: Plugins die den Playground selbst erweitern kann man bisher gar nicht entwickeln. Stattdessen kannst du über die API schon vieles kontrollieren und vor allem ausprobieren.
Ausprobieren ist hier auch das richtige Stichwort, denn der Playground ist ja kein vollwertiges Shopsystem, sondern eine Spielwiese um Feedback zu unseren neuen Technologien geben zu können.
Bei deiner letzten Frage bin ich mir etwas unsicher, ob ich sie richtig verstehe. Aktuell kann ein Benutzer des Playgrounds nicht steuern, ob er Updates erhält oder nicht. Sobald wir coole neue Änderungen haben spielen wir das Update automatisch für alle Benutzer ein. Der Vorteil: Wenn etwas schiefgeht sehen wir das sofort und können es direkt reparieren.
@Jens_K Habt Ihr aktuell denn schon einen ungefähren Ansatz, wie hier die Backend Entwicklung aussehen wird bzw. wie man eben das Backend um Funktionalitäten erweitern kann? Oder gitbt es da aktuell noch keine konkreten Pläne für?
@Shopwareianer einen Ansatz, wie Backend-Plugins im Playground aussehen werden, haben wir. Konkrete Pläne bzw. eine begonnene Umsetzung bisher nicht. Das liegt vor allem daran, dass es zuerst einen zumindest fast vollständigen Architektur-Freeze geben sollte, bevor unsere Ideen und Pläne zu Plugins der (Code-)Realität begegnen können.
Unabhängig vom Playground, bei dem ja alles ein wenig anders ist weil Cloud und so, planen wir, dass das Plugin-System der platform ähnlich funktionieren wird wie bisher in Shopware auch. Wenn es nach mir geht bedeutet “ähnlich” hier vor allem, dass Hooks Geschichte sind. Mal sehen.
@Shopwareianer einen Ansatz, wie Backend-Plugins im Playground aussehen werden, haben wir. Konkrete Pläne bzw. eine begonnene Umsetzung bisher nicht. Das liegt vor allem daran, dass es zuerst einen zumindest fast vollständigen Architektur-Freeze geben sollte, bevor unsere Ideen und Pläne zu Plugins der (Code-)Realität begegnen können.
Unabhängig vom Playground, bei dem ja alles ein wenig anders ist weil Cloud und so, planen wir, dass das Plugin-System der platform ähnlich funktionieren wird wie bisher in Shopware auch. Wenn es nach mir geht bedeutet „ähnlich“ hier vor allem, dass Hooks Geschichte sind. Mal sehen.
Da bin ich mal gespannt.
Das ganze ist zwar nicht wirklich das gleiche, aber schau dir mal Laravel Novaan in der Doku. Das Nova Backend basiert ja auch auf Vue.js
Du legst dir dann über die Console bspw. ein neues Tool an ( Backend Menü Eintrag + Views ) und kannst darauf aufbauen dein individuelles „Plugin“ im Backend bauen. Das ganze ist „relativ simpel“ über PHP Klassen umgesetzt. Datenbank Abfragen machst du dann ganz normal über deine Models usw.
Der Command legt für dich dann die Grundstruktur an, um es im Backend anzuzeigen und den Rest kannst du dann darauf aufbauen individuell umsetzen.
Danke für den Hinweis, das Laravel-Wissen ist bei uns eher sparsam gesät. Ich werde es mir zu Gemüte führen und ein, zwei Kollegen dazu nötigen dasselbe zu tun.
Danke für den Hinweis, das Laravel-Wissen ist bei uns eher sparsam gesät. Ich werde es mir zu Gemüte führen und ein, zwei Kollegen dazu nötigen dasselbe zu tun.
Gibts ja gar net
Macht das mal ^^
Nova ist ja noch nicht sehr alt, erst ein oder zwei Monate. Die Umsetzung finde ich aber wirklich sehr gelungen.
1.) Frontend: Wird es zu der “Instanz” die man erstellen kann auch einen kleiner Frontendspeicher geben? Oder muss man sich darum selbst kümmern und sozusagen immer extern und Instanzunabhängig sich ums Hosting kümmern? Wie sieht hier Shopwares Wunschsetting aus?
2.) Datensicherheit. Ich habe schon ein “paar” mal Backups einspielen müssen nach Missglückten Plugin- oder Shopupdates. Wie kann man seine “Instanz” sichern. z.B. Tages/Wochenbackup um mich nicht auf SW (sorry) verlassen zu müssen wenn “hinter dem Rücken” ein Update gefahren wird?
3.) Preise: Dass die Nutzung des API/Cores/keine Ahnung wie man das nennt. gratis ist, wurde ja schon von dem älteren Hamann auf der Keynote gesagt. Was sind die Datenlimitierungen bis es kostenpflichtig wird? Und gibt es schon jetzt neue Subscription-Modell (bitte überlegt diesen Begriff nochmal :-D) . Ich meine AWS und eure Arbeit zahlt sich ja nicht von allein?
Ich frag mich grad, ob ich als einfacher kleiner Shopbetreiber für Shopware “NextGen” doch noch ein Fernstudium Informatik absolvieren muss.
Kann mir grad auch nicht wirklich vorstellen, dass der “API”-Ansatz und das Cloudgedöns wirklich performant ist - sind mir einfach zu viele “Schichten” involviert.
“Playground” klingt für mich: Muss man sich leisten können - der einfache kleine Shopbetreiber wirt wohl ohne Agenturen und/oder fette Firmen-IT mit Shopware überfordert werden.
Naja - hab ja “Playground-Zugang” - vielleicht werde ich da irgendwann ja doch noch schlau raus
@sonic Warum sollte eine Cloudlösung nicht perfomant sein? Gerade Cloudlösungen sind richtig umgesetzt perfomanter als ein einzelner Server, oder eine VM.
Kleines Beispiel: Plentymarkets setzt ja mittlerweile auch auf AWS, nachdem denen ja die ganze Server Infrastruktur abgeraucht ist und alle Kunden offline waren.
Ein anderes Beispiel ist hier bspw. auch wieder Shopify, die setzen es ja genauso um. Und jedes größere Unternehmen mit High-Traffic setzt mittlerweile verständlicherweise auf solche Cloudlösungen wie AWS & Co. da eine solche Lösung unendlich skalierbar ist und sich dem Traffic automatisch anpasst.
Mit einem einzelnen Server bspw. nicht direkt möglich. Wenn bspw. eine hohe Last verursacht wird durch bspw. TV-Werbung oder ähnl. erkennt das System das und schaltet ggf. weitere Instanzen zu, sodass die Last auf weitere Server verteilt wird.
Das konnte man auch bspw. bei „Höhle der Löwen“ sehr gut beobachten. Anfangs waren die Shops darauf gar nicht vorbereitet auf diesen Traffic und viele Shops waren während der Sendung nicht erreichbar aufgrund des Traffics. Mit der Zeit haben die ganzen Pitcher das Problem erkannt und hier ebenfalls auf solche skalierbaren Cloudlösungen gesetzt, weil sich die Leistung eben dem Traffic anpasst. Ende vom Lied: Shop durchgängig erreichbar auch bei tausenden gleichzeitigen Nutzern, welche auf die Seite zugreifen.
Und warum sollte der einfache Shopbetreiber überfordert werden? Je nachdem wie es umgesetzt ist, verringert man doch den Aufwand. Hier kann man auch wider Shopify als Beispiel nehmen. Da kannst du dich auf deinen Shop konzentrieren, ohne dir Gedanken zu machen um Updates, Hosting oder sonst was.
Dann kann ich auch gleich zu Shopify oder versaCommerce gehen.
Nicht jeder ist so tief in der Materie drinne, dass er noch voll bei Cloud & Co. druchsteigt.
Ich rede von „kleinen“ Shopbetreibern. Die haben halt mitunter auch nicht die Kohle, das ganze in der „Cloud“ managen zu lassen und oder zu „mieten“. Ggf. soll es auch noch Menschen geben, die sich nicht gerne unnötig von „Anderen“ abhängig machen. Ich brauch mich auch nicht auf den „Shop“ konzentrieren, weil ich für alles rund um Verkauf/Marketing gar nicht bezahlt werde. Wenn mir heute mein Hoster auf den Zeiger geht, zippe ich meinen Shop zusamen und mache einen Datenbank-Dump - ratz fatz bin ich wieder woanders, da kann AZUR noch so prüde sein. Wenn ich daran denke, dass GoogleMerchant bei Produktbilder „nackte Haut“ moniert, nur weil der Karton des Raumduftes einen passenden Farbton hat, weiß ich schon, warum ich nicht großen Wert auf eine von den Amis dominierte Klaut-Welt lege.
Mit Performant meine ich: Browser/APP vom Kunde fragt mein „Frontend“ auf Server A an. Frontend-Server A macht nen aufgeblähten API-Call auf Server B - irgwendwo anders in der Cloud/Netz/anderer Clouddienst. B Antwortet A wieder mit einen aufgeblähten Datenpaket. Server A muss das wieder für das Frontend aufbereiten - und schickt das wieder zum Client zurück. „Performant“ bedeutet, sparsam mit Resourcen auskommen. Das die Cloud dann volles Rohr Rechenleistung für eine Problemlösung bereitstellt, macht das Program als solches nicht performant.
Ich hab halt kein Bock auf Cloud, weil ich mich damit aber auch einfach nicht mehr auseinader setzen will, können sich jüngere mir beschäftigen.
Und wenn es nicht ohne geht - muss halt eine andere Lösung her.
Naja - wenn ich noch Lust verspüre und es notwendig wird, setze ich mich vielleicht ja doch noch damit auseinander.
Will da auch gar nicht über (Un-)Sinn etc. diskutieren. Ist glaube nur nicht, dass sich der kleine Shopbetreiber so einen Shop finanziell wird leisten können.
@sonic Ne, Shopify oder Plentymarkets war jetzt nur das Beispiel mit der Cloud. Letztendlich hast du als Endnutzer damit ja nichts am Hut. Das meinte ich damit.
Shopware hatte ja aber auch gesagt, dass diese Cloud optional ist. Entweder kannst du die Infrastruktur von Shopware nutzen, oder weiterhin deinen eignen Hosting Anbieter. Soweit ich es im Kopf hab musst du darauf also gar nicht setzen. Kannst aber bei Bedarf auch ohne Probleme auf die Shopware Infrastruktur migrieren.
Bzgl. der Cloud: Ja das verstehst du wohl alles ein wenig falsch. Aber das ganze Cloud Thema hier auseinander zu nehmen würde wohl auch alles sprengen
Bzgl. des API Calls: Ein API Call verbraucht prinzipiell nichts an Leistung, da macht es dann die Masse. Und der schickt das auch nicht an Server A dann wieder nach B oder derglichen. Dafür hast du in der Regel einen Loadbalancer dafür, dieser verteilt praktisch die Anfragen auf die einzelnen Instanzen. Da wird nichts hin und her gesendet.
Da du hier auch von einer APP sprichst: Prinzipiell hat so gut wie jede einzelne APP eine API Anbindung. Oder jede Warenwirtschaft zu Amazon, eBay oder oder oder.
Eine API ist ja prinzipiell auch nur ein Endpunkt auf den du zugreifen kannst. Im Hintergrund passiert pinrzipiell genau das gleiche als wenn du keine API hättest.
Das Problem ist eher, dass hier der Begriff „API“ überwiegend „falsch“ und reduziert verendet wird - reduziert auf „Webschnittstellen“ (Siehe Beispiel Amazon, ebay oder oder oder) Für mich setzen APIs eigentlich viel weiter unten an - API steht ja nicht ohne Grund für „Application Programming Interface“ die obigen Beispiele dienen nur dem „Datenaustausch“, sind aber keine echte „API“-Zugriffe (naja - die Bedeutungen technischer Begriffe sind in den letzen Jahren eher plattgeschilffen worden).
Bei SW ist für mich „API“ immer gleich eine Form der „REST-API“ - dürfte wohl mein Denkfehler in Sachen Playground sein.
„API“ kann aber auch schlicht eine Funktionssammlung sein, die mir einen einheitlichen Zugriff - eine Schnittstelle - auf den „Core“ erlaubt.
Aber letztlich war ja auch schon die MFC ein Ansammlung von API-Zugriffen für win32 *lol*
So gesehen sind auch sArticle und sBasket schon APIs
Wie gesagt: Müsste ich mich mit auseinander setzen, also erst ein Informatik-Studium nachholen
Denke nur, dass „Playground“ in der bisherigen Form mit den spärlichen Informationen derzeit nicht nur bei mir für viele ??? sorgt.
Eine API ist ist ja letztendlich nichts anderes als eine Schnittstelle zum Datenaustausch, richtig.
Und wenn das Shopware Backend komplett auf einer API basiert, dann kommunizert das Frontend bspw. eben über diese API/Schnittstelle zum Backend.
Mit dem Vorteil, dass ich aber mit dem API-first Ansatz eben unabhängig vom Frontend jede Aktion darüber steuern kann. Was aktuell nicht der Fall ist.
Aktuell kann ich ja bspw. im Frontend nur auf die verfügbaren Variablen zugreifen in Smarty welche mir zur Verfügung gestellt werden.
Ich könnte hier also bspw. “problemlos” eine APP entwickeln, welche eben über die API auf die Funktionen im Shop/Backend zugreift samt User Login usw. Das hat schon seine Vorteile. Für dich als Nutzer wird sich da aber nicht viel ändern denke ich.
Oder ein anderes Beispiel: Komplexere Konfiguratoren für Produkte. Der Konfigurator kann damit völlig unabhängig von Shopware sein, da man eben mit der neuen API alles abdecken kannn - So kannst du dann auch ohne größere Probleme über die API einen konfigurierten Artikel über einen externen Konfigurator in den Warenkorb legen. Oder oder oder oder eben.
Eine komplette API macht das ganze System einfach unabhängiger und mächtiger, da man eben jegliche Aktionen über die API steuern kann. Naja, ich bin auf jeden Fall gespannt, in welche Richtung das ganze geht
An dieser Stelle sei nochmal angemerkt: Der Playground ist kein Produkt. Er ist genau das, was die Übersetzung vermuten lässt: Eine Spielwiese, die dazu dient Feedback zu sammeln bzw. für euch, sich frühzeitig mit neuer Technologie auseinandersetzen zu können.
Ich kann Dir versichern @sonic, dass ein Informatikstudium nicht notwendig ist um eine REST-API zu bedienen. Die von Playground mit eingeschlossen.
Du hast natürlich trotzdem Recht damit, dass API in dem Zusammenhang als Verkürzung genutzt wird, was ihn aber nicht weniger richtig macht.
Also wie jetzt? Der Playground ist eine Spielwiese, wo ich mir sozusagen eine Art Webshop in der Cloud zusammenschrauben kann, um einfach Dinge zu lernen!?
@Murmeltier Der Playground ist eine Spielweise, wo du dir anschauen kannst, wie zum Beispiel eine neue Administration aussehen könnte, oder wie ein per API gesteuerter Warenkorb funktionieren könnte. Zu all diesen Themen kannst du dann Feedback geben, welches in der weiteren Entwicklung berücksichtigt wird.
Mit dem Playground einen produktiven Webshop in der Cloud zusammenzubauen wird aktuell schwierig, es gibt keine Storefront und keine Zahlungsschnittstelle, welche außerhalb des Sandbox Modus funktioniert etc.
Wenn es sowas wie eine Symbol-Landkarte gibt, wäre schön.
Dankeschön
Ich werde es mir zu Gemüte führen und ein, zwei Kollegen dazu nötigen dasselbe zu tun.
Wenn mir heute mein Hoster auf den Zeiger geht, zippe ich meinen Shop zusamen und mache einen Datenbank-Dump - ratz fatz bin ich wieder woanders, da kann AZUR noch so prüde sein. Wenn ich daran denke, dass GoogleMerchant bei Produktbilder „nackte Haut“ moniert, nur weil der Karton des Raumduftes einen passenden Farbton hat, weiß ich schon, warum ich nicht großen Wert auf eine von den Amis dominierte Klaut-Welt lege.
