Revision 566: Edge Computing mit SvelteKit und Cloudflare Pages

Transcript

[0:00] Die Idee vom Edge Computing ist tatsächlich gar nicht mehr so neu und kommt ursprünglich aus dem Bereich Smart Factories, wo tatsächlich in beispielsweise Fabriken, die automatisiert sind, wahnsinnig große Datenmengen anfallen, die in irgendeiner Form ja irgendwo berechnet werden müssen.
Ich glaube, das ist auch das, was Pages im Kern ist, eine Plattform für statische Webinhalte plus mittlerweile halt die Edge Functions und die damit verbundenen ganzen Worker-Möglichkeiten.
Aber was interessiert mich das als Webdeveloper, dass es Edge Computing gibt.

[0:31] Music.

[1:02] Diese Revision von Working Draft wird euch präsentiert von Midwald.
Midwald ist der Hoster für Agenturen und Freelancer.
Solltet ihr mehr als ein einzelnes Webprojekt zu betreuen haben, dann könnte Midwald euer Gamechanger sein.
Ich erinnere mich damit grausend an meine eigene Freelancer-Vergangenheit, als ich für 10 Kunden bei 20 verschiedenen Hostern mit 30 Logins zu jonglieren hatte.
Bei Midwald hingegen? Ein Login für alle Projekte.
Wahlweise für den besucherbasierten Agentur-Server oder den nerdig selbstkonfigurierten Space-Server.
Mit allen Features, die ihr euch nur wünschen könnt, vom Shop-System-Installer über SSL-Zertifikate bis hin zum ausgefuchsten Rechte- und Rollensystem.
Ihr wisst schon, für das Management eurer Projekte unter einem Dach.
CO2-neutral und DSGVO-konform. Und sollte es mal haken und ihr den Support anrufen, dann kriegt ihr echte Nerds ans Rohr.
24,7 an 365 Tagen im Jahr.
Das alles könnt ihr haben, wenn ihr auf mitwald.de slash workingdraft vorbeischaut.
Das schreibt sich m-i-t-t-w-a-l-d punkt d-e slash workingdraft.
Alle Infos zu mitwald findet ihr natürlich auch in den Shownotes zu dieser Revision.
Wir danken Mittwold für die Unterstützung von dieser Revision von Working Draft.

Revision 566: Edge Computing mit SvelteKit und Cloudflare Pages

https://workingdraft.de/566/

[2:14] Hallo beim Working Draft. Wir sind heute zu zweit. Zu einem bin ich dabei, die Vanessa, und wir haben einen Gast, den Nils Röhrig.
Und du warst auch schon mal bei uns in der Revision 511. Da haben wir noch über Microfrontends bei Gewehrdigital gesprochen.
Heute geht es um ein ganz anderes Thema, aber ich freue mich riesig, dass du wieder bei uns dabei bist.
Für alle, die die Revision 511 noch nicht gehört haben, möchtest du dich noch einmal für unsere Hörer und Hörerinnen vorstellen, Nils?
Ja, sehr gerne. Hallo zusammen. Ich freue mich auch, hier zu sein.
Und ja, wie Vanessa schon gesagt hat, mein Name ist Nils Röhrig und ich bin Software-Ingenieur bei der REWE Digital nach wie vor.
Hab damals über Microfrontends geredet und heute reden wir über Edge Computing und ich, ja, arbeite als Software-Ingenieur, wie schon gesagt, bin mehr oder weniger hauptsächlich im Frontend tätig, wobei es mittlerweile relativ variabel ist, wo gerade Erfordernisse sind.
Und ja, freue mich auf jeden Fall, hier zu sein und heute ein gutes Gespräch zu haben.

[3:11] Ja, schön, dass du da bist. Wir hatten auch schon eine, nennen wir das Vorgeplänkel, einfach mal ein professionelles Vorgespräch, die Vorbereitung, und haben auch schon mal über die guten alten schrecklichen Zeiten gesprochen, als wir noch im Internet Explorer die Extra-Layouts schreiben mussten, und sind auch dazu gekommen, dass du allerdings gar nicht mit den modernen Frameworks angefangen hattest, Sondern du kamst tatsächlich auch deine ersten Erfahrungen mit der PHP, JQuery aus dieser Zeit?
Ja, so kann man sagen. Also, ich bin seit mittlerweile gut 20 Jahren irgendwie web-interessiert und seit gut 15 Jahren mache ich das Ganze auch professionell.
Und damals waren andere Zeiten. Damals war JavaScript echt noch so ein Ding, das kam halt irgendwie hinten dran und man hat im Wesentlichen HTML gehabt im Kern, hat das mit CSS erweitert, Stichwort Progressive Enhancement war damals ein ganz großes Ding, ist ja auch heute wieder ein Thema, was häufig diskutiert wird.
Und diese ganze JavaScript-Geschichte hat tatsächlich bei mir erst so vor ungefähr sieben, acht Jahren angefangen, als es so ein bisschen sich gedreht hat.

[4:18] Wie würdest du denn jetzt eigentlich den Vergleich ziehen zwischen heutzutage ins Frontend einzusteigen und damals ins Frontend einzusteigen? Wenn du dich entscheiden könntest, würdest du wünschen, Und dass du heutzutage eingestiegen wärst, oder war das doch gut, dass du damals bei dieser verworrenen Spaghetti-HTML-CSS-Javascript-Zeit eingestiegen bist?
Das ist eine Frage, die hat im Prinzip zwei Antworten, weil ich glaube, beide Zeitpunkte sind in irgendeiner Form lehrreich und relevant, weil früher war es halt tatsächlich mehr noch ein bisschen Anarchie, ein bisschen Wilder West.
Man war noch nicht durchprofessionalisiert, es war noch eine sehr klare Community, die quasi das Open Web im Herzen trug und die ganze Professionalisierung, die ganze, Industrialisierung, sage ich mal, das Web hat sich erst danach so entwickelt. und, Heutzutage hat man halt den Vorteil, man hat eine ganz große Platte an Tools und man hat ganz viele Frameworks, mit denen man arbeiten kann, super spannendes Zeug, macht wahnsinnig viel Spaß.
Nachteil ist natürlich, man hat wahnsinnig große, eine wahnsinnig hohe Lernkurve.
Also, es ist wahnsinnig viel, was man lernen kann mittlerweile, und viele glauben auch, dass man es lernen muss.
Ich glaube, die Zeiten damals waren simpler, weil man halt einfach eine HTML-Seite geschrieben hat, man hat CSS draufgemacht, dann hat man das auf dem Webserver hochgeladen und hat eine Website.
Das funktioniert heute auch noch, aber in der Regel passiert das ja nicht mehr so.

[5:42] Ja, ich weiß auch. Ja, stimmt, es funktioniert heute auch noch, aber es ist, glaube ich, auch gar nicht mehr das Erste, was man sich googeln oder heutzutage chat-shippetieren kann.
Ich weiß tatsächlich noch, dass ich, oder von mir aus, ja Hut habe, wie denn jetzt eigentlich so alles funktioniert, und da waren halt die ersten Antworten, okay, da gibt's halt so Web-Posting-Systeme, und da gibt's sowas, das heißt FTP-Client, und es gibt irgendwas, das heißt Secure, da ist es SFTP, und da kann man die HTML-Dateien hochladen und tatsächlich so rüberschieben, und dann konntest du das im Browser anschauen.
Und das war halt eins zu eins das Gleiche.
Und das fand ich tatsächlich schon irgendwie noch einen Vorteil von dieser simpleren Zeit.
Es war bestimmt kompliziert, so manche Bereiche davon, aber ich wusste immer, was passiert, weil ich hab ja tatsächlich die gleiche HTML-Datei, die ich hier auf meinem lokalen Rechner hatte, in sozusagen eine Cloud oder auf eine andere Webserver geschoben und dann war sie halt im Web, aber das war ja immer noch die gleiche HTML-Datei.
Und jetzt haben wir ja immer so einen Build-Step dazwischen, wo ja auch diese ganzen Frameworks jetzt zu Hilfe kommen, damit das dann alles wegabstrachiert wird und wir uns nicht mehr drum kümmern müssen.

[6:56] Ich find aber auch spannend, ich find es super spannend, aber nicht im negativen Sinne.
Ich find es super spannend, wenn Leute erst heute mit dem Programmieren im Frontend anfangen, wie das für sie sein muss.
Ich bin da eigentlich total interessiert dran.
Wenn man diese, und man nennt es immer Grundlagen. Ich weiß gar nicht, ob jetzt wirklich JQuery sozusagen die Grundlage sein muss.
Aber wie geht man dann mit Bugs um? Oder weiß, kann man, wenn man heutzutage jetzt so ein Framework lernt, kann man noch unterscheiden, was davon ist das Framework und was davon sind zum Beispiel Browser APIs.
So, wenn jetzt irgendwie bei NUXT weiß ich zum Beispiel, dass NUXT irgendwelche besonderen, besondere Syntax hat, dass die Links auch geprefetcht werden.
Was nett sein kann für bestimmte Themenbereiche, wenn man vielleicht Blogartikel liest und man kann davon ausgehen, der User möchte auch den nächsten Blogartikel noch lesen, wir laden das schon mal vor.

[7:58] Aber weiß man dann heutzutage noch, dass das eigentlich der HTML-Link-Prefetch ist, den es schon immer gab, und da ist halt nur ein Rapport drumrum?
Ja, das ist eine gute Frage. Ich glaube, die Unterscheidbarkeit der Dinge ist heute etwas schwieriger, weil es einfach so wahnsinnig viel gibt.
Und wenn man einen Blick drauf wirft, wie Leute heute in die Industrie kommen, viel läuft ja über Bootcamps auch, und in Bootcamps, Aus gutem Grund, kurz und kompakt, wird in wenigen Monaten irgendein Stack geleert, mit dem man starten kann.

[8:26] Ich glaube aber, das geht natürlich auf Kosten der Grundlagen.
Ich denke, man kann sich die aneignen, wenn man das passende Umfeld hat und die Motivation dazu.
Und ich glaube, man sollte das über die Zeit auch tun, einfach um ein bisschen mehr Verständnis dafür zu entwickeln, was liegt da drunter, um eben genau so was zu wissen, dass das eben bloß ein Wrapperum etwas ist, was es eh schon immer gab und was jetzt nicht speziell vom Framework dazu gekommen ist, sondern dass es etwas ist, was man prinzipiell auch an einer anderen Stelle einsetzen kann, wo man jetzt vielleicht nicht in diesem Framework-Kontext ist.
Grundsätzlich glaube ich, dass...

[8:57] Die Zeiten heute sehr, sehr gut sind, um einzusteigen, aber man darf sich auf jeden Fall auf eine ziemlich, ziemlich einen Berg von Sachen gefasst machen, die man lernen kann.
Und man sollte sorgsam wählen, wo man anfängt und nicht versuchen, alles auf einmal zu lernen.
Das war früher einfacher. Früher hatte man HTML und CSS und musste vielleicht noch ein bisschen, wie du sagst, FTP lernen und sich einen Free-Web-Poster suchen.
Dann hat das funktioniert. Stimmt, das war die größte Aufgabe dafür.
Genau, die guten Free-Web-Poster, am besten noch mit PHP-Support, wenn man Glück hatte.
Auch das heute nicht mehr so eine große Nummer, wenn man überlegt, mit Resell, mit Netlify, mit Cloudflare, man hat Angebote, die Webhosting sehr, sehr simpel und sehr einfach zugänglich machen.
Also viel hat sich verbessert, aber es ist einfach wahnsinnig viel dazugekommen, und es ist weit umfassender, was man da wissen kann und lernen kann, als das, was wir früher vor uns hatten.

[9:51] Ja, und jetzt hast du gerade schon ein wichtiges Stichwort genannt, denn heute hast du uns ja das Thema mitgebracht, Edge Computing mit SvelteKit und Cloudflare Pages.
Da sind jetzt drei Sachen drin, Edge Computing, SvelteKit, Cloudflare Pages.
Womit fangen wir denn an?
Fangen wir mit der Edge Computing an?
Ich glaube, das ist wahrscheinlich der beste Einstieg, weil, ehrlich gesagt, Edge Computing ist quasi das große Thema Und Swaget Kit und Cloud Fab Pages sind in diesem Fall wie lediglich Mittel zum Zweck.
Deswegen lass uns gerne mit Edge Computing anfangen.

[10:27] Ja, dann frage ich gleich heraus, wie würdest du mir denn erklären, was ist Edge Computing?
Also, ich würde es so erklären, und ich mache mir da vielleicht so ein bisschen Informationen zu Nutze, die ich natürlich auch nicht selber generiert habe, sondern die ich irgendwo gelesen habe, aber im Prinzip ist Edge Computing eine Form des Cloud Computings, wenn man so will, aber während klassisches, traditionelles Cloud Computing irgendwo an einem Standort liegt und dort alle Berechnungen ausgeführt werden, ist beim Edge Computing so, dass es zwischen dem Zentrum, also der Cloud sozusagen, und dem lokalen Gerät verschiedene Orte gibt, an denen Berechnungen stattfinden können.
Und das ist halt, das beste Beispiel, was man da bringen kann, ist, glaube ich, einfach CDN. Das ist etwas, was schon sehr ...

[11:14] Verbreitet ist, die meisten benutzen es, und die meisten sollten es wahrscheinlich auch benutzen, das macht wahrscheinlich Sinn, und das ist eigentlich schon eine Art von Edge Computing, wenn man so will, spätestens wenn im CDN Berechnungen durchgeführt werden.
Wenn man jetzt als Beispiel nimmt, ich habe ein Bild, was ich irgendwo im CDN liegen habe, und ich möchte dieses Bild in einem anderen Format haben, ich möchte eine andere Auflösung haben, viele von diesen Tools bieten mir dann die Möglichkeit zu sagen, okay, schick mir mal ein paar Query-Parameter mit, und sag mir mal, was du jetzt von mir haben willst.
Ich kann da alles daraus generieren. Und diese Berechnungen werden ja üblicherweise nicht voraus ausgeführt, sondern erst on demand einmalig und dann gecached.

[11:54] Und dieses on demand Ausführen, dieses Berechnen des neuen Bildes ist ja im Wesentlichen schon eine Art von Computing, eine Art von Berechnungen.
Und so kann man sich das im Prinzip vorstellen. In dem Fall vom CDN ist es dann, ja, vielleicht muss ich da ein bisschen weiter ausholen, wenn man ein Modell sich zugrunde nimmt von Red Hat, dann kann man sich das Edge Computing so ein bisschen vorstellen wie so ein Kreismodell.
Man hat im Kern, wie gesagt, die Cloud, und um die Cloud ist dann quasi die sogenannte Service Provider Edge, das ist quasi der Übergang von meiner internen Cloud-Umgebung, von meinem internen Rechenzentrum, was auch immer, rüber ins weitere Internet.
Nachdem man von dieser Service Provider Edge durch das weitere Internet quasi den Datenstrom verschoben hat, dann kommt man zu diesem sogenannten End-User-Premises-Edge.
Und diese End-User-Premises-Edge ist quasi die Netzwerkschicht, die dort liegt, wo es vom weiteren Internet in meine internen Umgebungen geht.
Das kann zum Beispiel sein eine Fabrik, das kann zum Beispiel ein Laden sein, das kann irgendwie der Zugang zu einem bestimmten Büro sein, und da kann man auch Berechnungen ausführen.
Und zu guter Letzt gibt es noch eine weitere Edge, eine sogenannte Device-Edge, und dort geht es dann tatsächlich vom...

[13:09] Von inneren Kern an meinen spezifischen Standorten über in mein Endgerät und an all diesen Stellen kann man im Prinzip Berechnungen durchführen.
Und stellt sich natürlich die Frage, warum möchte man das tun? Das klingt ja jetzt erstmal irgendwie relativ komplex und aufwendig.
Ich kann die Berechnungen auch einfach in der Mitte machen, aber die Idee vom Edge Computing ist tatsächlich gar nicht mehr so neu neu und kommt ursprünglich aus dem Bereich Smart Factories, wo tatsächlich in beispielsweise Fabriken, die automatisiert sind, wahnsinnig große Datenmengen anfallen, die in irgendeiner Form ja irgendwo berechnet werden müssen. Und bevor dann diese riesigen Datenmengen, die durch Sensoren überall in der Fabrik permanent erfasst werden, verschoben werden über das Netzwerk irgendwo in der Cloud, hat man gedacht, okay, wieso machen wir nicht schon Berechnungen an der Stelle, wo diese Daten anfallen quasi, also quasi an der Kante, bevor es ins Netzwerk geht, dann schon vor Ort in der Fabrik irgendwie Vorberechnungen machen, Daten aggregieren und dann noch ein Aggregat von Daten rauszuschicken und in die Cloud zu schicken.
Das ist so ein bisschen der Hintergrund des Ganzen. Also, ich möchte die Berechnungen, die ich ausführen möchte, möglichst nah dort ausführen, wo sie irgendwie Sinn ergeben.
Und das ist in der Smart Factory beispielsweise an dieser End-User-Premises-Edge, von der ich eben sprach.

[14:30] Was habe ich denn jetzt alles für Vorteile als Nutzer? Geht es dann auch schneller? Hat es weniger Kilobyte?
Also als Benutzer erstmal ist es für mich idealerweise, wenn alles gut läuft und das ist das Versprechen, was dahinter steckt, dann wird ja eine Berechnung irgendwie nicht mehr in Kalifornien durchgeführt, sondern vielleicht am Netzwerknoten in Düsseldorf.
Und das heißt, meine Daten müssen nicht mehr einmal um die ganze Welt, sondern können direkt in Düsseldorf verarbeitet werden, und alles, was dort berechnet werden kann, wird dort berechnet und wird unmittelbar zu mir zurückgeschickt.
Und das ist so das große Versprechen.

[15:07] Ich glaube, was vielleicht jetzt schon ein bisschen deutlich geworden ist, ist, dass bei Edge Computing nicht eine konkrete Technologie irgendwie der Schlüssel ist, sondern dass es sich eher um eine Netzwerk- oder eine Architekturphilosophie handelt, wie man seine Daten reguliert, wo man Berechnungen durchführt, und weniger jetzt eine konkrete Technologie bezeichnet.
Ja. Geht es dann, weil es war gerade von Kalifornien, Düsseldorf, die Rede, das ist ja international.
Kann man Edge Computing auch im kleineren Bereich haben, dass ich sage, das ist maximal auf Europa ausgeweitet, oder sogar maximal auf Deutschland?
Also, ich würde vermuten, dass das wahrscheinlich stark vom Anbieter abhängt, und möglicherweise von Konfigurationsoptionen, Aber ich glaube, wenn man das Prinzip halt komplett überlegt, dann möchte man die Sachen möglichst nah beim Nutzer haben und dann auch möglichst international.
Und ich glaube, wenn man jetzt mit Cloudflare das Ganze handelt, nun ist Cloudflare ein großes Produkt.
Das heißt, das kann eine ganze Menge. Und die ganzen Details kenne ich ja auch nicht, aber möglicherweise könnte ich mir vorstellen, dass man sagt, okay, ich möchte das nur in einem beschränkten geografischen Rahmen ausrollen.
Aber dann stellt sich wieder die Frage, okay, ist das dann überhaupt das richtige Tool, Wenn ich ohnehin meine Berechnungen in Frankfurt habe und nur bis Berlin gehe oder bis München, dann muss man sich, glaube ich, die Frage stellen, ob das Tool dann das richtige ist an der Stelle.

[16:25] Ja, woher meine Frage kommt, die hängt zusammen mit jetzt zum Beispiel GDBA und wo werden eigentlich Daten gespeichert.
Jetzt ist allerdings die Frage, du hattest vorher das gute Beispiel mit Bildern und dass zum Beispiel das Tool mir dann die Bilder in einem anderen Format berechnen kann.

[16:44] Wäre das jetzt eigentlich ein Problem, wenn ich die Bilddaten von Nutzer und Nutzerinnen irgendwo in Europa gespeichert habe, wo eigentlich alles okay ist.
Aber ich möchte ein zusätzliches Tool benutzen, wo ich dann die, ja, diesen kleinen Helferlein benutzen kann, dass ich mir das Bild nicht schon vorher abspeichern muss in der richtigen Größe und richtigen PNG und da, da, da, sondern on demand sagen kann, oh, jetzt brauche ich das gerade schwarz-weiß.
Und das ist aber ein Tool aus Amerika. Wäre das dann ein Problem für die Daten?
Werden die da verarbeitet und gespeichert? oder kriegt eigentlich das Tool recht wenig von den Daten mit?
Also, natürlich werden die Daten dann dort bearbeitet oder verarbeitet, wo man dann in der Nähe vom Nutzer ist. Das ist ja die ganze Idee.
Also, wenn ich halt sage, ich bin in Kalifornien und möchte ein Bild aus Deutschland, dort irgendwie in mir anzeigen lassen, das aber irgendwie in einem anderen Format haben, dann werden die üblicherweise natürlich dort vor Ort verarbeitet und dann gecached für weitere Benutzung.
Da hast du natürlich einen guten Punkt angesprochen. Datenschutzrechtlich gelten da natürlich die gleichen Regeln wie sonst auch.
Also, wenn man halt Daten verarbeiten möchte an Orten, die jetzt außerhalb der europäischen Jurisdiktion liegen, dann wird man da auf jeden Fall Verträge abschließen müssen mit den entsprechenden Anbietern, dass die quasi gewährleisten, dass dort die Datenschutzvorschriften, die für uns gelten, in irgendeiner Form auch weiter Bestand haben.

[18:11] Okay. Aber klingt so, als gäbe es da Überlegungen, was man dann machen kann, Verträge?
Wie gesagt, ich habe es jetzt nicht im Detail untersucht, aber die Regeln, die es gibt, die gelten ja natürlich dort auch.
Und ich könnte mir vorstellen, wenn jetzt ein internationaler Player am Start ist, die wollen ja überall Geschäfte machen.
Die meisten werden sich mit dem Thema GDPR schon mal beschäftigt haben.

[18:32] Ja, wahrscheinlich. Jetzt hätte ich als nächstes die Frage, das klingt ja von der Theorie her, klingt das ja alles ganz super, aber was interessiert mich das als Webdeveloper, dass es Edge Computing gibt?

[18:46] Ja, also für mich als Webdeveloper, ich meine, im Wesentlichen den Punkt haben wir ja schon angesprochen, die Performance beim End-User ist für mich als Webdeveloper wahrscheinlich am interessantesten, wenn das Versprechen eingehalten wird. Wir haben da vorhin davon gesprochen, dass es diese Service Provider Edge gibt, und das ist im Wesentlichen auch der Netzwerkkreis, der für uns als Web-Developer am interessantesten ist, weil das ist im Prinzip genau da, wo halt jetzt auch schon CDNs und so durchgeführt werden, und im Idealfall, wie gesagt, werden Berechnungen und komplizierte Dinge, die irgendwie vor Ort ausgeführt werden können, nicht einmal um die Welt geschickt, sondern vor Ort einfach ausgeführt, und das ist natürlich Etwas, was für mich als Web-Entwickler interessant ist, dass ich den Lutzern vor Ort irgendwie die bestmögliche Performance bieten kann.

[19:35] Dazu kommt noch, dass natürlich das Tooling, was damit einhergeht, es mir als Web-Entwickler extrem leicht macht, Sachen über den Globus verteilt abzulegen.
Das ist vielleicht auch etwas, was man durchaus nennen kann, weil wenn man sich klassische Cloud-Anbieter anguckt, wie zum Beispiel, ich meine AWS kenne ich nicht so gut, aber ich meine, da wäre es genauso bei Google Cloud Functions zum Beispiel, ist es so, die sind immer an eine bestimmte Region geknüpft.
Und für mich als Webdeveloper ist das okay, solange ich nur in dieser Region aktiv sein will, aber wenn ich halt irgendwo anders aktiv werden will, dann ist das vielleicht ein bisschen zu wenig, oder ich muss es mehrfach in verschiedenen Regionen ausruhen, da muss ich mir selber überlegen, wie kann ich diese Sachen irgendwie so routen, dass Traffic aus den USA nur dort landet, und Traffic aus Europa nur hier landet.

[20:17] Und bei den Edge-Computer-Anbietern habe ich das Problem natürlich nicht, weil die haben halt genau dieses globale Netzwerk schon aufgebaut, meistens ursprünglich mal als CDN, und dort kann ich dann diese Berechnungen ausführen, und es wird mir als Entwickler sehr leicht gemacht, das zu tun.
Natürlich muss man immer die Constraints berücksichtigen, man hat ein Vendor-Login, das darf man nicht vergessen, man ist irgendwie dann an den Anbieter gebunden, man hat definitiv Datenschutzüberlegungen, die man irgendwie berücksichtigen muss, aber das Value Proposal für mich als insbesondere Frontend-Developer ist schon immens, weil ich muss mich um relativ wenig Infrastrukturarbeit selber kümmern.
Wann wäre denn für Dich der Moment, damit anzufangen bei einem Projekt?

[21:02] Also ich glaube, sobald man interkontinental tätig wird, kann das eine Option sein.
Ich glaube, solange man sich auf Europa beschränkt, bringt das relativ wenig, weil dann hat man ja ohnehin die zentralisierten Datenzentren, die man dann irgendwie relativ leicht erreichen kann.
Aber ich denke, wenn wir jetzt sagen, ja, okay, wir sind aus Europa, wir wollen irgendwie Geschäfte machen in Asien, wir wollen Geschäfte machen in Afrika, wir wollen Geschäfte machen in den Staaten oder in Südamerika, dann kann sich das schon anbieten und eine Überlegung sein, dass man dann den Nutzern vor Ort, also im Kern haben wir mal unsere Kernangelegenheiten, haben wir immer noch irgendwie hier in Europa, aber alles, was wir irgendwie auslagern können, alles, was wir irgendwie an Berechnungen an die entsprechenden Orte schicken können, können wir dann über das Edge-Netzwerk verteilen und den Leuten vor Ort direkt zugänglich machen.

[21:45] Das klingt zwar alles sehr überzeugend, und ich glaube, falls ich das jemals bräuchte, ich glaube, ich würde dich gerne einfach gerne mieten und sagen, wiederhole mal, was du gesagt hast, wie den Podcast vor. Aber jetzt stelle ich mir noch die Situation vor, Moment, das wird ja, solche Services werden ja vermutlich ein bisschen was kosten.
Ich glaube, groß skaliert schon. Allerdings, und für mich ist das Thema ja, ich habe ja für die Recherche auch eine kleine Applikation gebaut und die quasi die Cloudflare-Umgebung betreut und ich bezahle dafür tatsächlich keinen Cent, weil ich halt mit den Tools, die ich verwende, mit den Features, die ich verwende, immer noch in so einem Free-Tier bleibe. Der ist natürlich so beschränkt, dass man damit keine ernsthaften Geschäfte machen kann, wenn man jetzt etwas anderes macht, als bloß statische Webseiten ausliefern, hat man auf jeden Fall ein Limit, womit man kalkulieren muss, aber ich denke, die Preise werden, wie bei anderen Cloud-Anbietern, einfach auch mit der Nutzung skalieren.
Das ist nicht anders, als jetzt bei Google Cloud zum Beispiel auch, oder AWS auch, man wird immer ein bisschen ein Auge drauf haben müssen, okay, ist die Ressourcen, die ich jetzt gerade brauche, sind die noch irgendwie im Rahmen, was kostet der Spaß?
Aber für den Start kann man tatsächlich relativ Also preisgünstig starten, wenn man ein bisschen weiterführende Features haben möchte.

[23:00] Ja, ist jetzt ein anderes Thema, aber das finde ich tatsächlich auch selber als Webentwicklerin immer super hilfreich, weil ich auch meistens einfach teilweise nur mal ein Login brauche, mein irgendein Pseudo-Dingens-Bummens-Projekt da hochladen will, damit ich mal die UX davon sehe und eigentlich verstehe, was das eigentlich tut.

[23:17] Aber jetzt frage ich mich, es ist vielleicht so ein Ticken mit Kosten verbunden, aber vielleicht sind die Kosten, würde ich jetzt mal schätzen, vielleicht gar nicht wirklich der große Faktor.
Und obwohl du meintest, dass dir verschiedene Tools und vor allem jetzt hier Cloudflare als Beispiel viel Arbeit abnehmen und sehr hilfreich sind, ist es ja vielleicht trotzdem was, wo man befürchten könnte, vielleicht ist es doch eine Art Maintenance, vielleicht wird das schwierig, wir müssen da so einen Vertrag aufsetzen, was ist, wenn sich da mal was ändert?
Wie würdest du denn, kann man messen, dass man das braucht, oder wie würde man das am besten messen, dass man zum Beispiel langsam ist in Afrika? Das ist eine sehr, sehr gute Frage.
Habe ich auch keine Antwort für tatsächlich. Also, soweit habe ich mich tatsächlich nicht in diese Thematik vorgewagt.
Für mich war es einfach vor allem ein sehr spannendes Feld, wo ich sagte, ich möchte mir das mal anschauen.
Aber tatsächlich so wirklich große globale Produktiverfahrung habe ich damit auch nicht.
Deswegen, ja, wie könnte man das in Afrika messen?
Ja, wahrscheinlich müsste man dann auf den Devices selber irgendwie Analytics-Tools haben, die in irgendeiner Form Response-Zeiten messen und sowas, die mir dann Ausschluss darüber geben, okay, hey, der Request auf dem Device da in Nigeria, der hat gerade irgendwie drei Sekunden gedauert, das ist zu lang, wo ist denn der hingegangen? Oh, der ist nach Europa gegangen.
Können wir das vielleicht beschleunigen, indem wir das oder ein Großteil dieser Berechnung vielleicht irgendwie dann in Datenknoten in Nigeria verlagern oder so.

[24:45] Rein spekulativ, aber so könnte ich mir vorstellen, kann man das wahrscheinlich verfolgen, also ähnlich wie man das in anderen Situationen auch machen würde.

[24:52] Ja, dann haben wir hier auch gleich den Aufruf für alle Hörer und Hörerinnen.
Falls ihr euch damit auskennt, wie man am besten messen kann, wie performant eigentlich die Seite auf der anderen Seite der Erdkugel ist, dann sagt gerne mal Bescheid.
Würde mich jetzt gerade interessieren. Finde ich auch sehr spannend, ja.

[25:11] Und das nächste spannende Thema wäre dann, wie kommt jetzt das Weltkit zu Edge Computing?
Was hat das eine mit dem anderen zu tun? Edge Computing, theoretisches Konzept von Architektur, und SvelteKit ist also ein modernes Framework.
Genau, richtig. Also prinzipiell hat SvelteKit mit Edge Computing erst mal für sich genommen natürlich relativ wenig zu tun.
Es ist einfach ein JavaScript-Framework, was, wie der Name schon sagt, quasi die Erweiterung von Svelte ist und ja, das für Svelte anbietet, was Next.js für React oder Next.js für Vue anbietet.
So ungefähr kann man sich das vorstellen, den Scope von diesem Projekt.
Aber warum das in diesem Kontext so spannend ist, ist, dass Welt von Haus aus halt eine gewisse Plattformunabhängigkeit mit sich bringt.
Was meine ich damit? Also wir haben ja eben darüber gesprochen, dass ich natürlich, habe ich ja vorher gesagt, vor allem Cloudflare irgendwie ausprobiert habe, aber diese Angebote, Edge Computing zu machen und diese Plattformen zu nutzen, gibt es halt auch an anderen Orten.
Es gibt Vercel, es gibt Netlify, haben wir vielleicht heute auch schon mal erwähnt, Die bieten auch ähnliche Lösungen an, ähnliche Funktionen an.
Und SvelteKit hat ja im Kern wesentlich einen Compiler. Das heißt.

[26:26] Man baut seine App ins Welt und ins Weltkit-Funktionalitäten, dann schiebt man die einmal durch den Compiler durch und hinten raus kommt eine neue App.
Und die kann dann tatsächlich auch über etwas, was sich Adapter nennt.

[26:36] Plattformspezifisch angepasst sein.
Und das Weltkit von sich aus tatsächlich, wenn man nichts selber konfiguriert, dann hat das Weltkit tatsächlich schon Support für eben die drei genannten Cloudflare, Divershell und Netlify out of the box. Das heißt, wie kann man sich das vorstellen, wie funktioniert das?
Dieser Adapter nimmt im Wesentlichen den Output von einem Svelte-Kompilat und passt ihn so an, dass er auf dieser spezifischen Plattform ausführbar ist.
Und SvelteKit kommt von Hause aus mit einem Tool, mit einem Adapter.
Das ist der Adapter-Auto, nennt sich das. Und dieser Adapter, wenn man quasi die SvelteKit-App baut, SvelteKit-Compiler, man braucht auf jeden Fall einen Buildstep, ohne geht es nicht.
Und je nachdem, wo dieser Buildstep ausgeführt wird, wird halt geprüft, okay, bin ich jetzt gerade irgendwie auf Vercel, bin ich auf Netlify, bin ich auf Cloudflare, und ich muss also als Entwickler gar nicht explizit konfigurieren für diese drei Plattformen.
Deswegen ist das auf jeden Fall ein attraktives Tool, um einfach damit einzusteigen, um diese Plattformen zu nutzen, ohne dass ich mich jetzt mit den Spezifika beschäftigen muss.
Und das ist im Wesentlichen da, wo es dann so ein bisschen zusammengeführt wird.
Mehr, da habe ich ja einleitend schon gesagt, mehr Mittel zum Zweck, als jetzt irgendwie komplett an diese Philosophie gebunden, Weil SvelteKit kann man halt auch ganz normal als Node-App oder irgendwie anders einsetzen.

[27:58] Je nachdem welcher Adapter es gibt.
Ich muss jetzt alles noch mal ganz in der Reihe nachfragen. Mhm.
Wenn ich jetzt mal annehmen würde, man kennt diese Begriffe gar nicht.
Und bei mir, ich hab auch mit Svelte gearbeitet und damals mit Zappa oder Zeppa.
Mhm. Und du meintest auch grade schon, Svelte-Kit ist so was wie Next oder Next für Vue oder React.
Das heißt, das eine, was ich sehe, das hat so Routing mit drin, Client-Side-Routing.
Und auch Server-Side-Rendering dabei dann?
Genau, richtig. Also, das volle Programm, was man so erwarten würde, oder was ich zumindest erwarten würde, man hat ein Routing integriert, muss sich nicht selber darum kümmern, das ist ein File-System-based Routing, wie es bei anderen Tools auch der Fall ist.
Man hat Server-Side-Rendering relativ einfach konfigurierbar auf Seitenebene, also man kann Seiten pre-rendern, oder man kann sie Server-Side rendern, oder man kann sie komplett klein-seitig rendern.
Das kann man pro Seite gezielt besprechen, oder gezielt diskutieren.
Wirklich auf Component-Ebene, so wie es Astro zum Beispiel macht, da ist es noch nicht, aber vielleicht kommt das in der Zukunft noch, ich würde mich nicht überraschen, wenn das noch passieren wird, aber für diesen Fall kann man halt tatsächlich, ja.

[29:10] Man hat halt ziemlich viele Opinions, mit denen man erst mal arbeiten muss, natürlich, weil alle diese Frameworks sind im Kern opinionated, und das Weltbild hat halt auch seinen konkreten Weg, wie Daten zum Beispiel geladen werden.
Wenn man jetzt sagt, okay, ich habe eine Seite, und ich brauche auf dieser Seite irgendwie Daten, dann muss man sich vor Augen führen, dass die Seite, die ins Svelte geht, immer aus, einer oder mehreren Dateien besteht, und das ist zum einen mal die Page.svelte, mit einem Plus-Gepräfix, ganz wichtig, aber das kann man in der Dokumentation nachlesen, die Details, ich glaube, auf der Tonspur kommen die nicht so gut an.
Auf jeden Fall gibt es dann die Svelte-Datei, die eine Seite repräsentiert, und das ist eine Svelte-Komponente, die im Wesentlichen das Markup und so ein bisschen den State, das Verhalten von der Seite definiert.
Und dann gibt es neben dieser Svelte-Datei noch die Möglichkeit, eine ja, Server.js zu machen, wo man dann halt tatsächlich, ja, also Page.server.js, wo man tatsächlich, Berechnungen ausführen kann, die exklusiv auf Server-Seite stattfinden sollen.
Also man kann das sehr granular entscheiden, wo bestimmte Dinge stattfinden.
Also wenn ich jetzt sage, ich habe irgendwelche Secrets, die möchte ich auf gar keinen Fall in meinem Client haben, dann packe ich die in diese Server-Datei rein, und die wird auch ausschließlich im Server-Bundle dann.

[30:24] Verarbeitet. Die wird nicht in den Client-Bundle reingepackt und kommt niemals im Client an.
Sehr hilfreich für zum Beispiel so etwas wie Secrets. Es gibt analog dazu auch noch eine Page.js, ohne das Server, und diese Datenlade-Logik, die da drinnen liegt, die wird ausgeführt, sowohl auf dem Server, als auch im Client, oder auch nur im Client, wenn man halt eine Client-Site-Only-Seite hat an der Stelle.
Und so kann man relativ granular einstellen, zu welchem Zeitpunkt und wo bestimmte Daten geladen werden.
Und diese Daten kommen dann quasi über einen Weg, den man aus den Komponenten von anderen Frameworks kennt, Props gibt's in Svelte, wie in React auch, oder gibt's in Vue auch.
Über diesen Weg werden die da halt quasi vom Framework aus diesen Loader-Funktionen in die Seite injiziert, weil die Seite selber ist nichts weiter als eine Svelte-Komponente.

[31:11] Das ist jetzt eine schöne Kurve zu der Thematik, die wir am Anfang hatten.
Heutzutage gibt's einfach eine größere Learning-Kurve wahrscheinlich. Absolut, ja.
Alles, was du sagst, ich konnte dir folgen, weil ich glücklicherweise zumindest mal mit NUXTS.js gearbeitet hatte.
Und ich wusste, okay, Filebase, wahrscheinlich gibt es so einen Ordner, der heißt Pages.
Und wenn ich da diese Weltkomponente reinlege, dann wird da einfach so magisch eine Route auch draus.
Ich glaube, das fand ich am Anfang auch bei NUXTS.js so toll, dass ich da nicht mehr den Router selber schreiben musste. Ganz toll.
Aber natürlich, wenn man ja jetzt noch gar nichts damit am Hut hatte.
Und also, Filebase, okay, der Ordner.
Und Properties, und ja, und Loader, okay, und das Client-Site, und das Server-Site.

[31:53] Das stimmt, es ist auf jeden Fall relativ viel, was man da lernen kann.
Das stimmt schon. Ich muss aber tatsächlich auch sagen, ich fand den Zugang dazu relativ einfach zu finden, gerade wenn man irgendwie mit der Gedankenwelt rankommt und sagt, hey, meine HTML-Seiten liegen irgendwie im Dateisystem, Und das Verteilsystem spiegelt schon die Struktur meiner Applikation, die dann später auch beim Nutzer ankommt, wieder.
Damit ist schon viel gewonnen.
Na klar, man muss dann die ganzen Daten-Ladethematiken und sowas, die jetzt für das Framework spezifisch sind, auch noch irgendwie lernen.
Aber selbst das fand ich, wie gesagt, auf der Tonspur lässt sich sowas immer sehr schwer rüberbringen, gerade wenn man vielleicht Leute adressiert oder Leute zum Hörer, die das Thema noch gar nicht kennen.
Aber trotzdem würde ich sagen, probiert es mal aus, es ist gar nicht so schwer, wie es klingt.

[32:47] Ist dir Seppa noch ein Begriff von Sveld? Ja.
Ist Sveldkid jetzt eigentlich der Nachfolger oder ist es trotzdem was anderes?
Nee, das ist schon im Prinzip der Nachfolger. Also, Seppa wurde ja schon ursprünglich schon vor ziemlich langer Zeit mal aufgesetzt.
Sveld gibt's ja ungefähr seit 2016, wenn ich mich nicht irre.
Und Seppa kam erstmals irgendwie so 2017 raus.
Und das Team hinter Sveld, die auch für Sveldkid und damals auch für Seppa verantwortlich sind, das vorantreiben. Wir haben halt irgendwann entschieden, okay, die Architekturentscheidungen, die wir für Seppa getroffen haben, die sind nicht so zukunftsfähig und haben sich dann entschieden, okay, lass uns nochmal gucken, wie können wir das besser machen und das Ergebnis davon ist letztlich SvelteKit. Also SvelteKit ist letztlich der Nachfolger von, Seppa, wenn man so will.
Hast du jetzt die Befürchtung, dass das mit SvelteKit auch wieder passieren könnte? Denn und Rich Harris, wenn man ihn kennt und ihm folgt.
Ich weiß gar nicht, wie ich ihn beschreiben würde. Ich würde ihn ein bisschen als idealistisch ansehen in der Webwelt.
Was ich supergut finde, dass es diese Personen gibt.

[33:55] Aber mir auch ein bisschen Angst macht, seine Tools in Production einzusetzen, wenn er sich denkt, nee, es geht ja noch besser.
Wir stampfen das mal ein, wir machen noch mal von vorne.
Also, ich glaube, die Sorge kann ich durchaus nachvollziehen, weil das ist so ein bisschen auch der Track-Record, den Rich Harris hatte.
Vor Svelte kam ja auch schon was anderes, nämlich Rektiv, was irgendwie auch nicht das Beste war, was man machen konnte, und Svelte war dann die bessere Variante.
Ich glaube aber, man redet von ein bisschen unterschiedlichen Dimensionen.
Ich glaube, Rektiv hat bei Weitem nicht die Reichweite gehabt, die Svelte hatte heutzutage. Svelte ist sehr bekannt mittlerweile, viele Leute kennen es, Leute, die es benutzen, mögen es gern, das zu benutzen. Es ist mittlerweile seit ...

[34:35] Ich glaube, 2019, in der Version 3 und sehr stabil unterwegs, wird eigentlich nur erweitert und keine fundamentalen Änderungen.
Und die Community ist wesentlich größer, das Team, was dahinter steht, darf man auch nicht außer Acht lassen, ist mittlerweile größer.
Das ist nicht nur noch Recheris. Auch nicht nur Recheris wird tatsächlich, also vielleicht, das ist eigentlich eine coole Sache, wenn man sich das überlegt, dass bestimmte Firmen im Webumfeld, wie zum Beispiel Vercel oder Netlify, Leute sponsern für Fulltime Open Source Work.
Das ist in dem Fall auch einer dieser Fälle. Rich Harris wird halt quasi von Vercel angestellt, um Svelte weiterzuentwickeln.
Aber er ist auch nicht der einzige, der von Vercel angestellt wird, um Svelte weiterzuentwickeln.
Vercel hat zumindest noch eine weitere Person, glaube ich, eingestellt, die exklusiv für die Arbeit am Framework da ist. Und es gibt noch Leute, die innerhalb von Vercel dann für DevRelations und sowas verantwortlich sind, für Svelte spezifisch.
Also ich glaube, die Community ist heutzutage deutlich größer.
Das Team, was dahinter steht, ist deutlich größer.
Und ich, auch wenn Rich Harris natürlich immer noch das Gesicht ist.

[35:36] Glaube ich nicht mehr, dass es nur eine One-Man-Show ist. Und so ein fundamentaler Shift, den würde ich eigentlich jetzt erstmal nicht mehr erwarten, dazu ist mittlerweile die Reichweite und der Bekanntheitsgrad zu groß.
Früher war das vielleicht noch ein bisschen anders, da gab es eine Handvoll Leute, die die Tools verwendet haben, da konnte man noch so 180-Grad-Wendungen machen, oder zumindest in irgendeiner Form rechtfertigen, oder besser rechtfertigen als heute.
Aber ich würde damit nicht rechnen, Einfach dadurch, dass es wirklich seit vier Jahren Svelte für sich genommen komplett stabil ist.
Und Svelte geht jetzt auch relativ lange in Entwicklung, war uns seit Dezember dann auch erstmals in der 1.0-Variante vorliegt.
Und ich würde damit rechnen, dass das jetzt auch erstmal nur weiterentwickelt wird.

[36:18] Ja, das klingt ja auf jeden Fall schon mal nach guten Nachrichten.
Ich war eine von diesen wenigen Personen.
Ich habe meine Portfolioseite damals mit Seppar geschrieben.
Muss allerdings sagen, die läuft immer noch.
Hat zwei Probleme. Als ich damit angefangen hatte mit, ja, ich kann jetzt an Seppar auch gar nichts Spezielles sagen, das war halt wirklich das Weltkomponenten und hatte halt einen Bildprozess dazu.
Mehr habe ich da jetzt auch großartig nicht gemacht für eine Portfolioseite.
Hatte damals den riesigen Vorteil, dass ich es extrem einfach fand, das zu lernen und zu benutzen.
Und zwar einfacher als Nuxt.js. Das sind alles nur persönliche Erfahrungen und persönliche Meinungen.
Aber damals war das Vue 2.
Ich war sehr gut drin in Vue 2 und ich hatte auch ein bisschen Erfahrung mit Nuxt.
Und ich war aber noch begeisterter über die Syntax von Svelte, die ja jetzt auch sozusagen ein bisschen bei Vue 3 angekommen ist, diese Scripts und Templates, kein Component, Boilerplate, mehr drumrum.
Aber das war ja bei Svelte bei Anfang an, es war so schlank, das war ja extrem gut. Und was schön war, dann konnte man sich so extrem gut auf die eigentliche Programmierung konzentrieren.
Und nicht, ob ich das jetzt in den Computed- oder Methods-Block quasi reinschieben muss.

[37:39] Jetzt habe ich die zwei Probleme. Das eine ist, Wenn ich jetzt natürlich mal wieder was ändern muss, stehe ich da und so, hä, was ist dieses Dollarzeichen da?
Und wieso ist das so?
Und ich glaube, ich habe da auch nicht mehr den richtigen Linter und Pritt hier installiert.
Das ist alles ganz merkwürdig eingerückt.
Aber vor allem habe ich da gelernt, ein wichtiger Tipp immer an alle draußen, schön die Readme schreiben, wie man das Projekt eigentlich bildet.
Ich glaube, bei jedem von diesen Scaffolding-Tools ist das ja alles dabei.
Ob das jetzt Meet oder sonst was, das steht dann immer dabei.
Hier machst du npm install und dann machst du npm run dev oder du machst npm start, aber dass es dabei steht, ist sehr wichtig.
Weil sonst kommt man nach drei Jahren zu dem Projekt zurück und möchte da mal kurz...

[38:20] 2022 auf 2023 ändern und weiß plötzlich nicht mehr, was man tun soll.
Das war mit den damaligen HTML-Seiten noch sehr viel einfacher.
Das stimmt allerdings. Bei HTML-Seiten hat man einfach das Datum geändert und war fertig.
Ja, da war man fertig.
Ja, das stimmt schon. Bildprozesse bringen auf jeden Fall eine Menge Komplexität rein.
Und ich glaube, dieses Problem ist aber jetzt nicht exklusiv in diesem Space zu verordnen.
Also nicht exklusiv im Svelte-Space zu verordnen. Ich glaube, das ist so ein generelles Problem mit den Build Chains, die wir uns über die Jahre angeeignet haben.
Also, wenn man halt ein Projekt vielleicht vor sieben Jahren mal mit Grunt gemacht hat und das heute nochmal laufen lassen möchte, dann würde ich auch viel Spaß wünschen, ich glaube, da nochmal reinzukommen wird sehr schwierig sein, wenn man seitdem nur noch mit Webpack oder Veed oder irgendwas anderem gearbeitet hat.
Das ist, glaube ich, so... Und das ist auch einer der Punkte, wo tatsächlich man dieses Tooling, was wir heutzutage haben, durchaus kritisieren kann und sollte.
Es hat wahnsinnig viel Komplexität reingebracht, die man irgendwie beherrschen muss.
Mittlerweile bin ich persönlich an dem Punkt, wo ich sage, ich möchte, dass es funktioniert. Ich möchte diese Buildchains gar nicht mehr selber bauen.
Wenn immer das möglich ist, lasse ich das gerne die Opinionated.

[39:33] Tools machen, die mir zur Verfügung gestellt werden.
Dann bin ich auch gerne bereit, meine eigenen Opinions hinten anzustellen.
Einfach, weil es tatsächlich auf die Dauer sehr, sehr anstrengend ist und man einfach irgendwann nicht mehr weiß, was war denn jetzt eigentlich vor zehn Jahren noch das Ding oder vor fünf Jahren oder auch vor drei Jahren.
Also, der Space bewegt sich so schnell, da ist der genaue Zeitraum wahrscheinlich gar nicht so relevant mehr, dass sich einfach seitdem auf jeden Fall irgendwas verändert hat.

[39:59] Ja, JavaScript-Tooling ist ein guter Begriff, da darf auch jeder nochmal in die Revision von vorletzter Woche reinhören, die 564.
Da hatten wir Marvin Hagemeister hier, der genau sich diesen Thema angenommen hatte, JavaScript-Tooling zu optimieren, weil er auch gerade bei ESLint doch so einige Sachen gefunden hat, weil er sich gleich mal gefragt hat, was ist denn das da eigentlich so langsam?
Und sich das so ganz klitzeklein angeschaut hat, was passiert.
Und wenn man sich da mal reinwühlt, kann das da drin auch ganz schön lustig werden.
Aber wir haben ja jetzt gerade heute das...
Den Vorteil, dass das eigentlich ja die Tools für uns abnehmen und sich in dem Sinne heute SvelteKit drum kümmern wird, dass der Prozess hoffentlich irgendwie reibungsfrei funktioniert.
Also, zusammenfassend, SvelteKit ist Svelte, aber mit SSR und Routing und dem ganzen Gedöns, hat aber nichts mit einem UI-Framework oder Library zu tun.
Also, SvelteKit selber nicht, nee, das ist halt Svelte, ist die UI-Library, die in Svelte Kit dann verwendet wird.

[41:04] Oder meintest du jetzt irgendwie nur die UI-Library mit vorgefertigten Komponenten, die man zusammenstecken kann?
Ja, genau, weil das allererste Mal, als ich das Wort Kit gehört hatte, habe ich mich kurzzeitig gefragt, ob das jetzt quasi das Utify für Svelte ist.
Nee, tatsächlich ist das nicht der Fall. Also so eine UI-Komponentenbibliothek ist nicht Bestandteil des Frameworks.

[41:24] Also das ist eigentlich, der Scope ist, ich bin ein Application-Framework und benutze Svelte als Template-Engine, wenn man sich das vereinfacht mal überlegen möchte.
Ja. Das ist auch nochmal ein gutes Stichwort und gerade auch das, wie hieß das erste, Sveld, das Rectif?
Rectif, genau. Rectif. Rectif war quasi der Vorgänger von Sveld, das war Rich Harris' erstes Framework und wen Kent weiß, dass er seine Tools vor allem aus der Not geboren erstellt hat, ist ja jemand, der aus dem digitalen Journalismus mehr oder weniger kommt und da sich quasi seine Tools selber gebaut hat Und aus diesem Wege ist erst Reactive und später Swaith entstanden.
Und da war ja ein großer, einer dieser großen Punkte, die ich noch in Erinnerung habe, dass er immer meinte, ja, Reactive wäre ja gar nicht React.
React wäre ja gar nicht Reactive. Und meins ist richtig Reactive.
Und einer der größten Unterschiede jetzt aus der View und React immer noch heutzutage ist, dass es schon vorkompiliert wird und dann quasi das Welt...
Library gar nicht mehr mit dem Browser ausgeliefert wird, was ja bei Vue schon so ist, dass wenn ich jetzt eine Vue-App habe, wird auch immer Vue.js mit am Browser des Users laufen. Aber da gibt es immer noch den großen Unterschied.

[42:38] Also, es fällt es nach wie vor natürlich mit diesem Compiler-Ansatz, und ich glaube, wenn man den einmal irgendwie etabliert hat, dann kommt man da auch so ohne weiteres nicht raus.
Und während es richtig ist, dass man nicht mehr das komplette Framework packt und in den Browser schiebt, und da rüber dann Komponenten ausführen lässt, quasi das UI-Framework nimmt meine Komponenten und führt sie aus und alles in live und nichts irgendwie vorkopiert, also quasi live interpretiert.
Das ist bei Swage nicht so, weil der Compiler ja schon zur Buildzeit statische Code-Analyse macht, Dependency-Graphen innerhalb des Codes aufbaut und Abhängigkeiten von bestimmten HTML-Elementen auf bestimmte Werte einfach zu diesem Zeitpunkt schon identifizieren und hardcodieren kann.
Das ist immer noch da. Was natürlich nicht ganz richtig ist, ist, dass gar kein Code aus der Svelte-Library mitgeliefert wird.
Es wird eigentlich aber darauf beschränkt, dass nur der Code mitgeliefert wird, der auch wirklich gebraucht wird.
Das ist so ein bisschen der Unterschied vielleicht. Wenn du jedes einzelne Feature, was Svelte anbietet, nutzt in deinen Komponenten, wirst du wahrscheinlich auch einen relativ großen Anteil an Code aus der Svelte-Library in deinem Bundle haben.
Aber das ist einfach in der Natur der Sache, weil diese Funktionen sind ja da und können auch genutzt werden.
Sie werden allerdings nur dann mitgepackt, wenn sie auch gehaucht werden.

[43:51] So, dann haben wir erklärt, was Svelte und SvelteKit ist. Und wir wissen, was Edge Computing ist.
Und wir haben schon ganz oft den Namen Cloudflare gehört und wissen, dass damit irgendwie Edge Computing geht.
Wie kommen wir jetzt von SvelteKit zu Cloudflare?

[44:09] Du meintest, glaube ich, schon richtigerweise vorhin, da kommen schon so Sachen mit, dass Svelte dann auch extra für Cloudflare Cloudflare was loaders vorbereitet?
Genau, richtig. Also, im Prinzip, wenn man sich das vorstellt, Cloudflare ist erstmal nur eine Plattform, nur, in Anführungszeichen, eine Plattform, wo ich irgendwie Code hinschieben kann und wo Code ausgeführt werden kann.
Und SvelteKit macht es mir insofern dann einfach, als dass dieser Adapter, von dem ich eben sprach, schon für sich genommen einfach Unterstützung für Cloudflare bietet out of the box.
Und tatsächlich habe ich da, ich habe einen Guide geschrieben, der auf, den habe ich, glaube ich, gar nicht in der Link-Liste, können wir gleich noch reinpacken, aber im Prinzip kann man mit relativ simplen Schritten aus einer Swaget App, quasi auf Cloudflare in die Edge kommen, indem man einfach ein Repository erstellt, aus diesem Repository ein Cloudflare-Pages-Projekt, also Cloudflare-Pages nimmt quasi eine Anbindung an GitHub und holt sich dann quasi ausgetappt den Code.

[45:07] Und immer, wenn der aktualisiert wird, wird auch die App neu gebaut, so das übliche Prozedere, was man halt von solchen Plattformen heutzutage mehr oder weniger gewohnt ist.
Und aus diesem Repository kann man dann ein Cloudflare-pages-Projekt erstellen, dann kann man das WeltKit-App daraus erstellen, oder da rein, in dieses Repository reinpacken, und dann kann man die App pushen, und dann funktioniert das eigentlich out of the box, direkt auf Cloudflare.
Und mit Support tatsächlich, und das ist vielleicht noch ein spannender Punkt, dass natürlich eben nicht nur die statischen Inhalte, die man mit Swagetern generiert, irgendwie funktionieren, also nicht nur die Prerender-Pages, nicht nur die statischen Websites, die ich vielleicht vorher rausgehauen habe, sondern dass tatsächlich die ganze serverseitige Logik von Swaget dort halt auch funktioniert.
Die wird nämlich von diesem Adapter übersetzt in Cloudflare Edge Functions, die dann letztlich im Cloudflare-Netzwerk über den Wertball verteilt abgelegt werden und in den einzelnen Nodes überall dann ausführbar zur Verfügung stehen.

[46:07] Und somit kann man halt ein relativ einfaches Server-Side gerenderte App haben, wenn man sagt, ich hab eine Datenbank, die liegt irgendwo in der Cloud, dann kann man die halt auch dort anschließen, ohne dass man jetzt aus dem Client raus ein SDK braucht, was irgendwie secure ist, um an die Datenbank zu kommen, sondern kann das natürlich durch die Server-seitige Logik lösen.
Der Vorteil ist im Wesentlichen einfach, dass es sehr, sehr einfach ist, mit einer Sweltkit-Applikation out of the box, direkt in Cloudflare zu starten.
Aber der Vollständigkeit halber, das Gleiche sollte mit Netlify und Vercel ähnlich komfortabel funktionieren.
Ich persönlich habe es halt mit Cloudflare ausprobiert und damit gearbeitet.
Davon kann ich sprechen, aber Vercel und Netlify werden auch supportet und sollten gleichermaßen unterstützt werden.

[46:52] Jetzt hast du mir doch glatt die Frage weggenommen. Entschuldige.
Ob es denn nicht auch noch Cloudflare-Alternativen gibt und ob man das nicht auch mit Netlify und Vercel machen könnte.

[47:04] Aber dann geh doch gerne nochmal genauer auf deine Erfahrung mit Cloudflare ein, weil irgendwie bist du ja zu der Entscheidung gekommen, dass du jetzt das nutzt anstatt der anderen, auch wenn es bei den anderen vielleicht auch geht.
Also wie kam es denn dann speziell zu Cloudflare?
Ja, also das ist ein guter Punkt. Da wollte ich auch noch drauf hinaus, Cloudflare bietet das an, was Vercel und Netlify auch anbieten, also quasi statisches Web-Posting mit irgendwie Edge-Functions-Anbindung, kann man eine serverseitige Funktion da ausführen, das können die mittlerweile, soweit ich weiß, alle, relativ simpel.
Was Cloudflare allerdings tatsächlich noch mehr kann oder besser kann, Cloudflare kann halt auch Daten speichern an der Kante.

[47:46] Und das ist, glaube ich, ein Punkt, der viele Perspektiven erfordert, um damit zu arbeiten. Eine haben wir schon besprochen in Form von GDPA.
Natürlich sollte man da irgendwie sicher sein, dass man mit Cloudflare einen Partner hat, der auch den eigenen Datenschutzanforderungen genügt.
Sonst sollte man es nicht verwenden. Aber der Unterschied ist im Wesentlichen, dass Cloudflare neben diesen ganzen, ich nehme ein Git-Repository, baue das und packe das in mein CDN-Edge-Netzwerk, und da kann ich es ausführen, eben auch Möglichkeiten bietet, Daten zu speichern, die dann von Cloudflare über Magic, die für mich als Frontend-Entwickler völlig uninteressant ist, irgendwie im Globus verteilt werden und da verfügbar sind. Und da gibt es drei verschiedene Optionen.
Ich habe vor allem, weil ich ja gesagt habe, ich habe mit dem Freed hier vor allem gearbeitet, da gibt es halt nur eine von den drei Optionen, das ist eine der Einschränkungen, mit denen man arbeiten muss.
Aber es gibt...

[48:38] Ja, Workers KV heißt das eine, muss man vielleicht noch ein bisschen weiter ausholen, die Edge-Funktionen in Cloudflare werden in einem Cloudflare-Produkt ausgeführt, namens Workers, und das sind quasi diese Edge-Funktionen, und diese Workers, das ist quasi eine V8-Runtime, die gesandboxed läuft, und die einige zusätzliche Laufzeit-APIs zur Verfügung stellt, und eine dieser Laufzeit-APIs ist eben Key-Value-Storage, und das ist, was der Name schon sagt, ich kann also im Prinzip, in meiner Cloudflare-Applikation irgendwie Daten in einen Key-Value-Storage packen und die dann auch immer raussuchen.
Und wie das Ganze im Hintergrund funktioniert, ist für mich als Entwickler erstmal komplett transparent, das interessiert mich relativ wenig, aber, wenn man es wissen möchte, kann man sich natürlich überlegen, was passiert denn da eigentlich?
Und im Wesentlichen ist es so, dass, ja, an jedem Edge-Knoten, den Cloudflare hat.

[49:34] Wird quasi dieser Key-Value-Storage gespiegelt.
So. Und zwar, folgendermaßen, wenn man halt sagt, ich möchte jetzt einen neuen Schlüssel anlegen, mit einem neuen Wert, dann mache ich das erstmal an dem Knoten, wo ich gerade mit verbunden bin, der mir am nächsten ist, wenn ich jetzt in Köln bin, könnte das beispielsweise Knoten in Düsseldorf oder so sein, und dort lege ich dann quasi meinen neu gespeicherten Wert ab.
Und Key-Value-Storage ist nicht Instant, also es ist nicht Real-Time-Verfügbarkeit, da gibt's andere Tools, da kommen wir gleich noch kurz drauf, Und von dort aus wird dann quasi der Wert, den ich neu angelegt habe, irgendwie in Cloudflare gespiegelt und innerhalb von einer Minute, das ist so die garantierte Zeit, ist dieser Wert über den Globus überall quasi gemirrored und verfügbar in dem jeweiligen Cache, an dem jeweiligen Knoten.
So, das ist schon mal auf jeden Fall etwas, was schon sehr wertvoll sein kann, weil für mich als Entwickler brauche ich ja jetzt auch nicht mal mehr eine Datenbank.
So, ich kann jetzt einfach meine Daten auch irgendwie da speichern.
Klar ist so ein Key-Value-Storage, der nur eventually persistent ist.

[50:37] Natürlich nur begrenzt nützlich, nur für bestimmte Daten, die sich nicht so häufig ändern, zum Beispiel, aber es ist auf jeden Fall etwas, was man woanders so nicht hat, oder zumindest, ja, vielleicht haben die anderen mittlerweile ein bisschen nachgeholt, aber mein letzter Stand war, dass es tatsächlich bei Cloud Play relativ exklusiv ist.
Und nun ist dieser Key-Value-Storage natürlich nur eventually persistent, also nach einer Minute habe ich die Zusage vom Anbieter, dass es synchron ist, und während dieser Minute könnten dieser Wert von verschiedenen Orten geändert werden, dann wird es Konflikte geben und im Zweifel irgendwie so eine endlos Kaskade von Änderungen, weil es irgendwie jedes, weil es in kurzer Zeit überall geändert wird, deswegen ist es nicht so gut für Daten, die sich häufig ändern.
Es gibt von Cloudflare aber jetzt noch zwei andere Produkte.
Eins dafür ist, glaube ich, mittlerweile komplett verfügbar, aber nur im Paid-Tier, das nennt sich Durable Objects, und Durable Objects ist im Grunde genommen.

[51:34] Ja, da wird von Cloudflare garantiert, dass ich, wenn ich dieses Objekt speichere, dieses Durable Object speichere, dann kann ich das Instant überall abrufen.
Wie die das machen? Magic?
Ich weiß es nicht, sie sind Plattformbetreiber, und am Ende des Tages ist das ein Job, den ich gerne dem Plattformbetreiber machen lasse, weil ich mich damit nicht rumschlagen mag.
Aber für mich interessant ist, um zu wissen, Durable Object ist im Grunde genommen eine Instanz von einer JavaScript-Klasse, die irgendwie serialisiert wird oder als Gener-Code geteilt wird und die ist überall gleich zugänglich.
Es ist überall die gleiche Instanz, mit der ich arbeite.
Das heißt, da habe ich eine viel, viel stärkere Persistenzgarantie und eine viel, viel stärkere Verfügbarkeitsgarantie und die Garantie, dass es halt, wenn ich es am einen Ende der Welt ändere, auch unmittelbar am anderen Ende der Welt mit dem gleichen Wert abrufbar ist.
Bis zum nächsten Mal.

[52:28] Vielmehr kann ich dazu leider nicht sagen, weil ich selber noch nicht ausprobiert habe, aber ich finde es auf jeden Fall ein spannendes Proposal und werde es vielleicht auch irgendwann nochmal ein bisschen genauer erforschen.
Vor allem, weil innerhalb von diesem Cloudflare-Workers-Kontext jetzt noch ein weiteres Produkt auf die Karte gekommen ist.
Ich bin mir gerade gar nicht sicher, ob es mittlerweile der Open-Beta oder auch Closed-Beta sind.
Nennt sich D1 oder D1. Und dabei handelt es sich tatsächlich um eine SQLite-basierte SQL-Datenbank.

[52:58] An der Kante. Das heißt, ihr enabelt es mich als Entwickler sogar soweit, dass ich quasi eine fully grown SQL-Datenbank in meiner Edge-Applikation nutzen kann.
Wie gesagt, es ist ein super Value-Proposal. Man darf nicht vergessen, es ist natürlich harter Vendor-Login. Das heißt, gut, wenn man SQL-Datenbank kann, ist es möglicherweise relativ portable noch, weil man ja einfach im besten Fall einen Dump macht und woanders wieder hochlädt, aber trotzdem sollte man immer immer im Hinterkopf behalten, dass man sich da natürlich auch stark an den Anbieter bindet.
Aber ich glaube, das Value Proposal ist schon durchaus sichtbar.
Und ich könnte mir vorstellen, dass das für den einen oder anderen Entwickler, der gerade irgendwie startet, ein Projekt umzusetzen, schon durchaus attraktiv sein kann, weil man hat dann quasi einen Anbieter, der mir diese Möglichkeiten bietet, und ich brauche mich nicht irgendwie an verschiedenen Stellen drum zu kümmern, sondern kann das alles an der einen Stelle machen.
Und ja, das ist so prinzipiell der Hintergrund, warum ich mich damals für Cloudflare so interessiert habe und Cloudflare ausprobiert habe, im Kontext dieses Edge-Computing-Forschungsprojekts, sage ich mal.
Eben wegen dieser Datenspeicherungsmöglichkeit, alles aus einer Hand.

[54:10] Ja, ich finde, das klingt superinteressant. Da eröffnen sich ja ganz neue Möglichkeiten.
Da braucht man plötzlich kein Backend mehr. Da ist man plötzlich aus dem Frontend heraus, das Fullstack.
Normalerweise ist es oft anders herum, dass eher die Backende zu Fullstack werden.
Aber hier hat man wirklich die Möglichkeit, hier das Fullstack zu werden.
Ich finde, das klingt superinteressant für startende Projekte.
Ich will nicht immer sagen Startups, sondern es kann ja genauso gut bei bestehenden Unternehmen sein, die jetzt nach einem neuen Projekt daneben aufziehen wollen und vielleicht nicht auf Ihre 10 Jahre alte Codebase noch ein Feature ransetzen, sondern vielleicht das einfach komplett woanders hosten.
Das klingt ja sehr interessant.
Ich bin mir, also ich hab's jetzt nicht nachgeschaut, aber ich bin mir sicher, dass man das umziehen können muss.
Und Sie werden's einem schon nicht so schwer machen.
Auf der anderen Seite, wenn ich das hier mit Google Cloud und AWS...

[54:58] Ich hab das Glück, dass ich mich nicht drum kümmern muss. Ich hab eine Person hinter uns im Unternehmen, die kann das Gott sei Dank sehr, sehr gut. Und es geht auch niemals kaputt, und ich muss mich nie drum kümmern.
Ähm, vielleicht ist das auch das Problem, dass es für mich diese unbekannte Wolke ist, wo ich mich nicht aus... Ha, das war jetzt kein gewollter Wortwitz.
Ähm, wo ich mich nicht gerade drin auskenne.

[55:21] Aber es scheint da schon irgendwie Komplexität zu geben. Jetzt weiß ich nicht, ob du das einfach nur alles so schön erklärt hast.
Und Cloudflare schuldet dir jetzt auf jeden Fall hier mal was.
Für diese schöne Erklärung. Aber es klang zumindest alles sehr einfach.
Das Einzige, was ich dich jetzt noch erfragen würde, hast du ein paar konkrete Beispiele, was man denn da speichern wollen würde, jetzt nicht im SQLite-Datenbank-Modell, sondern und hier ist die Karte, die ich ebenfalls mitgebracht habe.
Das die erste Variante genannt wird. Key-Value-Workers-KV. Also, ich hab tatsächlich ein konkretes Beispiel, Und das ist die Karte, die ich mitgebracht habe.
Das sind die beiden Seiten hier. Und das ist die Karte, die ich mitgebracht habe.
Und zwar das Beispiel von dem, was ich halt selber gebaut habe.
Und das ist die Karte, die ich mitgebracht habe. Und das ist die Karte, die ich mitgebracht habe.
Und da, die App, die ich da gebaut habe, ist so eine Pseudo-E-Commerce-App, ein kleiner Shop, Also, das sind die beiden Seiten.
Und die sind für mich die Karten, die ich mitgebracht habe. Und die sind für mich die Karten, die ich mitgebracht habe.
Der nicht wirklich ein Shop ist, der viele Funktionen, die ein Shop braucht, nicht wirklich hat.
Die sind für mich die Karten, die ich mitgebracht habe. Die sind für mich die Karten, die ich mitgebracht habe.
Aber er speichert die Produktdaten innerhalb dieses Key-Value-Storage. Und Produktdaten Und die sind für mich die Karten, die ich mitgebracht habe. Und die sind für mich die Karten, die ich mitgebracht habe.
Ändern sich in den meisten Fällen einmal am Tag. Es gibt sicherlich vereinzelte Shops, die irgendwie sehr spezifische Anforderungen haben, wo ich einmal in der Stunde meine Produktdaten aktualisieren will, aber typischerweise sind die Produktdaten ja nicht so änderlich, dass sie sich alle naselang verändern. Sie sind aber änderlich, das heißt, man sollte sie verändern können. Und das ist etwas, wo ich mir vorstellen kann, dass Key-Value-Store halt wirklich ein ganz guter Deal ist, weil man halt an der Stelle sagt, okay, ja, ich hab halt Daten, die ändern sich irgendwie alle.

[56:47] Ja, selten, auf jeden Fall nicht sehr häufig, und dann ist es auch nicht schlimm, wenn auf der anderen Seite der Welt das Produkt eine Minute später den neuen Preis hat.
Ich glaube, wenn das wirklich eine Anforderung ist, dann hat man es mit einer sehr spezifischen Nische im Handel zu tun, und möchte dann vielleicht eine andere Technologie einsetzen.
Aber das wäre so ein gutes Beispiel dafür, glaube ich, was man machen kann.
Dann kann man natürlich noch weiterdenken. Man könnte auch sagen, okay, wenn man jetzt irgendwie ja, ein blödes Beispiel, eine To-Do-App hat, ne, klassiker To-Do-App, könnte man auch über für den Nutzer identifizierte To-Dos da drinnen speichern, weil am Ende des Tages der Nutzer wird ja nicht zu zwei, äh, zu den zugleichen Zeiten an zwei unterschiedlichen Orten sein.
Das heißt, er wird nicht mit dem Handy wahrscheinlich irgendwie in Singapur unterwegs sein und mit dem Desktop-Computer vielleicht in Europa.
Und selbst wenn er das wäre, dann wäre halt eine Minute später die Synchronisierung da, also alles, was nicht so zeitkritisch ist.
Und letztlich sind diese Key-Value-Storages nichts weiter als irgendwie String-identifizierte JSON-Blobs oder sowas.
Das ist im Wesentlichen wirklich nur eine ganz stumpfe Datenablage, und wie man die organisiert, kann man sich ja auch noch ein bisschen überlegen, kann man optimiert für den entsprechenden Use-Case machen, aber alles, was nicht zeitkritisch ist, kann man im Prinzip da ablegen.
Und natürlich, was vielleicht auch nicht, auch sensible Daten sind auch da nicht so gut aufgehoben.

[58:15] Sollte man vielleicht auch noch dazu sagen. Alles, was nicht zeitkritisch und nicht sensibel ist, ist aber, glaube ich, ein ganz guter Ort dafür.

[58:22] Ok, super. Wer jetzt nach Cloudflare googlen würde, findet da vor allem die Cloudflare Pages.
Das ist jetzt das, worüber wir gesprochen haben, wo ich mein Repository verlinken kann, und dann ist das quasi auf einer Cloudflare Page.
Richtig, das ist das Produkt Cloudflare Pages.
Das ist ein guter Punkt, dass du es nochmal sagst, haben wir tatsächlich eben nicht explizit erwähnt, aber Cloudflare hat halt relativ viele Produkte, aber Cloudflare Pages ist das, wonach man sucht, und wenn man nach diesen ganzen Datenspeichermöglichkeiten sucht, dann sucht man am besten nach Cloudflare Workers, denn die sind im Wesentlichen die Technologie, die da zugrunde liegt.
Man kann eine Page, wie gesagt, auch, die hat automatisch eine Workers-Integration, das heißt, wenn man das Projekt richtig einrichtet, dann werden diese Edge-Functions auch entsprechend gebaut und deployed, und das sind dann Functions, die im Workers-Kontext laufen, diese Edge-Frames, diese einzelnen Workers, und da gelten dann entsprechend diese, ja, die Regeln und die APIs, die im Workers-Kontext dokumentiert sind.

[59:31] Mhm. Und wenn man auf die Landingpage schaut, dann reden Sie, stimmt, das ist, wenn ich jetzt nur auf die Landingpage gehe, dann erscheint mir das, da wüsste ich jetzt erstmal nicht, was denn jetzt eigentlich der Unterschied ist zu Netlify und Vercel, weil es geht um Jamstack.

[59:48] Dem Spaß halber. Möchtest du kurz erklären, was ein Jamstack ist?
Was ist ein Jamstack? Ja, ich glaube, da gibt es mittlerweile auch genauso viele Definitionen, wie das Wort Buchstaben hat. Meine... Ja, wir wollen noch die 21. Definition von dir.
Also, so wie ich das kennengelernt habe, steht Jamstack für JavaScript, APIs und Markup.
Und im Wesentlichen war die Idee dahinter, mag sein, dass sich das heute wieder von der Definition verändert hat, ob das Wort, kann man, glaube ich, nicht mehr so viel geben.
Aber im Wesentlichen, man hat irgendwie statisches Markup, was irgendwie irgendwo geladen wird und dann über JavaScript mit APIs spricht, die von irgendwelchen Produkten angebunden werden, sodass man quasi eine statische Web-App irgendwo hat, die dann dynamisch über APIs Daten nachlädt und damit irgendwie Krempel macht.
Das ist so meine persönliche Vorstellung davon, zugegeben, die ist auch schon sehr alt.
Man hört ja immer wieder, dass sich dieses Wort irgendwie über die Zeit so verändert hat und auch die Definition, ich glaube, Netlify hat den Begriff mal geprägt und auch die Definition von Netlify selber haben sich irgendwie durch die Zeit immer ein bisschen verändert.
Kann man, glaube ich, im Internet-Archive nachschlagen, wenn man möchte.
Aber, ja, das ist so im Wesentlichen der Kern dahinter und ich glaube, das ist auch das, was Pages im Kern ist, eine Plattform für statische Web-Inhalte, plus mittlerweile halt die Edge-Functions und die damit verbundenen ganzen Worker-Möglichkeiten.

[1:01:10] Ja, das haben sie hier auch als vierten Punkt hier aufgelistet, Dynamic Functionality mit der Integration von den Cloudflare-Workers.
Und ansonsten, wie man's kennt, man hat die Git-Integration, und dann kann ich Git-Push machen, das stößt den NPM-Run-Build wahrscheinlich an.
Genau. Und ich gebe wahrscheinlich, oder hoffentlich, vielleicht funktioniert es sogar super smooth, dass ihr sagt, es ist ein Svelte-Projekt und dadurch weiß der Build-Prozess schon, dass es dann der Dist-Folder ist oder der Export oder der Build.
Ich habe dafür einen Guide geschrieben, wie man ein Svelte-Projekt auf Cloudflare-Pages bringt.
Den können wir in der Link-List. Ich glaube, ich habe ihn noch nicht hinterlegt, aber ich schicke ihn dir gleich gerne noch rüber, dass wir das noch unterbringen können.
Da kann man das nachlesen. Es sind eigentlich relativ simple Angelegenheiten.
Man muss ein bisschen konfigurieren, aber es ist halt wirklich nur so drei, vier Felder, wo man irgendwas eintippen muss und vielleicht noch ein Häkchen setzen und dann funktioniert das eigentlich ganz gut.

[1:02:11] Kann man nachlesen. Ist so einfach wie FTP fast. Ja, tatsächlich schon und sogar fast noch ein bisschen einfacher, weil wenn es einmal eingerichtet ist, dann läuft es halt.
Ja, da muss man sich ständig dran erinnern, wie war noch mal der FTP-Link?
Wie war noch mal der FTP-User, den ich verwendet habe?
Genau, Passwort war so ein Passwort. Tschüß, bis zum nächsten Mal.
Ja, du hast gerade schon erwähnt von ein paar Links, die du uns hinterlegt hast, also zwei hatten wir schon, aber ich sehe hier in der Link-Liste, die du schon für uns vorbereitet hast, die wir natürlich auch in die Show-Notes schreiben werden, noch was von App-Codes, Slides und Talks?
Genau. Also, diese ganze Inhalte, die Inhalte, die wir heute besprochen haben, gehen so ein bisschen zurück auf den Talk, den ich mal gemacht habe, und wo ich noch ein bisschen detaillierter und ein bisschen intensiver ein bisschen darüber sprechen wollte, und die Slides für diesen Talk sind offen einsehbar, die sind verlinkt.
Zu dem Talk gehört quasi eine Companion-App, wo man das quasi an diesem Live-Beispiel sich mal anschauen kann, diese E-Commerce-App, von der ich eben sprach, wo unter anderem die Produktdaten in dem Key-Value-Storage gespeichert werden, dafür ist der Code auf GitHub einsehbar, der wird verlinkt. Genau. Das sind so die beiden zusätzlichen Links, die wir, glaube ich, noch nicht gesprochen hatten, ne?

[1:03:22] Mhm. Ja. Ja, das ist super. Und wer jetzt noch mehr von dir lernen möchte, kann nicht nur den Talk auf YouTube im Nachhinein anschauen, sondern wird dich auch beim Svelte-Workshop treffen können bei der Enter.js im Juni.
Genau, richtig. Ich bin im Juni auf der Enter.js und da mache ich einen Svelte-Workshop.
Das ist ein Svelte-Einsteiger-Workshop. Das heißt, wir fangen tatsächlich bei Du kannst HTML, Du kannst CSS, Du kannst JavaScript an.
Und weitere Kenntnisse sind nicht erforderlich. Wir werden auch nicht auf die großen Details von Svelte-Kit eingehen, sondern wirklich nur auf das UI-Framework, und dann gemeinsam ein bisschen was bauen, damit ihr ein Gefühl dafür bekommt, was dieses Framework anbietet, was es kann. Und einen Tag später bin ich auf der InterJS dann noch mit einem Talk vertreten, aber wenn ihr diese Folge gehört habt, werdet ihr dort nichts Neues erfahren.
Es sieht nur vielleicht ein bisschen schöner aus, weil ihr auch was seht und nicht nur hört.
Ja, super. Aber das mit dem Svelte-Workshop klingt auf jeden Fall Sehr gut. Was ich persönlich immer mag, man muss ja nicht immer nur einen Workshop für eine eine Programmiersprache oder ein Dialekt oder ein Framework.

[1:04:32] Man muss ja nicht nur Tandrei nehmen, wenn man fest vorhat, das auszubenutzen, sondern auch einfach immer das Reinschnuppern in andere Paradigmen, in andere Theorien, finde ich extrem hilfreich.
Kann mir vorstellen, dass einem das immer so ein bisschen so ein bisschen nächste Stufe eines Developers immer noch so ein bisschen weiterbringt.
Da ein bisschen die Fühler draußen zu haben und zu verstehen, was die Grundgedanken von so anderen Frameworks vielleicht auch sein können.
Und dann, selbst wenn man noch JQuery macht, was komplett legitim ist, dann kann man ja vielleicht so, man muss vielleicht jetzt nicht die ganze zehn Jahre alte Web App nehmen und einmal komplett migrieren für mon... Jahre, weiß ich nicht.
Aber vielleicht kann man ja so ein paar Gedanken immer mit einbringen und sich denken, ach, guck mal, da gibt's ja dieses Format, dass man reaktive Daten immer mit, weiß ich nicht, ich weiß nicht, ob das immer noch so ist, mit so einem Donnerzeichen oder sowas, passiert. Vielleicht kann man sich das ja auch so in die JQuery App dann mitnehmen und so sagen, hey, hier möchte ich eigentlich einen Wert haben, der möchte dich kennzeichnen, der kann sich ändern und der soll das Template sozusagen, das Markup, das HTML verändern, deswegen kennst du eigentlich nicht die jetzt auch mit einem Dodder.
Das finde ich immer sehr, sehr gut.
Deswegen freut es mich zu hören, dass du auch einen Workshop darüber gibst.

[1:05:44] Wir haben jetzt gesprochen über Edge Computing, über Edge Computing mit SvelteKit, über SvelteKit mit Cloudflare Playtest und Edge Computing.
Haben wir irgendwas noch nicht erwähnt, worüber du gerne noch sprechen möchtest?
Nee, ich glaube, wir sind mit allem durch, auch wenn ich mir die Liste der vorüberlegten Themen anspreche, dann glaube ich, haben wir alle Punkte soweit besprochen, ja.

[1:06:11] Zum Abschluss, ich könnte das jetzt also auch machen, ich könnte jetzt auch Edge Computing mit Vue, und Cloudflare-Pages machen, oder mit Nuxt und Cloudflare-Pages.
Theoretisch spricht da absolut nichts gegen. Ich weiß nicht, wie gut jetzt Nuxt zum Beispiel irgendwie auf Cloudflare-Pages oder Ver-Send-or-Notify adaptiert ist, oder wie man das machen würde, aber theoretisch spricht natürlich nichts dagegen.
Wenn du deine Next-App in der Edge-Funktion ausführen kannst, dann kannst du die genauso nutzen, wie das auch mit das Weltgitter-Fall ist.
Als Wettkampf hat man halt bloß den Vorteil, dass man halt...
Ja, out-of-the-box-Support für diese Plattformen schon hat und sich nicht groß kümmern muss, das zu adaptieren.
Von anderen Frameworks weiß ich aber nicht, wie sich da die Tools verhalten. Da wird's auch Mittel und Wege geben.
Im Prinzip wird das machbar sein, ja. Ja, ich seh hier schon die Landingpage, wo das React-Logo, Vue-Logo, Gatsby-Logo, Hugo-Logo... Ja, dann...
Es ist hier schon verlinkt mit einem... Ach, guck mal. Deploy a Blazer, Brunch, Dokusaurus, Gatsby, Gridswurm, Hexo, Hono, Hugo, Jackalus, etc.
Ich bin ja, was man heutzutage alles lernen muss, das ist ja verrückt.
Quick, Remix, Solid. Hui, ja, komplizierte Zeit. Das Gute ist, man muss es nicht alles lernen.

[1:07:25] Aber man kann alles deployen. Also egal, was man gelernt hat, man kann auf jeden Fall alles deployen.
Ich glaube, PHP geht nicht, aber sonst geht ziemlich viel, ja.
Aber PHP hat ... Ach ja, doch, es hat ja auch sozusagen einen Frontend.
Aber Laravel macht man ja auch heutzutage. Ja, plain PHP macht man nicht mehr, das stimmt.
Laravel mit Inertia und Vue oder so. Ja, ja, ja. Und dann macht man auch hier so ein Headless-CMS drauf.
Genau, Statement nutzt man da, hab ich gehört, in der Laravel-Welt.
Sicher? Ich hab keine Ahnung, das ist ein Space, in dem ich tatsächlich gar nicht mehr so aktiv bin, wenn man nur so peripher Sachen mitbekommt.
Aber Statemic scheint einen ganz guten Ruf zu genießen und kann sowohl Headless als auch Headfull.
Basiert auf Laravel, integriert sich wohl fabelhaft damit. Aber wer so ein bisschen peripher auch nur das Laravel-Ökosystem auf dem Schirm hat, weiß, dass da halt ganz, ganz viel drum gewachsen ist in den letzten Jahren.
Und dass da durchaus ein Ökosystem am Start ist, was man nicht unterschätzen sollte.
Sollte. Und was sich lohnen kann zu lernen, wenn man tatsächlich entweder den Horizont erweitern möchte oder vielleicht einfach mal lernen möchte, dass man nicht immer nur PHP haten muss, sondern auch mit PHP gute Software schreiben kann, weil das Problem meistens vor dem Rechner sitzt und nicht im Rechner ist.

[1:08:45] Ja. Aber da spricht das alte, das alte Herz so ein bisschen raus. Leute hatet doch nicht immer nur. Probiert es doch mal selber aus.
Ja, also auf jeden Fall ein schöner Moment in diesem Podcast über diese ganzen Tools, was man mit denen doch alles machen kann, um zu seinem perfekten Champs zu kommen.
Ich glaub, das war jetzt dieser schöne Moment, wenn uns irgendjemand anders zuhört, der oder die nicht direkt Frontend-Web-Developer ist.
Die fragen sich auch, wir haben doch einen Lappenschutz. Hat keiner, was wir grad gesagt haben.
Das stimmt. Okay, also bitte jetzt kein böses Feedback, dass wir nicht genau drauf eingegangen sind, was irgendwie...
Ist da Tamek? Ist da Tamek, ja.
Ich hab's noch nicht mal gehört. Wie gesagt, periphere Vision, peripheral vision, wie man im Englischen sagt, irgendwie noch alte Connections in dieses Ökosystem sind übrig geblieben und da kriegt man immer so ein bisschen mit, was abgeht. Aber benutzt habe ich Laravel auch seit Jahren nicht mehr.

[1:09:44] Gut, dann mach ich doch gleich noch den letzten Aufruf in dieser Folge an alle Hörer und Hörerinnen, die sich mit diesen Tools auskönnen.
Kommt doch gerne vorbei, damit ich auch auf dem Laufenden bleibe, was wir hier eigentlich so machen in der Frontend-Welt.
Wie gesagt, wir verlinken alles in den Show Notes und wir bedanken uns sehr fürs Zuhören.
Nils, dir danke ich sehr für diese sehr informative Episode über Edge Computing, Svelte Kit und Cloudflare Pages.
Ich hoffe, du wirst uns auch mal wieder besuchen. Ja, sehr gerne. Ich war wieder sehr gerne hier.
Das zweite Mal jetzt schon. Das hat das zweite Mal sehr viel Spaß gemacht.
Und ich bin ziemlich sicher, dass wir uns in der Zukunft noch mal sehen.
Oder hören. Mit Sicherheit. Ich wünsche dir sehr viel Erfolg beim Svelte Workshop und einen Talk danach.
Ganz viel Kraft auch. Das sind zwei Tage. Das kann man auch unterschätzen, was da immer so auf einen drauf zukommt, aber alles Gute dafür. Ich weiß, du wirst das ganz gut machen.
Es freut mich sehr, dass du hier gewesen bist. Was mich auch freuen würde, was uns als Working Drafts erfreuen würde, wären 5 Sternchen auf iTunes.
Und wenn ihr uns kontaktieren möchtet, dann macht das gerne in unserer Slack Community Draft oder auf Twitter oder auf Mastodon oder per E-Mail.
Das war's, glaube ich. Ansonsten vielen Dank fürs Zuhören und bis zum nächsten Mal. Ciao.

[1:11:11] Music.

[1:11:34] Musik.