brettvormkopp
MemberComments: 1764
Received thanks: 350
Member since: March 2013
edited November 2018
Moin, ich habe eine Frage zu Playground.
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.
Comments
Bzgl. des Hostings: Schau mal hier -> https://de.shopware.com/unternehmen/forschung/neuer-core/
bzw. die Keynote.
Moin brettvormkopp,
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 Aaah super, alle Frage beantwortet :-P Dankeschön
@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.
Da bin ich mal gespannt.
Das ganze ist zwar nicht wirklich das gleiche, aber schau dir mal Laravel Nova an 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.
Wäre evtl. ein Ansatz bzgl. des Vue.js Backends.
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 :P
Macht das mal ^^
Nova ist ja noch nicht sehr alt, erst ein oder zwei Monate. Die Umsetzung finde ich aber wirklich sehr gelungen.
Es gibt dazu auch eine kleine Video Serie auf Laracasts, was das ganze vielleicht schneller etwas näher bringt -> https://laracasts.com/series/laravel-nova-mastery
Oder die Keynote von Taylor ->
Vielleicht ist es ja ein guter Ansatz für die Backend Plugin Umsetzung oder dergleichen.
Und da klinkte ich mich nochmal ein und habe eine Frage zum Frontend und Datensicherheit und Preise. @Jens_K @ndzoesch @Stephan Pohl @Moritz Naczenski
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.
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.
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.
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.
Könnte jemand bitte meine Zwischenfrage noch mal anschauen? Danke euch @Jens_K @Moritz Naczenski https://forum.shopware.com/discussion/comment/235918/#Comment_235918
@brettvormkopp Die Frage wurde ja beantwortet. Es ist aktuell eine Spielwiese, nichts wieter. Es ist kein finales Produkt. Daher erübrigen sich deine Fragen eigentich.
Ich weiß auch gar nicht, warum Ihr alle so mega viele vom Playground abweichenden Fragen stellt? Wartet doch einfach ab? ... Shopware wird das schon zu gegebener Zeit kommunizieren, wenn die selbst wissen was Sache ist und es vom Zeitpunkt her passt? ... Aktuell werden einfach Ideen gesammeln, mehr nicht. Konzentriert euch doch einfach mal darauf anstatt irgendwelche Zukunfts Frage zu stellen, worüber evtl. noch gar nicht diskutiert wurde, weil es einfach noch viel zu früh ist ...
Naaaja, also dass es eine Spielwiese ist, das können die ja gerne behaupten, muss aber nicht stimmen, und meine Menschenkenntnis sagt, es stimmt nicht. Kommunikation ist ja nicht SW's Ding, ausser dass sie Brandlöscher wie Moritz hier reinschicken und dann ist erstmal wieder alles gut.
Ein Blick in Google Trends verrät jedem, dass Shopwares Aufstieg seit Anfang 2017 stagnierte und nun einen absteigenden Trend vorweist. Siehe: https://trends.google.de/trends/explore?date=all&geo=DE&q=shopware Schaut man sich im Forum um, dann sind hier nur noch eine handvoll Profis, die helfen. In der Summe habe ich das Gefühl, dass mehr Fragen gestellt werden, aber auch, dass weniger Profis dabei sind und ein ziemlich hohes Stresslevel mitschwingt.
Ich ziehe daraus den Schluss, dass etwas "revolutionäres" passieren muss. Dieser "Playground" (SWP) wäre es ja. Wie schon in einem anderer Forumsbeitrag geschrieben lässt sich zwar darüber streiten was hieran revolutionär ist wenn das andere Firmen schon haben, jedoch muss sich jede Firma neu erfinden. Was sollte es also sonst sein? Und etwas muss passieren sonst wandern die Leute ab, wenn an der Standart-Software so wenig passiert bei relativ vielen Mitarbeitern.
Für ein paar meiner Kunden ist SWP interessant. Nicht für alle. z.b. für mich persönlich und meine betreuten absoluten Superumsatz-Shops ist es nicht brauchbar. Ich könnte die anderen aber schon jetzt in Shopify unterbringen. Und erst die Öffnung SWP hat auch mir dazu die Augen geöffnet wie ich so star sein konnte und soviel Energie in SW zu stecken. Wie gesagt könnte ich mit einem Fingerschnipp zu Shopify, aber ich will auch nicht sofort zu einem US? Konzern rennen nur weil da mal kurz die Kirschen besonders süss sind. Wirtschaftlich betrachtet kann SWP für mich bedeuten, dass ich aus dem Shopware Universum aussteige oder voll dabei bleibe. Das hängt auch mit der Informationspolitik ab. Den gleichen "Höllenritt" wie SW4 und 5 tu ich mir kein zweites mal an.
Das ist auch in sofern interessant, weil so f*cking viele Firmen einen Shopwareheini suchen, einen der "alten" Software. Was ist denn mit den Menschen die sich für so eine Stelle bewerben und nach 2 Jahren heisst es: "Du kannst gehen. Mit SWP bist du überflüssig geworden."
Deshalb halte ich meine Fragen auch für legitim, und es wäre schön, wenn man ein paar Frontendinfos abgreifen kann. Ich bin mir auch sicher, dass es darauf Antworten gibt. SW Mitarbeiter haben schon oft ein paar hilfreiche Insider rausgegeben die sich immer bewahrheitet haben.
@Shopwareianer
@brettvormkopp Naja, stagnieren würde ich mal nicht sagen. Man muss ja so fair sein und das auch im Kontext zu anderen Systemen sehen.
Wenn du dir mal die Konkurrenz anschaust, dann sieht das schon anders aus:
https://trends.google.de/trends/explore?date=all&geo=DE&q=shopware,Magento,Shopify,Prestashop,JTL
Höllentritt von 4 auf 5? Was macht Ihr denn da immer ...
Naja gut - Wenn man für jeden Mumpitz nen Plugin hat und dann hinterher da irgendwie 50 Plugins nutzt usw. kann das natürlich schonmal hässlig werden. Ich persönlich hatte bei den Shops nie wirklich mega Probleme - Wenn diese sauber umgesetzt waren.
Und nach Shopify? Würde ich persönlich nie machen, wenn ich einen Shop hätte. Denn ja: Da bist du zu 100% von einen dritten abhängig. Bei Shopware, Magento & Co. hast du ja prinzipiell alles in deinem Besitz in Form von Sourcecode & Co. Bei Shopify ... Und ich will gar nicht wissen, wie hart die im Hintergrund die ganzen Daten analysieren
Zumal du bei Shopify nicht so flexibel bist wie bei Shopware, zumindest meiner Meinung nach. Shopware ist im Vergleich zu den anderen Systemen am Markt, wirklich eine Top Software. Ich habe schon mit fast allen gearbeitet. Magento, Shopify, Prestashop, Woocommerce ... Meiner Meinung nach ist kein System so gut wie Shopware. Klar der Backend Kram wi ExtJs & Co ist voll fürn Popo und miserabel und nicht sehr flexibel ... Aber das wird sich ja bald ändern.
Naja - Hat eben alles seine Vor & Nachteile.
Äh ja, dagegen sag ich ja nichts - ausser dass hier und da mein Beitrag nicht richtig gelesen wurde :-P. Aber wo sind die Antworter auf meine Fragen? https://forum.shopware.com/discussion/comment/235918/#Comment_235918 Wäre sehr nett wenn das jemand beantworten könnte.
Das ist für den Playground nicht geplant, zumindest nicht so wie Du es in Deiner Frage formulierst. Sollte der Playground in Zukunft auch mit Frontend daherkommen, was aktuell noch nicht absehbar ist, liegt das Frontend auch im Container in der Cloud.
Aktuell kann man das afaik nicht. Da das Ganze aber auch zum Testen und gegentreten ist, passt das. Der Playground ist in keinem Fall für Produktivdaten.
Der Playground ist und bleibt nach aktueller Planung kostenlos. Wie die Preise später mal in einem SaaS-Produkt aussehen könnten steht bisher in den Sternen. Playground ist auch tatsächlich eine Spielwiese und eben kein Produkt. Du sollst Dich damit auseinandersetzen und mitgestalten können, wie die Zukunft der Software aussieht.
Deine Menschenkenntnis scheint mir ein wenig eingerostet, @brettvormkopp.
Der Playground ist tatsächlich ein Feedbackinstrument und eine Möglichkeit für uns, Erfahrungen mit der Cloud-Technik zu sammeln. Keine Verschwörung an der Stelle. 
Du kannst übrigens auch gern mal beim Livestream vorbeischauen, der nächste ist am 07. Dezember. Ich freue mich da über jede Frage im Chat und greife auch gern nochmal das Thema Playground auf.
Gruß, Niklas
Sorry, wenn ich mich da auch nochmal einklinke, aber als Feedbackinstrument finde ich das doch etws too much. Feedback könntet Ihr auch einfach bekommen, wenn Ihr viele Dinge einfach nur besser kommunizieren würdet! Da muss wohl schon etwas mehr dahinter stecken, sonst würdet Ihr Euch keinen solchen Terz dafür machen. So was entwickelt man ja auch mal nicht in 2 Minuten. @brettvormkopp wird da schon nicht ganz unrecht haben.
Schon der Name "Playground" hört sich - für mich - schon mal verdächtig nach Google Strategie an und der Fakt, dass das Ganze wieder über eine zusätzliche Regisitrierung läuft, deutet darauf hin, das SW auch daraus natürlich auch Daten ziehen kann/will. Ich denke das gehört so oder so mit zum ganzen Shopware Konzept, also dieses Binden an eine Produkt bzw. Firma. Aber klar, alles ganz legitim. Man muss ja nicht mitmachen...
haha, Verschwörerisch meinte ich das nicht @ndzoesch ;-) Es kann ja auch durchaus sein, dass DIESE Instanz nur eine Spielwiese ist. Das lässt sich ja auch nicht abstreiten. Dass SWP jedoch ein Projekt in Produktiveinsatz für die Zukunft ist kann man aber auch nicht abstreiten, oder? Wozu sollte sich sonst jemand die Mühe machen sowas zu bauen ohne Hintergedanken, wie es @Murmeltier anmerkte. Ich denke es folgt hier den ganz klaren Leitlinien für neue Produkte https://de.wikipedia.org/wiki/Push-Pull-Strategie
Unabhängig davon habe ich gestern einem Bekannten vom SWP erzählt. Er meint: Genialer Schachzug von Shopware. Erst mit freier Software locken und dann mit der Mutter-Api abhängig machen. Und nein, ich habe ihm es unvoreingenommen erzählt damit ich seine Meinung höre und nicht das was ich hören will.
Und bitte eines nicht vergessen. Für einige Kunden von mir ist SWP durchaus interessant. Ich hasse die Idee nicht. Ich bin nur Uninformiert. Und das trägt seltsame Blüten.
Eine Potentielle Cloud Lösung schließt ja ein On-Premise Produkt nicht aus. On-Premise ist ja unser Kern Geschäft. Es wäre gelogen, wenn man sagt, dass die Erfahrungen die wir mit Playground sammeln nur eurem Feedback dient, natürlich gibt es das auch um Erfahrungen zu sammeln und natürlich gibt es auch einen Markt für solche Lösungen. Also ist es durchaus denkbar, dass daraus irgendwann ein Produkt entsteht. Aber das ist natürlich nur für eine sehr spitze Zielgruppe relevant.
Der Fokus ist weiterhin ein On-Premise Produkt. Die Funktionen werden sich auch zu großen Teilen überschneiden. Daher ist es erstmal eine Feedbackplattforn für die neue API und Administration. Beides wird es auch irgendwann On-Premise geben + allem das, was Shopware jetzt schon ausmacht.
Wir wollen nur nicht im stillen Kämmerlein entwickeln und euch etwas vorsetzen. So könnt ihr euch kostenlos das ansehen, an dem wir arbeiten.
Das dies keine Ablösung von SW5 ist, bedingt ja schon der Funktionsumfang. Also ja, der Fokus ist weiterhin On-Premise und KMU. Da kommen wir ja auch her.
Lass es mich mit den Worten von Stefan Hamann sagen: https://www.youtube.com/watch?v=oUME-FnlUKE&t=3502 (ab 58:22 für ~20 Sekunden)
Da kann man nur schreiben:
Der breit gestreute Newsletter mit dem Hinweis auf Playground hat schlicht "die Falschen" erreicht, und nur für Verunsicherungen gesorgt, was auch daran liegt, dass Shopware nach wie vor ein großes Komunikationsprobelm hat - SW spricht nicht die Sprache der Anwender/Kunden
Da helfen dann auch keine hier nachgeschobenen Keynotes und Labervideos - sowas gucke ich mir z.B. grundsätzlich nicht an - alleine schon, weil mir nach spätestens 5 Minuten die Augen zufallen (wer bitte zieht sich freiwillig > 1 Stunde Labervideos rein?) . Ich hätte da dann doch lieber Texte ohne Marketingsprech, da kann man auch mal einen Absatz mehrfach lesen. Was mich betrifft: Ich lese nur "API" - "API" - "API", was Shopware aber nun konkret mit "API" meint, wird nicht geklärt. Als einer, der mit dem VIC20 angefangen hat zu programmieren, habe ich sicherlich eine andere Auffassung zur Begrifflichkeit, als die doch überwiegenden Spätmillenials bei Shopware
"Playground" richtet sich nunmal an Entwickler, Integratoren etc - aber nicht an die breite Masse Newsletterempfänger - also kleine bis mittlere Shopbetreiber.
ICH! Aber mit Geschwindigkeit x1,5 . Das kann man bei Youtube einstellen. Aber man muss bei den Videos schon sehr zwischen den Zeilen lesen und Orakeln, da gebe ich dir recht. Ich weiss auch nicht wovor SW soviel Angst hat Informationen ordentlich zu kommuniziren. Zum Glück sind meine Fragen hier im Forum meist zur Zufriedenheit beantwortet :-D