In der heutigen Folge unterhalte ich mich mit dem digitalen Kumpel Manuel Schöbel über Headless Commerce. Hallo und herzlich willkommen zu Ein Geek kommt selten allein. Mein Name ist Stephan und heute freue ich mich besonders, meinen Lieblingsgeek Manuel begrüßen zu dürfen. Hallo Stephan, ich freue mich extrem. Es geht in dieser Folge um das Thema E-Commerce. Allerdings ist ja ein Riesenfeld. Deswegen beschränken wir uns bei dem Thema auf einen eher kleinen und ziemlich modernen Ausschnitt, nämlich Headless Commerce. Bevor wir aber zu tief in das Thema eintauchen, erstmal zu dir Manuel. Ich habe dich im Intro einen digitalen Kumpel genannt, vielleicht fangen wir da einfach mal an. Ja, wahrscheinlich liegt das daran, dass ich in meiner gesamten Laufbahn mich immer mit dem Digitalen beschäftige, allerdings sehr hands-on als verschiedensten Rollen, viel auch als Entwickler, Freelancer, aber auch CTO, Berater. Genau, das mache ich jetzt schon eine relativ lange Weile, immer im Web-Kontext und auch seit einigen Jahren sehr speziell im E-Commerce-Bereich auf den verschiedensten Ebenen. Und E-Commerce ist ja genau das Thema, worum es geht. Wir sind, oder wir versuchen es zu sein, ein Digitalisierungspodcast. Hier soll es um Digitalisierungsthemen gehen. Und ich glaube, es gibt wenig Bereiche im alltäglichen Doing, die so erfolgreich digitalisiert wurden wie Handel. Da muss man einfach nur mal dran denken, was mit Amazon ist. Die meisten von uns kaufen ja mehr online ein, als dass sie eben stationären Handel kaufen. Und in der Vorbereitung habe ich einmal kurz bei Statista reingeguckt. Und Statista hat auch nochmal gesagt, im Jahr 2022, ich weiß nicht, ob die schon, ich glaube, die haben noch keine 23er Daten, deswegen ist 2022 so das letzte volle Jahr, was sie haben können, ist tatsächlich der Umsatz im B2C E-Commerce. Also wir reden jetzt davon, wenn Endkunden Dinge kaufen können, auf 84,5 Milliarden Euro zahlen. Gesunken, weil das im Jahr davor war Super-Corona-Lockdown, da hat jeder alles gekauft online, also ist um 2% gesunken. Aber diese fast 85 Milliarden Euro, die im Jahr 2022 waren, standen 2015, also so sieben Jahre davor, noch unter 40 Milliarden, also hat sich da mehr als verdoppelt in der Zeit. Und das liegt auch daran, dass die Technologien natürlich vernünftig funktionieren, dass die Leute da Lust drauf haben und dass alles sich so in der Waage schön nach oben geschaukelt hat. Und deswegen, was wäre spannender, als mal da reinzugucken, wo die Digitalisierung denn erfolgreich ist, wo es geklappt hat? Also Online-Handel vor allem als Vater mit zwei kleinen Kindern ist absolut präsent. Also wir kaufen tatsächlich fast alles online ein. Allerdings auch immer mehr. Beispiel das klassische Food Delivery oder der Supermarkt-Einkauf, der bei uns auch schon mittlerweile extrem viel online passiert. Ja, weil irgendwie zwei Stunden rausgehen, einkaufen, wird immer schwieriger. Von daher sind es nicht nur mehr klassische Güter, auch der Supermarkt-Einkauf bei uns absolut online am Start. Das ist ein spannendes Beispiel mit dem Supermarkt, weil da haben wir ja die Situation, Handel funktioniert über bestimmte Channels. Also das heißt, es gibt irgendwie einen Ort, einen Vertriebskanal. Und der Vertriebskanal für Supermarkt, den kennen wir alle, ist der Supermarkt um die Ecke. Wenn ich da was einkaufen möchte, laufe ich hin und hole mir beim Supermarkt die Sachen. Jetzt mit dem Online-Einkaufen von Supermarktgütern ist es natürlich anders. Also ich gehe ja nicht in den Supermarkt und sage denen, jetzt liefert mir Folgendes, sondern dann kommt auf einmal die App ins Spiel. Das heißt, ich habe einen zweiten Kanal, über den ich kaufen kann eigentlich. In der Regel habe ich irgendeine Art von App. Vielleicht habe ich eine Webseite, auf der ich meinen Warenkorb fülle und schwupps, schon habe ich einen Multichannel, weil ich zwei Kanäle habe, über die ich kaufen kann, aber es sind dieselben Sachen. Also es ist quasi der Laden um die Ecke, der Supermarkt um die Ecke, der mir die Gurke bringt, ob ich die jetzt im Laden in den Einkaufswagen gelegt habe oder ob ich die in der App da reingelegt habe. Somit hat man diese Kanäle, die halt immer mehr werden und das wird spannend, wenn du das klassische E-Commerce dir betrachtest, da kannst du ja auch tausend Läden gehen. Du kannst deinen eigenen Webshop haben, du kannst bei Amazon verkaufen, du kannst auf einen Marketplace gehen, du kannst dann irgendwo mitmachen sozusagen, kannst in einem Partnershop sein, wenn ich jetzt der Hersteller von etwas bin, der das nicht nur bei mir, sondern auch in einem Fachvertrieb hat. Und das ist eine der Bewegungen, die wir in einem Handelsmarkt natürlich sehen, dass man über mehrere Kanäle kaufen kann. Ich möchte gar nicht, dass der Mensch, der etwas haben möchte, unbedingt in meinen Supermarkt kommt, sondern er möchte die Gurke haben. Dann will ich ihm doch anbieten, egal worüber er die kaufen möchte, soll er die doch eigentlich kriegen. Das ist dieses ganze Multi-Channel, Omni-Channel Thema, was dann irgendwann kulminiert in No-Line-Commerce. Also wo es wirklich dann egal ist, wo hast du es denn gekauft? Ist es denn in der App gewesen? Ist es denn im Supermarkt gewesen? Ein gutes Beispiel wäre sehr wahrscheinlich ein Vertreter, der vorbeikommt und dir sagt, guck mal hier, so könnte die Tupperware aussehen, wenn es Tupperware so noch gäbe, aber bei mir kannst du nicht bestellen, aber das kannst du in jedem Laden kaufen. Wäre ja Quatsch. Ja, absolut. Wobei man sagen muss, also ich glaube, es gibt so, es gibt verschiedene Wege, die sich entwickeln. Das eine ist halt, ich habe so meine Waren, die ich verkaufen will, genau wie du sagst. Überall, so auf den ganzen verschiedenen Marktplätzen, da gibt es ja unendlich viele, nicht nur Amazon, da kann ich dann irgendwelche Aggregatoren nutzen, die mich dann sozusagen auf allen Kanälen irgendwie raus aussteuern. Aber da muss man halt auch sagen, Man sieht schon, dass durchaus auch da der Trend wieder da ist, dass man sagt, naja, es ist mir doch nicht mehr ganz egal, dass ich einfach überall verkaufe. Ein ganz klassischer Händler, ja, der will einfach nur abverkaufen. Man merkt aber schon, dass ja auch das sozusagen Branding und Markenthema immer weiter da ist. Das heißt, ich möchte schon eine Marke entwickeln und da ist dann wiederum doch der eigene Store. Also sozusagen nicht egal, wo ich verkaufe, sondern wirklich möchte bei mir sozusagen in meiner virtuellen Heimat verkaufen. Schon ein Thema, das glaube ich immer größer wird und auch irgendwo immer wichtiger wird. Ganz klassisches altes Beispiel ist Amazon als Marktplatz ist halt, die können halt mal deine Preise einfach irgendwie anpassen, ändern oder sagen, nee, du bist zu teuer, das streiten wir nicht aus. Also das ist nicht mehr dein Shop, das ist auch nicht mehr deine Produkte so richtig, sondern du bist schon fast ein Angestellter von Amazon, wenn du da verkaufst. Solche Dinge gibt es halt in dem Bereich auch. Genau, und dann hast du natürlich, genau wie du sagst, wenn der Vertriebler bei dir zu Hause vorbeikommt, das gibt es halt auch gerade so im Kontext von Live-Video-Shopping und so weiter. Auch das sind super spannende Bereiche, der ja auch Online-Handel letztlich ist. Ich hatte das tatsächlich letztens. Ich habe nicht, weil ich es kaufen wollte oder sogar musste, einfach nur, weil es mich interessiert hat, bin ich auf der Webseite, ich glaube, von TrueNAS oder so gelandet, also wo diese Network Attached Storage Systems, da gibt es dieses Betriebssystem dafür und die verkaufen auch ihre eigenen NAS-Systeme. Das Spannende dabei ist, die haben dann halt einen Link, viel Spaß, kauf es dir bei Amazon. Also auf der Webseite bieten sie es eigentlich an, das ist deren Produkt, aber du kannst es bei denen gar nicht kaufen. Das heißt, mit allen Vor- und Nachteilen, die so ein Amazon jetzt mit sich bringt, sei es Dropshipping, sei es halt, du musst dich nicht darum kümmern, dass jemand eine Retoure bekommt, du musst dich nicht darum kümmern, dass die Kreditkartenzahlung nicht durchgeht, aber auch mit allen Nachteilen, dass du halt den Shop nutzen musst, dass du gar nicht so sehr die Daten vielleicht bekommst in der Qualität, wie du sie haben möchtest über die Leute, die sich interessieren. Conversion Rates sind völlig unklar, weil du kannst vielleicht mit so einem Affiliate Link das noch rausfinden, hat jemand meinen Nass gekauft, weil er auf meiner Seite war oder weil er woanders war. Du weißt halt relativ wenig und gibst dadurch auch viel auf. Ja und es geht ja noch viel weiter, was vielleicht auch eher klassische, so kleine und mittlere Händler, aber potenziell passieren kann, ist, dass halt einfach dein Vertrieb sozusagen, dein Kanal einfach geschlossen wird. Sagt Amazon einfach aufgrund von irgendwelchen Automatisierungen, nee, du verkaufst jetzt hier erstmal nicht mehr, bis das sozusagen aufgelöst wird. Das ist dann so. Genau, das sind alles Sachen, die durchaus passieren bei den Marken sozusagen, die halt dann verlinken. Ich glaube, das ist wahrscheinlich noch viel so ein klassisches Hersteller-Thema. Also ich bin Hersteller schon seit Jahren und ich verkaufe halt über meine Händler. Das ist halt so der klassische Weg. Den gibt es halt. Ich habe jetzt vielleicht noch eine Webseite dazu gekriegt, wo man irgendwelche Anleitungen PDF-mäßig runterladen kann, habe aber sicherlich so ein bisschen den Konflikt zwischen. Verkaufe ich jetzt auf meiner eigenen Seite oder verkaufe ich weiterhin nur über die Händler, wie mache ich jetzt das gegebenenfalls Pricing und so weiter und da gibt es aber natürlich auch wieder sehr viele, die halt sozusagen komplett neu rein als Hersteller online, starten und schon immer sozusagen ihre eigenen Brand plus Commerce online halt hatten, da stellt sich halt die Frage gar nicht. Genau, also da gibt es sicherlich sehr viele Ausprägungen, alles mit seinen Vor- und Nachteilen, aber viele Herausforderungen, ich glaube gerade für die klassischen, die halt große Webseiten haben mit zigtausenden Produkten und so weiter, da in den Verkauf zu kommen online ist eine Herausforderung. Damit haben wir ja sehr viel über Commerce gesprochen und sehr wenig über Headless. Und die Frage ist, was ist jetzt diese Headless-Komponente daran? Also wo verschwindet der Kopf? Was war der Kopf eigentlich vorher? Und wodurch wird er gegebenenfalls ersetzt? Ja genau, also das Headless-Commerce ist tatsächlich eher im Grunde genommen ein technischer oder architektureller Begriff per se. Wie ich mir das vielleicht besser vorstellen kann, ist da ein Beispiel von einem absoluten Kaffee-Nerd, der irgendwie Inhalte macht, YouTube-Videos, Content oder so, der testet irgendwelche Kaffeemaschinen, was auch immer, der hat jetzt eine Webseite mit einem klassischen CMS-System irgendwie, Und hat da seinen Inhalt drauf, die Produkttests und so weiter. So jetzt irgendwann sagt er, okay, ich habe so viel Traffic, also so viele Leute kommen auf meine Seite, ich mache jetzt noch eine eigene Brand so und mit irgendwelchen Kaffee-Zubehör-Produkten und so weiter. Die will ich jetzt verkaufen, die will ich aber auf meiner Seite verkaufen, weil da habe ich ja den Traffic. Und was dann klassischerweise passiert ist, ich habe jetzt eben meine... Also anders als bei diesem Nass-Beispiel, du willst die Leute nicht wegschicken und sagen, geht mal in den Laden, sondern du willst sie hier behalten und sagen, hier, wenn du dich informierst, kannst du gleichzeitig auch kaufen. Genau. Und dann habe ich halt sozusagen aus der klassischen Sicht eben mein Tool, mein Service sozusagen, irgendwie ein WordPress oder was auch immer. Der ist für meine Webseite da. Und jetzt will ich aber verkaufen, also hole ich mir noch irgendwas dazu, was verkaufen kann. E-Commerce-System wie zum Beispiel ein Shopify oder so. Genau. Nicht mehr Magento, sonst was. Genau, und da sozusagen konfiguriere ich meine Produkte, habe irgendein Theme, das sieht dann irgendwie aus und läuft dann nicht unbedingt direkt auf meiner Seite, also ich bin jetzt der koffeexperte.de, sondern eben auf shop.koffeexperte.de, was de facto eine andere Domain ist, das ist eine andere, komplett andere Webseite, komplett anders ausgespielt wird. Das heißt, im traditionellen Sinne habe ich einfach Systeme, egal ob Content oder jetzt E-Commerce, die dir alles machen. Also wenn ich ein E-Commerce-System habe, baue ich da meine Produkte rein, aber auch die Präsentation, also die Seite, wo die Produkte dargestellt werden, kommt komplett aus diesem einen System. Das ist so das klassische monolithische System. So, der Unterschied zu Headless ist jetzt im Grunde genommen in der Analogie, der Head ist der Kopf, also das Frontend, also die eigentliche Webseite. Also die Darstellung. Die Darstellung, also da, wo sozusagen die Bilder im Browser gemalt werden und so weiter. Das ist das Frontend, das ist in dem Kontext der Head. So, Headless bedeutet jetzt einfach nur, dass mein E-Commerce-System beschnitten wird. Das E-Commerce-System kann jetzt nicht mehr die Seite rendern. Das kann es nicht mehr, sondern es kann nur noch Produkte da eingepflegt werden. Ich kann sagen, wie teuer ist das Produkt und so weiter. Das war's. Damit sozusagen endet der Horizont von diesem Headless-E-Commerce-System. Hat aber selbst auch ein Frontend, weil du musst ja irgendwie die Daten da reinbringen, aber es ist nicht für den Endkunden sichtbar. Genau. Also da definitiv ein guter Punkt immer zu unterscheiden zwischen dem Admin-Backend sozusagen, also das, was ich administrativ brauche. Auch da gibt es dann durchaus, auch da gibt es durchaus, ist es durchaus auch so, dass ein Headless-E-Commerce-System auch das abschneiden könnte. Also ich könnte auch mein eigenes, genau könnte ich schon durchaus machen, aber üblicherweise machst du es nicht, sondern du hast halt genau das Backend zur Pflege, zur Administration, das hast du schon, aber genau der Headless-Kontext ist halt sehr nutzerorientiert, also das ist das, warum du es machst, es geht natürlich immer um den Nutzer, um einen gewissen Mehrwert zu bieten. Genau, so jetzt hast du sozusagen ein helles E-Commerce-System und das ist es. Also ein helles E-Commerce-System ist ein E-Commerce-System, mit dem du per se erstmal nichts verkaufen kannst, weil es halt keine Webseite rendern kann. Das klingt so ein bisschen wie ein Datengrab. Du legst halt ganz viele Informationen da rein und dann sind sie erstmal da und du müsstest jetzt irgendwas bauen, was diese Daten darstellt und Aktionen ermöglicht. Weil du kannst ja damit, klar, über API kannst du interagieren, aber jemand, der kaufen will, kann halt noch nicht kaufen. Selbst wenn du dein System mit dem Backend-Admin-System schön bepflegt hast. Ist. Halt erstmal alles da. Genau, das ist auf jeden Fall erstmal sozusagen, wenn man jetzt wirklich komplett irgendwie außerhalb dieser Welt ist, erstmal Rückschritt, weil ich nehme ja dem eine Funktionalität, das heißt, das kann jetzt was weniger. Plus, ich habe jetzt sogar mehr Arbeit, weil ich muss jetzt hingehen und das, was es vorher gemacht hat, irgendein Theme, das irgendwie schön aussah, das fange ich jetzt an, komplett selber zu bauen, was ja irgendwie erstmal sehr absurd klingt. Also es klingt nach mehr Aufwand, als ich nehme mein WordPress, was ich eh schon hatte, mache dann WooCommerce rein und freue mich einfach. Ja, genau. Also das Das ist absolut so. Du baust im Endeffekt dein Frontend halt komplett selber. Was ist jetzt der große Vorteil in Anführungsstrichen? Es kann ein großer Vorteil sein, wenn ich das tue, weil ich kann zum Beispiel völlig andere Technologien nutzen, um diese Website zu bauen. Das heißt, ich bin nicht mehr abhängig davon, von den Vorgaben dieses E-Commerce-Systems. Und da ist immer so ein bisschen die Frage, ist denn ein E-Commerce-System, das ja schon sehr viel Komplexität mit sich bringt, weil es ja Handel, den Verkauf abbildet, ist das schon nicht unkompliziert, ist das System und die Menschen, die das bauen, sind das wirklich die aller allerbesten auf der ganzen Welt, um super coole, effiziente Webseiten zu bauen? So und die Antwort ist klassischerweise nein, weil gerade so in der Webentwicklung entwickelt sich halt unendlich viel, unendlich schnell. Da wird kein E-Commerce-System der Welt immer irgendwie mithalten können. Dann auch noch das sozusagen im Frontend so, zwar können die auch gar nicht, weil die haben ja Bestandsnutzer, die haben jetzt nicht unbedingt Bock, dass sich da irgendwie alle Nasen sagen, was ändert. Genau, das heißt, ein Vorteil in Anführungszeichen ist Technologieunabhängigkeit von meinem Backend. Also ich kann mein Frontend bauen, womit und wie auch immer ich das möchte. Genau, das Versprechen ist dann in der Regel bessere Performance. Die Website ist schneller plus User Experience ist viel, viel besser, weil du halt alles selber baust. Das funktioniert nur, wenn man es halt so baut, dass es auch performanter ist und die User Experience auch wirklich besser ist. Weil wenn du halt ganz viel selber baust, ist das viel Arbeit und natürlich ist da, würde ich sagen, eine gewisse Expertise schon Voraussetzung für das zu tun. Bringt es irgendeinen Vorteil, wenn wir dieses Channel-Beispiel nochmal nehmen? Also wenn wir jetzt sagen, du verkaufst auf deiner eigenen Seite, jetzt shop.coffeenerd.de da verkaufe ich das und jetzt möchte ich gerne noch einen anderen ja, irgendeinen anderen Anbieter enablen. Ein Geek kommt seltenerlei, möchte jetzt auch Kaffee verkaufen. Könnte ich dann da quasi auch einfach reingehen oder würdest du sagen, du würdest das eh über klassische APIs machen? Das ist da kein Vorteil an der Seite. Nochmal die Frage. Frage. Kommen wir nochmal zurück zu dem Channel-Beispiel. Jetzt habe ich ja einen Channel, über den ich verkaufe, das ist diese shop.coffeenerd-Seite. Wenn ich das Headless habe und wenn ich es richtig verstehe, ist ja der Vorteil, dass ich das jetzt in verschiedensten Medien ausspielen kann. Also ich habe jetzt nicht unbedingt die Webseite, sondern ich könnte es überall hinbringen. Ich könnte es auf die eingekommen-selten-allein.de-Seite bringen und auch da den Kaffee verkaufen. Ich könnte es vielleicht sogar in einen YouTube-Stream einbinden. Ist das jetzt sozusagen das, wo der Vorteil liegt, weil theoretisch, ich habe ja auch bei den klassischen Shop-Systemen, habe ich einfach eine API, das heißt, ich könnte da auch irgendwas programmieren und einfach an die API rangehen, müsste dafür ja gar kein Headless Commerce machen. Ja, genau, also ich würde sagen, der primäre Vorteil liegt nicht so sehr darin, weil ich in der Regel ja, genau wie du sagst, bei einem klassischen E-Commerce-System die Anbindung ja immer über Integration löse. Also auch wenn ich jetzt eine API habe, muss ich ja trotzdem Integration zum Fremdsystem haben. Also das hilft ja nicht, wenn ich jetzt, also YouTube ist es relativ egal, wie meine API aussieht. Ich muss dafür sorgen, dass meine Produkte in YouTube reinkommen oder klassisches Beispiel Google Shopping oder so. Da muss ich trotzdem meine irgendwelche CSV-Dateien generieren und da hochladen. Ob ich jetzt Headless habe oder nicht, ob ich jetzt das direkt aus der Datenbank baue oder nicht. das ist, würde ich sagen, nicht unbedingt so der Vorteil bezogen auf Fremdsysteme. Es kann natürlich ein Vorteil sein, wenn ich eine gute API habe, wo ich wirklich an alles drankomme. Das kann natürlich schon ein Vorteil sein, aber ich glaube, der große Vorteil ist jetzt, Eigentlich dann gegeben, wenn ich beispielsweise, um jetzt in dem Channel-Beispiel zu bleiben, ich habe jetzt meinen Kaffeeshop und jetzt möchte ich auf meiner Webseite, verkaufe ich ja schon auf meinem Shop, aber das ist jetzt so ein hypothetisches Beispiel. Beispiel. Oder nicht so, du machst jetzt noch eine App, du hast deine Mobile-App und über die Mobile-App willst du auch verkaufen können. Das ist vielleicht ein klassisches Beispiel. Dann gibt es halt oft die etwas sehr weit gefassten Beispiele mit IoT und so. Mein Kühlschrank könnte ja jetzt auch über die API dann direkt da kaufen und so. Das mag sein. Ich könnte ja Chat-GPT anbinden. Ich könnte das anbinden und sagen, stell mir meinen Kaffee, so ähnlich wie es über Alexa ja auch nur mit Amazon funktioniert? Ja, genau. Aber das ist halt immer so ein bisschen so, es ist halt immer so ein bisschen die, Integration zu Fremdsystemen so, da sehe ich nicht unbedingt so den unglaublichen Vorteil von Headless, sondern ich glaube, der große Vorteil von Headless ist halt immer, wenn du in deiner eigenen Welt sozusagen bist, was kannst du denn alles machen mit Headless für deine Nutzer? Also was kannst du selber bauen? Und da ist so ein, ich würde sagen, so der 90% Vorteil, Und irgendwie der Vorteil, den du halt allermeistens hast, ist halt, du kommst halt dann dahin, dass du, wenn du dein Frontend selber baust, dann kannst du ja für dein Frontend das auch so bauen, dass es nicht nur Produkte verkaufen kann, sondern eben auch zum Beispiel dein Content schön darstellt. Also wenn wir jetzt bei diesen Kaffee-Experten bleiben, dann habe ich halt nicht mehr shop.mein-kaffee.de und mein-kaffee.de für die Inhalte, sondern ich habe halt nur noch diese eine Seite. Und egal, wo ich mich auf dieser Content-Seite befinde, es gibt immer einen Warenkorb. Ob ich jetzt im Blog bin, ob ich auf einem How-To bin oder wo auch immer, auf dieser Seite gibt es immer diesen Warenkorb. Und das hast du ja nicht, wenn du jetzt nur eine monolithische Seite hast aus einem klassischen CMS-System oder so. Da gibt es halt keinen Warenkorb, weil das CMS kann sowieso keinen Warenkorb abbilden, weil du kannst ja nichts in den Warenkorb hinzufügen mit einem klassischen WordPress oder so. Das heißt, wenn ich das jetzt konkret anwenden würde, könnte ich den Supermarkt um die Ecke wieder nehmen. Der hat vielleicht eine Abteilung oder der hat eine Webseite, da sind Rezepte drauf. Und bei den Rezepten kann ich einfach auch, schmeiß mir das alles in den Einkaufswagen, klicken. Also ich kann anpassen, mach es für vier Personen, mach es für sechs Personen, dann kriege ich zehn Karotten da rein oder 20 Karotten da rein, je nachdem, was ich brauche für mein Rezept. Weil das alles aus dem selben System kommt. Also da wäre ja die Synergie, die ich dann nehmen kann. Wenn ich der Supermarkt-Webseiten-Betreiber bin, sozusagen. Ich habe das geschrieben, ich mache das CMS, ich mache aber auch den Commerce-Teil. Ja genau, da fängt es dann halt so, aus meiner Sicht zumindest spannend zu werden. Also da muss man sozusagen von der Beruflichkeit jetzt nochmal wieder ein Fass aufmachen natürlich, weil das Headless ist tatsächlich von der Beruflichkeit wirklich nur, du hast ein Headless-E-Commerce-System, sobald du quasi ein E-Commerce-System hast mit einer API und das Frontend selber gebaut hast, das unabhängig davon ist. So, das Headless. Da ist halt immer die Frage, okay, was gewinne ich dadurch durch wirklich. Dann kommt jetzt das nächste Buzzword, ist halt dieses Composable Commerce, wo ich dann sage, ich habe jetzt nicht nur ein Headless-System, sondern zwei. Ich habe nämlich ein Headless-E-Commerce-System und ein Headless-CMS. Die sind beide Headless. Da ich ja das Frontend komplett selber baue, kann ich jetzt selber entscheiden, was stelle ich denn auf der Seite dar, das aus den verschiedenen Systemen kommt. Ich kann mir das also zusammenbauen. Also ich nehme, und da bleiben wir bei dem Rezeptbeispiel, ich nehme mir. Eine Rezeptseite, wo ich zum Beispiel sogar nicht mal die Rezeptdaten aus dem CMS hole, sondern eben aus einem Tandori oder so, so ein Rezepte- Management-System, das auch eine API hat. Da nehme ich mir das raus, die Produktdaten hole ich mir aber aus dem E-Commerce-System über die API und dann habe ich vielleicht sogar noch bestimmte Content-Bereiche oder so auf der Seite, die hole ich mir aus dem CMS, und das kann ich dann im Endeffekt alles so zusammenstrukturieren, da kommen wir halt zu dieser wesentlich besseren User Experience, weil ich einfach wesentlich interessantere Inhalte auf der Seite darstellen kann, plus aber die Funktionalität auch erweitert habe, weil ich, genau wie du sagst, jetzt sagen kann, Add to Basket, dass dann im Endeffekt das Signal an den E-Commerce Backend gibt, hier diese Produkte bitte in den Warenkorb legen und das E-Commerce Backend sozusagen eben den Warenkorb auch wirklich dann abbildet. Und wenn ich das mache, Und dann fange ich an halt schon durchaus sehr, sehr schnell sehr viele Vorteile zu haben, wenn ich halt Headless unterwegs bin. Ich sehe da viele Parallelen dazu, wie man auf klassischen Webseiten ja aus unterschiedlichen Third Partys irgendwas eingebunden hat. Du hast da einen Ads-Server, da kommen irgendwie Ads rein, die musst du irgendwie einbauen. Dann hast du vielleicht noch irgendwie eine Google-Integration für deine Karte, für eine Anfahrt oder dergleichen. Also du hast ja auch aus verschiedenen Quellen hast du Sachen zusammengebaut und hast dann als ein Ding gerendert am Ende. Und jetzt ist es auch so, ich habe verschiedene, aber die sind nicht Third Party, sondern irgendwie First Party, weil das ist ja von mir. Und was es eigentlich erleichtert, ist ja gar nicht so sehr das, was in der technischen Umsetzung passiert, sondern es ist ja eher die Frage der Pflege und was ist dahinter. Also welche Leute befüllen diese Systeme, wie stellt man sicher, dass das synchron bleibt, also dass die Dinge, die wir am Lager haben, auch in dem E-Commerce-System drin sind und dass die Content-Dinge vielleicht nach den richtigen CI-Richtlinien sind, dass man da auch nochmal drauf achtet, dass das Wording vielleicht richtig gebrandet ist und dergleichen. Und somit ist der Vorteil, der eigentlich nicht an der Stelle, wo du baust, weil ob du jetzt Software baust mit einem Headless oder ob du Integration über APIs baust, ist ja jetzt auch noch nicht so interessant. Das Spannende ist das, was über diese verschiedenen Ebenen hinweg geht, also was menschlich dann passiert und organisatorisch. Also die, genau, also der, der ich ja vom Herzen ja durchaus auch Entwickler bin, würde ich dir insofern widersprechen, weil es natürlich viel cooler ist, mit anderen Sachen zu bauen, als jetzt irgendwie so in Themes um es irgendwie rumzufuschen. Aber ich bin vollkommen bei dir. Genau, technische Vorteile hin und her. Es ist auf jeden Fall so, dass du ja, wenn du jetzt so ein Online-Produkt hast, was auch immer, du hast ja in jedem Fall die Leute, die die Content-Pflege machen. Aber du hast auch die Leute, die zum Beispiel das Design eben machen. Und du hast die Entwickler, die das letztlich umsetzen. Ja, klassische Arbeitsteilung. Genau. Und auf den drei Ebenen hast du, Hast du tatsächlich mal sehr, sehr große Vorteile, weil stell dir vor, du hast jetzt, das passiert halt sehr häufig, du hast halt irgendwie meinetwegen auch ein Moodle LMS oder deine Content-Seite und so weiter. Jetzt stell dir einfach mal nur vor, du hast deine Hauptnavigation oben. Und die soll jetzt überall gleich sein, aber genau gleich. So, dann habe ich aber, wenn ich jetzt klassisch verschiedene Systeme habe, dann habe ich ja komplett ein Change-Trick-Quest. Für jedes einzelne Team. Erstmal das, plus ich habe ja vielleicht unterschiedliche Technologien, ich habe eine unterschiedliche Code-Basis, um das genau gleich zu bauen. Das funktioniert natürlich nicht wirklich gut. Wenn ich jetzt das Headless mache, dann ist es der exakt gleiche Code. Also wenn ich jetzt sozusagen für diese verschiedenen Domänen von Commerce zu Content und so weiter, das ist alles das gleiche Frontend. Das heißt, ich kann sozusagen Designvorgaben machen. Als Entwickler kann ich halt auch ganz einfach das umsetzen einmal sozusagen, dann ist es halt so. so. Und ein anderer Vorteil ist halt, wenn du dir so klassische, Systeme anguckst, dann ist es ja in der Regel so, dass du da, wo du den Content editierst, zum Beispiel auch bei einem Produkt, bei einer Produktbeschreibung, da gibt es ja in der Regel dann noch den HTML-Editor. Das heißt. Ich kann dann da hingehen und ein bisschen HTML noch reinbauen. Ich kann dann vielleicht hier nochmal irgendwas in Fett machen oder die Farbe einfach im Inline-Style so nochmal ändern. Das kann ich als Editor machen, so, wenn ich Lust habe, weil irgendwie wie ist das so eine Business Requirement und dann mache ich das halt. So, wenn dann jetzt irgendwas nicht funktioniert oder so, dann darf der Entwickler halt gucken, was ist da los, habe ich noch nirgendwo gesehen und dann muss der gegebenenfalls noch ins E-Commerce-Admin-Backend reingehen, um sich dann da irgendwie anzugucken, was ist denn da in dem HTML. Also, es ist halt wirklich völlig absurd und wenn du jetzt aber... Und das ist halt auch sozusagen technisch nochmal ein wichtiger Punkt. Die APIs geben ja kein HTML oder so raus, sondern strukturierte Daten. Das heißt, dass das Rendering oder das sozusagen, wie mache ich jetzt aus den Daten wirklich HTML, also das, was im Browser dargestellt wird, das passiert eben immer auf dieser Frontend eben. So, und das ist halt die Domäne der, rein die Domäne der Entwickler und der Designer, meinetwegen. Und somit hast du auch da organisatorisch eine viel, viel bessere Teilung. Also du würdest es ja eh über Markups ja wahrscheinlich lösen. Du würdest ja niemals HTML reinbringen, sondern du würdest irgendeine Art von Tag machen, das hier bitte strong ausgezeichnet oder irgendwie hervorgehoben, damit du dann später interpretieren kannst, wie muss ich das in diesem Medium jetzt darstellen. Also muss ich das mit einem bold Tag machen oder blinking oder wie würde sich das manifestieren? Weil gerade wenn du diese, also ich glaube, wer das 2024 noch macht, der ist irgendwie stecken geblieben. Weil man sollte nicht so ein Pre-Rendering machen in Systemen, wo Leute, die nicht technisch sind, semantische Informationen pflegen sollen. Ja. Absolut. Und das ist halt vielleicht sozusagen in einem Headless-Content-Management-System vielleicht nochmal plakativer. Aber da kann ich halt, sagen wir mal, ich habe jetzt eine Produktseite, meine Produktdaten kommen aus dem E-Commerce-Bereich, aus dem E-Commerce-Backend. Das wird auf eine bestimmte Art und Weise gerendert und darunter habe ich jetzt nochmal, den Produktbeschreibungsbereich und dieser Bereich ist ja gerade wenn ich jetzt auch so einen, gebrandeten Shop habe, also einen Shop von einer Marke selber das ist ja oft so, wenn man jetzt irgendwie, keine Ahnung ich finde Dyson zum Beispiel, cooles Beispiel oder Apple oder was auch immer, dann ist das ja nicht nur ein paar Bullet Points, sondern das ist ja wirklich richtig ausgefeilte schöne Grafiken mit Text das könnte kein Headless sein. Ja, wie die das jetzt genau machen, das weiß ich bei dem Beispiel nicht, aber der Punkt ist halt, das ist ja Content und dann ist immer die Frage, du brauchst ja schon ein gutes Content-Management-System, um solche Dinge halt zu machen und ein E-Commerce-System ist in der Regel halt nicht unbedingt das geilste CMS und da kann ich es halt gut kombinieren. Aber was halt noch relevant ist, ist ja, ich habe ja in einem Headless, beispielsweise CMS, kein HTML, das ich da reinbaue, sondern weil ich ja nur die Daten rausgebe, habe ich auch in einem Headless CMS, und das ist halt tatsächlich, da können wir vielleicht gleich nochmal drauf, ein organisatorisches Ding, schon anders, sondern ich konfiguriere quasi so bestimmte UI-Bereiche. z.B. Nennt man die Blocks oder Komponenten oder whatever. Das heißt, dann habe ich klassischerweise ganz einfach, da soll links ein Bild sein und rechts soll ein Text sein. Dann habe ich ja sozusagen nur noch in diesem Admin-Backend kann ich ein Bild auswählen und dann habe ich ein Textfeld, wo ich Text reinschreiben kann. Und dann kommt nämlich genau der Punkt, den du gerade genannt hast. Jetzt soll aber z.B. die Headline eine bestimmte Farbe haben. Und da habe ich dann nämlich das Dropdown. Warum ist das alles jetzt so toll? Warum rede ich so lange darüber? Das Gute ist halt, ich kann jetzt eben im Backend klar vorgeben, in diesem Dropdown stehen vier Farben drin, irgendwie Rot, Blau, Grün oder Gelb. Keine Color-Codes, sondern wirklich nur die Farben ausgeschrieben. Und dadurch kann ich jetzt auch für die Editoren ganz klar vorgeben, welche Farben können überhaupt genutzt werden, aber gleichzeitig auch, wie genau, in welchem Max-Code sozusagen werden die Front-Inhalte auch wirklich dargestellt. Das heißt, ich nehme im Endeffekt auch sozusagen durch den Helles Anlass, oder ich kann, wenn ich das möchte, was ich machen würde, dem Editor sozusagen komplett die Fähigkeit nehmen, auf UI-Themen irgendwie irgendwie einzuwirken. Also ich kann am höchsten so noch sagen, eben das ist irgendwie fett oder groß oder klein oder die und die Farbe. Also du kannst dem Markup Elemente definieren und sagen, dieses hier wäre Code, dieses hier wäre hervorzuheben, das ist entweder semantisch, dass du sagst Headline oder dass du es vielleicht auf kleiner Ebene sagst, das hier kriegt jetzt die Hervorhebungsfarbe. Ja. Ja genau und das kannst du dann halt das kannst du halt selber komplett definieren. Deswegen ist halt das Headless-Thema, Es ist halt nicht nur, dass du ein Headless-Backend hast und das Frontend komplett selber, sondern die Art und Weise, wie du sozusagen Admin-Backend in dem Headless-Welt benutzt, ist schon auch anders. Also ganz einfach ist ja, jetzt stell dir vor, du hast ein Headless-E-Commerce-System und du hast da irgendwie ein Produkt, das beschreibst du. Wenn dieses monolithische E-Commerce-System auch das Rendering machen würde, dann kannst du dir natürlich eine Vorschau anzeigen lassen von dem Produkt. Wenn du das Frontend jetzt komplett selber gebaut hast und auch noch andere Systeme für diese Produktseite benutzt werden, um die zu rendern, kannst du es natürlich nicht. Das heißt, du verabschiedest dich in großen Teilen davon, dass du diese Rizivik Live Editor Sachen in deinem Backend hast. Sondern wenn ich das sozusagen nur noch komponentenbasiert mache, dann ist es schon abstrakter. Auch da gibt es natürlich immer wieder Weiterentwicklungen und so weiter. Genau, grundsätzlich sozusagen, es ist schon ein bisschen anders. Das heißt für mich, die Zielgruppe ist eigentlich diejenigen, die, also Apple würde ich ausnehmen, weil Apple hat erstens wenig Produkte, die können es relativ gut schaffen, nochmal alle Webseiten zu aktualisieren, wenn die WWDC gelaufen ist. Ich würde auch nicht diejenigen nehmen, die nur so eine Handvoll Produkte haben. Ich glaube, bei all denen wird das super spannend, die halt viele Produkte haben, die irgendwie gleichförmig sind. Also stell dir mal vor, du hast irgendwie 20.000 Schrauben im Sortiment. Für diese Schrauben würdest du ja nicht für jede einzelne Seite definieren. Das Wort hätte ich gerne fett und das hätte ich gerne in rot. Du hast halt 20.000 Schrauben und du hast halt so Katalogprodukte im weitesten Sinne, wo halt ganz, ganz viel durchgeht. Und ich glaube für diese Szenarien ist es total spannend, auch der Supermarkt, meine Möhren, mein Kohlrabi und dergleichen, auch da werde ich die einzelnen Seiten jetzt nicht großartig auszeichnen, weil das sind nicht so erklärungsbedürftige Produkte. Auch bei dem Kaffee könnte ich mir vorstellen, wobei wenn der wenig hat, dann will der bestimmt bei manchen Sachen das noch hervorheben und sagen, dieser riecht aber besonders nach Kakao oder sonst was. Aber ich kann mir vorstellen, die Zielgruppe ist halt, wenn du dich wirklich arbeitsteilig darum kümmerst, dass jemand diese Produkte einpflegt und die Produkte soll verkauft werden und wir haben eine Standarddarstellung und wir sind nicht eine Designbude, die halt spezielle Designanforderungen für jedes Produkt hat, sondern es sind halt einfach verschiedene Schuhe. Und dann willst du die Schuhe raushauen. Dafür ist es natürlich mega gut. Ja, genau, also die, wobei ich sozusagen noch umgekehrt argumentieren würde, wenn du jetzt wirklich eine ganz klassische Produktseite hast, die wirklich einfach komplett Standard ist, dann kriegst du das natürlich auch ganz gut abgewählt mit einem klassischen, also so ein klassisches E-Commerce-System ist halt gut genug, um jetzt eine einfache, ganz klassische Produktseite zu bauen, zu rendern. Da hast du dann vielleicht weniger die Vorteile, aber du hast ja selbst schon, wenn du sagst, du hast eine Produktseite und darunter irgendwie diese drei Blogbeiträge sind auch spannend zu dem Produkt oder so, dann hast du selbst da schon eine Vermischung irgendwo zwischen den Bereichen. Immer wenn du wirklich sozusagen ein bisschen mehr oder spannenderen, interessanteren Content irgendwie oder sozusagen darstellen willst und du halt nicht wirklich nur ein reiner Abverkaufshändler bist mit, du hast Produkt ABC, du hast deine Kategorisierung und dann wird halt irgendwie abverkauft und du hast halt irgendwie kein Markenthema oder so oder kein Content-Thema oder so. Also sobald das der Fall ist, genau, oder du halt auch einfach neue digitale Geschäftsmodelle irgendwie entwickeln willst, da sind Handlesansätze auf jeden Fall super spannend. Kommen wir mal so ein bisschen zu dem Thema, was du denn konkret machst. Also wir waren ja jetzt ein bisschen hands-off, abstrakt, was so generell geht. Was machst du so in deinen Projekten? Also wie sieht das aus? Was ist so das, wie die Arbeit regelmäßig mit Headless CMS oder Headless Commerce aussieht? Wenn wir halt Content-Webseiten machen, auf jeden Fall immer ein Headless CMS. Also wir machen generell erstmal alles Headless. Habt ihr eine Präferenz? Also sagt ihr? Ja. Genau, also wir sind, wir sind jetzt nicht als Agentur irgendwie so riesig, dass wir jetzt irgendwie 15.000 Experten für alles mögliche rumspringen haben, sondern das, was wir ganz konkret machen, ist Strapi als Headless CMS, Shopware 6 als quasi Headless E-Commerce System und dann Next.js React sozusagen als Head, als Frontend. Das ist unser Core. Das ist das, was wir machen. Da gibt es sicher zig Systeme, mit denen man die Sachen bauen kann, aber das ist halt das, was wir machen im Kern. Das sind die Technologien, die wir nutzen. Und damit kannst du halt im Grunde genommen mehr oder weniger alles umsetzen. Wir sprechen ja schon darüber, dass man irgendwie Leuten, die dann ein Backend brauchen, um Daten einzupflegen, irgendwas tun. Wie viel Frontend-Arbeit ist das? Muss man verhältnismäßig mehr Frontend machen, weil man ja Headless ist? Oder ist es eigentlich so, dass man genauso viel macht wie vorher im Grunde genommen? Weil du musst ja eh irgendwie diese Anbindung machen womöglich. Ja, also man darf das nicht unterschätzen. Es ist extrem viel Arbeit, das Frontend für einen E-Commerce-Kontext zu bauen. Weil wenn man E-Commerce sich anguckt, dann könnte man sagen, gut, man hat eine Startseite, dann hast du irgendwie eine Kategorieseite, dann hast du eine Produktseite, dann legst du das in den Warenkorb und kaufst. Das sind aber so unendlich viele Details, dass... Das Bauen eines E-Commerce Frontends sehr viel Aufwand ist. So, das heißt, wenn ich das machen will, dann bin ich mit Sicherheit eher kein irgendwie kleines, kein kleiner Online-Händler, der halt irgendwie, keine Ahnung, irgendwie sechsstellig Umsätze macht oder so im Jahr, weil das ist schon Aufwand. Und das andere ist immer so ein bisschen die Frage, worauf setzt du halt auf? Wir haben das schon über relativ lange Zeit, das Frontend, so komplett selber gebaut. Das heißt, wir haben bestimmte Funktionalitäten, die wir einfach benutzen. Das ist einfach schon wahnsinnig viel da. Ja, du kannst es aber theoretisch im Design komplett anpassen, wie auch immer du das K möchtest. Also das ist ja die Individualisierung, Customization und so weiter. Kannst du alles machen. Es gibt aber fürs Frontend mittlerweile so ein paar Sachen, die schon existieren, die man nutzen kann. Es gibt so jetzt in der Next.js Welt so ein Next.js E-Commerce Starter Kit. Wobei man da muss man auch sagen, das ist, wenn man einen richtigen E-Commerce Shop baut, wirklich sehr wenig. nicht. Also das ist, ne? Ja, es ist halt irgendwie ganz cool, aber es ist nicht wirklich, dass man sagt, okay, wenn ich damit starte, kann ich easy einen Shop, den ich sonst mit einem fertigen Shop-System und irgendeinem Theme oder so gebaut habe, dann nehme ich mir dieses Starter-Kit und bin vielleicht ein bisschen langsamer, weil ein bisschen mehr Aufwand im Front ist. Das ist gigantisch viel mehr Aufwand. Ähm, genau. Dann gibt es noch so Sachen wie View Storefront, die haben, glaube ich, relativ viel. Also da hast du schon so so ein sehr ausgedehntes Frontend so für alles, was du brauchst im E-Commerce. Das ist halt Vue.js, das ist nicht unbedingt unsere Baustelle. Genau. Oder wie gesagt, du sagst halt, du willst das halt komplett selber bauen, weil es dafür gute Gründe gibt. Ja, dann kannst du das halt machen. Aber den Aufwand, den sollte man definitiv nicht unterschätzen. Ist ja ein neues Thema, aber hast du irgendeine Idee, wie viele Leute oder wie viele Anbieter in Deutschland Deutschland, sich damit überhaupt auseinandersetzen? Also ist das ein Thema, was eher in Google und Amerika existiert oder ist das was, wo wir hier auch relativ viel mitmachen? Weil im Moment habe ich noch nicht so hundertprozentig verstanden, wo die Vorteile sind. Viele Leute verstehen es vielleicht auch nicht. Ich glaube, du musst konkret in den Use Cases dann immer drin sein, um zu überlegen, wann macht man das? Und jetzt würde ich mich einfach quantitativ nähern und mal überlegen, gibt es eigentlich viele Leute, die bei uns Headless machen? Gibt es irgendwelche Leuchttürme, irgendwelche Shops, wo man sagt, das ist Headless, die machen das heute schon? Ehrlich gesagt, also die Projekte, die wir machen, sind jetzt nicht die Leuchttürme Deutschlands. Von daher kann ich das jetzt nicht unbedingt sagen aus der persönlichen Erfahrung. Aber, Du hast ja, wenn du dir zum Beispiel große Marken, glaube ich, da ist es schon die Regel, dass die Richtung Headless gehen. Also ich kenne es halt sozusagen aus Startups, die in dem Bereich E-Commerce, aber innovative E-Commerce-Sachen machen, die halt viel mit Online machen. Da ist, die merken schon deutlich, dass das ein Thema ist für fast alle. Dann hast du ja, wenn du dir halt die großen E-Commerce-Systeme der Neuzeit anguckst, so irgendwie Spriker ist da sicher ein Name, dann von Oboe2 gibt es da auch noch, weiß jetzt gar nicht, wie der Name ist. Die Systeme, die sind ja auch, da steht ja auch überall Headless dran. Also selbst auch beim Shopware steht halt Headless dran. Das heißt. Die bestehenden Systeme, die unterstützen auch den Headless-Modus sozusagen. Ja, genau. Also selbst ein Typo 3 Headless-Extension gibt es. Das ist ja aber auch komisch. Du hast ein System, was schon Frontend hat und das hat eine Headless-Extension. Allein der Name darüber kann ich mich aber ermähnen. Ja. Also das ist auf jeden Fall ein spannender Punkt im Detail, weil, also Headless ist halt jetzt nicht irgendwie ein Trend oder so, der morgen wieder weg ist oder so, sondern es ist schon so, dass die Welt Headless geht, früher oder später. haben. Es steht nach einem Pattern. Es ist halt wirklich, wie du sagst, architekturell. Ja, das ist ja der Witz, wenn du darüber nachdenkst. Ich habe ja schon seit Ewigkeiten halt nicht nur Webseiten, sondern Web-Anwendungen komplexester Art und so weiter gebaut. Das heißt, was machst du denn da? Du baust ja nicht eine Website und einen Backend-Server, sondern du hast ja immer tausende Server. Ich will jetzt nicht von Microsoft reden, aber du hast ja im Backend immer verschiedene Systeme, aus denen du eine Website baust, weil du halt eine App baust. Du baust ja eine Anwendung fürs Web. Und das ist eigentlich ja das, was so ein bisschen, wohin Headless geht. Also es ist ja nichts, es ist ja technisch nichts Neues. Es ist einfach, du hast eine Webseite, die hat halt im Backend verschiedene Services. Also es ist jetzt nur im E-Commerce-Bereich so, da ist es halt etwas völlig neuer Ansatz, weil man halt vorher nur mit monolithischen Systemen gearbeitet hat. So und eigentlich geht ja jetzt, sag mal, ein bisschen weiß ich nicht, einfach gesagt, ja der Trend, der, sagen wir mal, etwas sophistikäreren Entwicklung von Web-Anwendungen langsam zum E-Commerce. Also ich mache jetzt nicht nur irgendwie Front und Backend, das war's. Reicht nicht mehr. Reicht nicht mehr, ich mache jetzt halt mehr. Ja, von daher geht es dahin. Aber das Spannende ist halt, und das ist halt ein Punkt, den ich noch auch sehr interessant finde, ist, dass du schon merkst, dass es ein Unterschied ist. Hast du jetzt ein klassisches E-Commerce-System oder auch CMS, whatever, das jetzt auch Headless wird? Oder hast du eben die Newcomer, die halt von null auf komplett Headless gestartet sind und nur Headless sind? Wo unterscheidet sich das? Du kannst ja klassisch vorstellen, so jetzt zum Beispiel in Shopware oder in Typo3, ich bin kein Typo3-Experte, aber es ist ja leicht vorzustellen, du unterstützt ja beide Welten. Das heißt, wenn ich jetzt nur mir die Konfigurationsmöglichkeiten angucke, dann ist ja schon klar, ich habe immer Konfigurationsmöglichkeiten, die sowohl das klassische Template-Rendering unterstützen, als auch eben gegebenenfalls Auswirkungen auf das Headless haben. So, das ist das eine. Dann hast du so Sachen wie Dokumentation, hört sich trivial an, aber eine Doku für ein Headless-E-Commerce-System ist halt für Entwickler geschrieben, primär, also es gibt immer den Case Anwender fürs Admin-Backend und Entwickler. Aber ein Headless-E-Commerce-System hat eine Doku, die ist halt so geschrieben, dass der Fokus voll auf der API, Erweiterbarkeit und so weiter steht. Und bei einem klassischen System, das jetzt auch Headless macht, hast du auch da wieder beides. Das heißt, viele Sachen sind als Entwickler sehr, sehr schwierig in dieser Welt zu tun, weil du auch nichts findest. Weil natürlich auch ein Shopware zu 95% halt nicht Headless benutzt wird. So, das heißt, auch da ist es immer ein bisschen schwieriger. Und das andere, was theoretisch als Riesenvorteil halt natürlich auch irgendwie von so bestehenden Systemen, Elternsystemen gesehen wird, ist halt so die Plugin-Welt. Du hast ja Plugins für alles. Aber ganz ehrlich, wenn du Headless bist, dann beförderst du dich auch in eine Welt, wo du fast oder eigentlich gar kein Plugin brauchst, weil alles, was theoretisch ein Plugin wäre, machst du halt als... Deine Custom-Logik in einem eigenen Service beispielsweise. Und diese Plugins sind oft halt gar nicht dafür gebaut, dass die Headless funktionieren. Die gibt es zwar, die kannst du dann auch benutzen in deinem Mikro-System, aber da hat keiner darüber nachgedacht, gut, das muss auch Headless funktionieren. Ja, die Komplexität wird höher, weil du jetzt auf einmal sowohl Headless als auch nicht Headless in der Version oder der Version und dann multipliziert sich das ja wieder. Genau. Und da ist es auch egal, wie groß jetzt das Unternehmen dahinter ist oder so. Den Spagat kriegst du niemals so gut hin, wie jetzt ein System, das halt sagt, wir sind halt nur Headless. so. Die sind halt noch nicht so weit und da kann man überlegen, ist das eventuell irgendwie, hat das andere Risiken so, aber Wo. Glaubst du gehen die hin, die heute schon da sind, also diese Shopwares dieser Welt, würden die sich in den nächsten Versionen so entwickeln, dass sie quasi Headless werden und dann das, was sie anbieten als klassisches Interface, würden sie einfach draufsetzen, also dass dann quasi die APIs dieselben sind, die genutzt werden, dass sie eben Redundanzen einfach, abbauen in den nächsten Versionen oder glaubst du, es wird eigentlich immer immer dieses klassische monolithische geben und Headless ist dann halt ein Flavor, das ist was anderes. Kann ich natürlich nicht sagen, aber ein Beispiel, das Admin-Backend von einem Shopware ist schon quasi komplett Headless, in Anführungsstrichen gebaut, sondern das ist halt eine Vue.js-App sozusagen, die halt mit der API redet. Das heißt. Das ist ja schon nicht mehr... Das dachte ich mir nämlich auch, dass die es exakt so lösen. Genau, da ist es schon so. Im Frontend ist dann zu überlegen, ist dann eventuell der nächste Schritt, das so zu machen, dass dass irgendwann so ein Shopware halt zwar mit einer UI kommt, aber das ist dann halt auch sozusagen eine Headless-Frontend-App sozusagen. Da gibt es ja schon Sachen, die ja gebaut werden. Aber ja, das kann sein, dass das der Weg ist. Aber ich denke, das ist ein sehr, sehr weiter Weg dahin, um dann den Schnitt zu machen. Weil du hast ja, wie gesagt, also ich weiß es nicht, aber ich würde mal sagen, dass der Gro der Nutzer von diesem klassischen System, die halt auch noch klassisch nutzen. Ja, I don't know. Ich glaube, was, halt mehr Sinn macht, ist halt einfach, dass du mehr so komplett Frontend Libraries und Toolings hast, die wie zum View Storefront oder so. Also ich glaube, da wird es mehr geben, dass du halt für eine bestimmte Technologie, einfach komplette Frontends schon hast, die du nutzen kannst, um eben RAM abzuatmen, zu starten, aber dann dann komplett customizen kannst. Wahrscheinlich wird es so ein bisschen in die Richtung gehen. Könnte das so sein, wie damals bei, also als Bootstrap gerade rauskam, dann poppten ja auch überall die Stores auf mit und das ist jetzt hier das Bootstrap-Theme, das kannst du einfach verwenden, basiert irgendwie da drauf. Also dass man quasi auch sowas dann hat, dass du quasi dir irgendwo einen Marktplatz, einen Envato für ... Die Shopware-Frontends nehmen könntest? Oder ist es zu divers und du müsstest alles immer komplett anpassen? Ja, also es ist halt, du hast ja dann im Frontend so ein bisschen mehrere Ebenen. Du hast ja im Frontend dann die Technologiewahl. So React Next.js ist jetzt eine Technologiewahl fürs Frontend. So dann kannst du halt deine Komponenten und deinen Shop bauen mit der UI und so weiter. Aber dann hast du ja immer noch die Ebene, die Anbindung an dein konkretes E-Commerce-Backend-System. Genau. Und deswegen würde ich sagen, ist das eventuell von der Komplexität zu groß, als dass du so Envato-Style tausende von Themes einfach runterladen kannst, weil du brauchst ja schon eine richtige Entwicklermannschaft, um so ein komplettes E-Commerce vorne zu bauen. Und so, weißt du, es ist nicht so ein Technisch geht. Ist es eine doofe Idee. Ja, also es ist glaube ich eine sehr gute Idee, also so, das wird, hat auf jeden Fall krass, mit Sicherheit einen krassen Mehrwert, ich meine, wir bauen ja, oder ich baue so Sachen ja auch, viel, weil ich halt natürlich weiß, dass du schon natürlich einen Vorteil hast, wenn du sagst, du kannst halt komplett den Headless-Store bauen, aber du brauchst halt nicht zwei Jahre so, um überhaupt was zu haben, sondern bist halt relativ schnell dabei und kannst es aber dann hart customizen oder so. Das ist ja sicherlich schon sinnvoll. Wobei da jetzt immer die Frage, genau, wer macht das so? Sind das dann Unternehmen, die schon eigene Entwicklerteams haben, die jetzt irgendwie Headless-Schwand finden oder nicht? Ja. Ja, genau, das andere, was auf jeden Fall noch ein Ding ist, ein ganz interessanter Punkt, wo ich noch nicht sicher bin, ob das sinnvoll ist oder nicht, ist halt diese, du hast ja oft diese, weißt du, so Spryker oder diese großen Systeme, die halt so Headless und Composable sind und dann aber gleichzeitig alles aus einer Hand geben, so, weißt du. Da ist halt so ein bisschen so die Frage so was ist denn der Unterschied, ob ich jetzt meinen Vendor mir einen Monolithen gibt, der alles kann oder ob mir mein Vendor mir jetzt einfach einen Haufen Microservices gibt, mit dem ich dann alles machen kann so weißt du? Das ist halt so ein bisschen so, der spannende Part ist ja immer dann, wenn ich halt sage, ich hab halt, und da hast du dann halt den Vorteil, du bist halt vendoragnostisch irgendwo kannst dir aber bestimmte Services halt rauspicken und die dann so zusammenbauen, wie es halt Sinn macht. Ja, aber wer macht sich schon die Mühe? Für alles, was rausfällt. Aber das ist halt so ein bisschen, wo ich noch nicht so klar bin, ob das nicht eigentlich so ein bisschen den ganzen Zweck so ein bisschen absurd umführt. Also statt Monolithen kriege ich jetzt halt etwas Komplizierteres, aber alles ist aus einer Hand und eigentlich auch fest integriert und nicht wirklich einzeln nutzbar. Ja. Das hatte ich auch gerade mit diesem Marktplatzgedanken. Die Idee, die sich der entspannend war, ich hole mir jetzt dieses hyper-customizable System ins Haus, hole mir dann aber irgendwas anderes ins Haus, was mir quasi opinionated dann sagt, und so konfiguriere ich mein Backend und so konfiguriere ich das Frontend, damit ich, so Scaffolding, Boilerplate-artig schon starten kann mit irgendwas, aber dann kann ich mir auch irgendein anderes System holen, was erstmal funktioniert, also wenn es mir darum geht, ein schnelles Onboarding zu machen, dass ich schnell damit arbeiten kann und das alles da ist, ist das ein Quatschweg, aber wenn ich halt irgendeine Basis einfach nur haben will, wo ich was verändern möchte, der Vorteil scheint ja zu sein, ich muss viel customisen wollen, ich muss viel anpassen wollen an meine Bedürfnisse und es nochmal ein bisschen trimmen können. Und das widerspricht ja dem, der Kunde ist derjenige, der nicht viel Entwicklungsarbeit reinstecken möchte. Also dann hole ich mir kein explizit als anpassbares System ausgewiesenes Ding, sondern ich hole mir eins, was irgendwie ein bisschen Customizing, ein bisschen Lippenstift machen kann. Ja, das ist halt so der Punkt, man muss sich halt im Klaren darüber sein, nutze ich die Vorteile halt und ein klarer Indikator kann sein, dass du nicht nur ein digitales Geschäftsmodell hast, sondern du hast halt zum Beispiel zwei. Du hast halt zum Beispiel irgendwie Produkte, die du verkaufst und du hast Kurse, die du verkaufst oder du hast eben viel Content, aber auch Produkte, die du verkaufst. Weißt du so, in dem... Damit bin ich wieder bei dem zweiten Channel, der Vertreter, der vorbeikommt, die erzählt, guck mal, man kann auch richtig tolle Sachen machen, wenn man diese Pfanne kauft oder wenn man diese Sachen hat. Und auf einmal habe ich Content, der eben als Vehikel dient, die anderen Sachen zu verkaufen, die ich sonst alleine in den Shopping-Car packen muss. Genau. Oder du hast halt so, oder du hast halt irgendwie innovative Ransätze. Zum Beispiel ist es auch glaube ich spannend, auch für Startups oder so, weil ein Startup, das halt sehr innovative Sachen macht, baut ja in der Regel alles komplett selbst. So, das heißt, wenn jetzt so ein Startup irgendwie auch irgendwas verkaufen will, ich glaube, in der Regel sind die dann nicht so, dass sie sagen, dann nehme ich mir jetzt ein E-Commerce-System für diesen Bereich. In der Regel bauen die dann halt einfach, Produkt schnell als Schema in der Datenbank und das Ordering ist halt, das baut man dann so ein bisschen per IP selber, aber auch da zum Beispiel sehe ich unglaublich viel Potenzial, solche Systeme einfach fertig zu nutzen, selbst wenn ich nur wirklich einen kleinen Teil, weil ich eigentlich kein E-Commercler bin, ich brauche keine Coupons, ich brauche keine Kategorieseiten oder so, aber selbst wenn ich nur, Kunden mit Lieferadressen habe, warum auch immer, oder Rechnungsadressen oder so, den ganzen Kram, das ist ja, E-Commerce-Systemen machen ja sowas total gut, selbst da, glaube ich, ist es nicht schlecht, wenn ich mir einfach so ein Ding hinstelle, dann habe ich eine API und das binde ich dann halt ein. Also man kann schon viel damit machen, es gibt schon sehr viele sinnvolle Anwendungsfälle, aber wie gesagt, wenn ich jetzt als stationärer, Händler einen kleinen Laden habe und ich möchte auch online verkaufen, dann ist sicherlich irgendwie ein Shopify oder so, nicht die schlechtere Wahl, als zu sagen, ich mache das jetzt irgendwie wie Headless und bezahle, weiß ich nicht wie viel. Genau, um überhaupt irgendwas zu verkaufen. Also eigentlich dasselbe Dilemma wie immer. Es gibt keine klare Antwort. Es kommt darauf an. Und da muss man mal gucken, was sind die eigenen Bedürfnisse und wann nimmt man Headless, wann nimmt man nicht Headless. Du sagst aus Entwicklersicht, wenn man Spaß haben will, macht man Headless, richtig? Ja, auf jeden Fall. Also ich werde mit Sicherheit nicht ein WordPress-Theme jemals irgendwie in der Backend-Admin- Oberfläche das CSS anpassen. Das werde ich nicht tun. Das war Ein Geek kommt selten allein. Vielen Dank fürs Zuhören und großen Dank an dich, Manuel. Sehr gerne, hat mir sehr viel Spaß gemacht. Dann macht es gut, lasst ein Abo da und bis zur nächsten Folge. Wir hören uns.