Smashing Podcast Folge 22 mit Chris Coyier: Was ist serverlos?

Veröffentlicht: 2022-03-10

Kurze Zusammenfassung ↬ Wir sprechen von Serverless-Architekturen. Was bedeutet das und wie unterscheidet es sich davon, wie wir derzeit Websites erstellen? Drew McLellan spricht mit Chris Coyier, um es herauszufinden.

Heute sprechen wir über serverlose Architekturen. Was bedeutet das und wie unterscheidet es sich davon, wie wir derzeit Websites erstellen? Ich habe mit Chris Coyier gesprochen, um das herauszufinden.

Notizen anzeigen

Chris' Microsite The Power of Serverless für Front-End-Entwickler
Chris auf Twitter
ShopTalk Show-Podcast

Wöchentliches Update

„Einrichten von Redux zur Verwendung in einer realen Anwendung“,
von Jerry Navi
„Können Sie eine Website für die fünf Sinne entwerfen?“,
von Susanne Scacca
„Erstellen eines statischen Blogs mit Sapper und Strapi“,
von Daniel Madalitso Phiri
„Ein praktischer Leitfaden für Produkttouren in React-Apps“,
von Blessing Krofegha
„So erstellen Sie einen Porsche 911 mit Skizze“,
von Nikola Lazarevic

Abschrift

Foto von Chris Coyier Drew McLellan: Er ist ein Webdesigner und -entwickler, den Sie vielleicht von CSS-Tricks kennen, einer Website, die er vor mehr als 10 Jahren gestartet hat und die nach wie vor eine fantastische Lernressource für diejenigen ist, die Websites erstellen. Er ist Mitbegründer von CodePen, dem browserbasierten Programmierspielplatz und der Community, die von Front-Endern auf der ganzen Welt genutzt wird, um ihre Arbeit zu teilen und sich von denen inspirieren zu lassen, denen sie folgen. Neben Dave ist Rupert Co-Moderator der ShopTalk Show, einem Podcast rund um das Erstellen von Websites. Wir wissen also, dass er viel über Webentwicklung weiß, aber wussten Sie, dass er einmal einen Hot-Dog-Essen-Wettbewerb nur mit seinem Charme gewonnen hat? Meine großartigen Freunde, bitte heißt Chris Coyier willkommen. Hallo Chris, wie geht es dir?

Chris Coyier: Hey, ich bin der Hammer.

Drew: Ich wollte heute mit Ihnen nicht über CodePen sprechen, und ich möchte nicht unbedingt mit Ihnen über CSS-Tricks sprechen, das ist eine dieser erstaunlichen Ressourcen, von denen ich sicher bin, dass jeder weiß, dass sie ganz oben bei Google erscheinen Suchergebnisse bei der Suche nach Antworten auf Fragen von Webentwicklern. Ihr Gesicht taucht auf und es gibt einen nützlichen Blogbeitrag, der von Ihnen oder einem Ihrer Gastautoren geschrieben wurde.

Chris: Oh, das habe ich früher tatsächlich gemacht. Es gab ein … ich weiß nicht, es war wahrscheinlich zu der Zeit, als Google dieses seltsame soziale Netzwerk hatte. Was war das? Google Plus?

Drew: Oh, Plus, ja.

Chris: Ja, wo sie eine Website mit einem Plus-Konto verknüpft haben, und mein Plus-Konto hatte einen Avatar, und der Avatar war ich, also tauchte er in den Suchergebnissen auf. Ich denke, diese Zeiten sind vorbei. Ich denke, wenn du …

Drew: Ich denke schon, ja-

Chris: Ja.

Drew: Aber ich wollte mit Ihnen über etwas sprechen, das eher ein Nebeninteresse von Ihnen war, und das ist dieses Konzept serverloser Architekturen.

Chris: Mm (bestätigend).

Drew: Das ist etwas, worüber du seit einiger Zeit mehr lernst. Ist das richtig?

Chris: Ja, ja. Ich bin nur ein Fan. Es scheint wie eine natürliche Ergänzung zur Entwicklung der Front-End-Entwicklung, wo ich das Gefühl habe, zumindest etwas Fachwissen zu haben. Ich betrachte mich eher als … viel nützlicher im Front-End als im Back-End, nicht dass ich … ich mache das heutzutage die ganze Zeit. Ich bin schon lange genug dabei, dass ich keine Angst davor habe, mir ein bisschen Ruby-Code anzusehen, das steht fest. Aber ich bevorzuge das Frontend. Ich habe es mehr studiert. Ich habe mehr an Projekten auf diesem Niveau teilgenommen, und dann kommt dieses kleine neue Paradigma, das besagt: „Sie können Ihre JavaScript-Kenntnisse auf dem Server einsetzen“, und das ist interessant. Du weisst? So denke ich darüber. Es steckt noch viel mehr dahinter, aber das interessiert mich, weil ich das Gefühl habe, dass Front-End-Entwickler so tief in JavaScript eingegraben sind. Und jetzt können wir dieselben Fähigkeiten auch anderswo einsetzen. Mh, ziemlich cool.

Drew: Scheint, als hätte sich eine ganz neue Welt aufgetan, aber wenn Sie nur ein Front-End-Programmierer wären … ich sage, nur ein Front-End-Programmierer, sollte ich das nicht tun. Wenn Sie ein Front-End-Programmierer sind und daran gewöhnt sind, mit einem Kollegen oder Freund zusammenzuarbeiten, um Ihnen bei der Back-End-Implementierung zu helfen, ist das plötzlich offen. Und es ist etwas, mit dem Sie einen Großteil des gesamten Stacks selbst verwalten können.

Chris: Ja, ja. Das ist es.

Drew: Den Elefanten im Raum ansprechen, ganz oben. Wir sprechen über Serverless, und offensichtlich ist es schwierig, Dinge zu benennen. Wir alle wissen das. Serverlose Architektur bedeutet nicht, dass es keine Server gibt, oder?

Chris: Ich denke, es ist obligatorisch, wie wenn dies der erste Podcast ist, den Sie hören, oder im ersten … Sie das Wort „serverless“ nur beim ersten Dutzend Mal hören, das Sie es jemals gehört haben, ist es obligatorisch, dass Sie es tun eine viszerale Reaktion haben und diese Art von „Oh, aber es gibt immer noch Server.“ Das ist okay. Wenn Ihnen das gerade passiert, wissen Sie einfach, dass dies ein erforderlicher Schritt in diesem Zusammenhang ist. Es ist wie mit allem anderen im Leben. Es gibt Stufen zum Verstehen. Wenn Sie etwas zum ersten Mal hören, müssen Sie es ein wenig ablehnen, und erst nach etwa einem Dutzend Mal oder nachdem es sich für Sie ein wenig bewährt hat, können Sie die weiteren Stufen betreten hier zu verstehen. Aber das Wort hat gewonnen, also wenn Sie immer noch gegen das Wort „serverless“ kämpfen, muss ich Ihnen nur ungern sagen, dass der Zug dort den Bahnhof verlassen hat. Das Wort ist bereits erfolgreich. Du wirst dieses nicht gewinnen. So leid.

Chris: Aber ich denke, es ist interessant, dass… es fängt an zu sein, dass vielleicht manchmal gar keine Server involviert sind. Ich würde denken, dass eines der Dinge, die Serverless als Konzept festgeschrieben haben, AWS Lambda war. Sie waren gewissermaßen die ersten auf der Bildfläche. Ein Lambda ist wie eine Funktion, die Sie AWS geben und die es in den magischen Himmel versetzt, und dann … es hat eine URL, und Sie können darauf klicken, und es wird diese Funktion ausführen und etwas zurückgeben, wenn Sie es möchten. Du weisst? Das ist nur HTTP oder was auch immer. So funktioniert es, und das erste Mal, wenn du das hörst, denkst du: „Warum? Es ist mir egal." Aber dann gibt es einige offensichtliche Dinge. Es könnte meine API-Schlüssel kennen, auf die sonst niemand Zugriff hat. Aus diesem Grund führen Sie zunächst das Backend aus, da es geheime Dinge kennt, die nicht im JavaScript auf der Clientseite enthalten sein müssen. Wenn es also mit einer Datenbank kommunizieren muss, kann es das tun. Dies kann sicher erfolgen, ohne dass API-Schlüssel an anderer Stelle offengelegt werden müssen. Oder sogar wo diese Daten sind oder wie sie sie bekommen, es ist ...

Chris: Also das ist ziemlich cool. Ich kann eine Funktion schreiben, die mit einer Datenbank kommuniziert, einige Daten erhält und diese zurückgibt. Cool. Also, Lambda ist das, aber AWS funktioniert. Sie müssen eine Region auswählen. Du sagst: „Ich weiß nicht. Wo sollte es sein, Virginia? Oregon? Soll ich das aus Australien nehmen? Ich weiß nicht." Sie haben 20, 30. Ich weiß nicht einmal, wie viele sie heutzutage haben, aber sogar Lambdas hatten Regionen. Ich denke, sie haben heutzutage Lambda@Edge, was bedeutet, dass es alle Regionen sind, was irgendwie cool ist. Aber sie waren die Ersten, und jetzt hat jeder so etwas wie Lambda. Alle Cloud-Dienste. Sie wollen irgendeine Art von Dienst in dieser Welt. Eines davon ist CloudFlare. CloudFlare hat Arbeiter. Sie haben viel mehr Standorte als AWS, aber sie haben es auch zu einer anderen Zeit ausgeführt … so wie ein CloudFlare-Worker … es ist ähnlich wie ein Lambda, da Sie Node ausführen können. Sie können JavaScript ausführen. Sie können auch eine Reihe anderer Sprachen ausführen, aber … Ich denke, dass die interessanteste Sprache JavaScript ist, nur weil sie weit verbreitet ist.

Chris: Es passiert nur auf CDN-Ebene, was meiner Meinung nach ein Server ist, aber ich neige dazu, CDNs nicht als Server zu betrachten. Nicht so offensichtlich wie etwas anderes. In letzter Zeit fühlt es sich noch serverloser an. Ist ein CDN ein Server? Ich meine, ich schätze, es ist irgendwo ein Computer, aber es fühlt sich an, als wäre es noch weniger serverlastig.

Drew: Es fühlt sich so an, als ob ein CDN ein Server sein könnte, aber es ist die minimalste Version eines Servers. Es ist wie ein dünner Server, wenn Sie so wollen.

Chris: Ja. Sicher.

Drew: In Ordnung. Ich habe gehört, dass es gesagt hat … Ich kann mich leider nicht an die Quelle erinnern, um es zu würdigen, aber ich habe gehört, dass Serverless als „wie die Nutzung eines Mitfahrdienstes wie Uber oder Lyft“ oder was auch immer beschrieben wird. Sie können autolos sein und kein Auto besitzen, aber das bedeutet nicht, dass Sie niemals ein Auto benutzen.

Chris: Ja, das heißt nicht, dass es keine Autos gibt. Mhm, das ist schön.

Drew: Du rufst einfach einen, wenn du ihn brauchst, aber gleichzeitig bezahlst du nicht die Anschaffungskosten für ein Auto. Du zahlst weder Wartung noch Treibstoff oder-

Chris: Richtig, und die Preisgestaltung macht auch Sinn, oder? Das ist schön. Das ist eine schöne Analogie, finde ich. Und weil es sich auch auf CDN-Ebene befindet, fängt es nur HTTP-Anfragen ab, die bereits stattfinden, was bedeutet, dass Sie es nicht fragen ... Sie senden keine Anfrage an es und es sendet eine Anfrage zurück. Es passiert natürlich nur während der Anfrage, wodurch es sich auch weniger serverhaft anfühlt. Ich weiß nicht, es ist interessant. Es ist sicher interessant. Das ist aber eine große Sache, dass Sie die Preissache angesprochen haben. Dass Sie nur für das bezahlen, was Sie nutzen. Das ist auch wichtig, denn … sagen wir, Sie sind ein Back-End-Entwickler, der es gewohnt ist, sein ganzes Leben lang Server hochzufahren. Und sie übernehmen die Kosten: „Ich brauche diese Art von Server mit dieser Art von Speicher und dieser Art von CPU und diesen Spezifikationen. Und so viel wird es kosten.“ Serverless kommt daher und schneidet dieser Preisgestaltung den Kopf ab.

Chris: Also, selbst wenn Sie ein Back-End-Entwickler sind, der das einfach nicht so sehr mag, dass er sich einfach nicht dafür interessiert, als ob Ihre Fähigkeiten im Laufe der Jahre genau das sind, was sie sind, vergleichen Sie den Preis und du denkst: „Was? Ich könnte 1 % von dem bezahlen, was ich vorher bezahlt habe?“ Das darf dir doch nicht egal sein, oder? Wenn Sie dieser Back-End-Entwickler sind, der hundertmal mehr für seinen Service bezahlt, als er zahlen muss, dann sind Sie einfach ziemlich schlecht in Ihrem Job. Tut mir leid zu sagen. Dies ist hinzugekommen und hat die Preisgestaltung in vielerlei Hinsicht erschüttert. Darum musst du dich kümmern. Und es ist irgendwie cool, dass jemand anderes … Es ist nicht so, dass Sie sich überhaupt keine Sorgen um die Sicherheit machen müssen, aber es ist nicht Ihr Server. Sie haben nicht … Ihre Lambda- oder Cloud-Funktion, oder Ihr Mitarbeiter oder was auch immer, sitzt nicht auf einem Server, der sich direkt neben einigen wirklich sensiblen Daten in Ihrem eigenen Netzwerk befindet. Es ist nicht direkt neben Ihrer Datenbank.

Chris: Wenn jemand Code schreibt, der irgendwie versucht, sich selbst aus dem Worker oder dem Lambda oder was auch immer auszuwerfen, und versucht, auf seine Weise Zugang zu anderen Dingen zu erhalten, gibt es nichts zu holen. Die Sicherheit ist also auch eine große Sache, also noch einmal, wenn das Ihre Aufgabe als Serveradministrator ist, müssen Sie sich um die Sicherheit dieses Dings kümmern. Wenn Sie es ausführen, bestimmte Dinge in Lambda ausführen, erhalten Sie einfach eine gewisse natürliche Sicherheit, was großartig ist. Also, es ist viel billiger. Es ist viel sicherer. Es fördert diese kleine modulare Architektur, was eine gute Idee sein kann. Hier scheint es Domino um Domino guter Ideen zu gehen. Deshalb ist es bemerkenswert. Du weisst?

Drew: Ja, ich meine, traditionell mit einer serverbasierten Architektur, die wir seit Jahrzehnten im Web betreiben, haben Sie einen Webserver, den Sie selbst betreiben. Es enthält Ihren Front-End-Code, Ihren Back-End-Code, Ihre Datenbank und alles. Dann müssen Sie es warten und am Laufen halten und die Rechnungen bezahlen, und selbst wenn es nicht verwendet wird, ist es da, um Rechnungen zu begleichen. Der Benutzer würde eine Anfrage stellen und es würde all das HTML-Abfragematerial aus der Datenbank erstellen und alles an den Browser senden. Dieser Prozess funktioniert. So werden viele Dinge gebaut. Es ist wahrscheinlich der Großteil dessen, wie das Web aufgebaut ist. So funktionieren Dinge wie WordPress. Ist das wirklich ein Problem, das wir lösen müssen? Ich meine, wir haben ein wenig über die Kosten gesprochen. Was sind die anderen Probleme damit, die wir angehen müssen und bei denen Serverless uns helfen könnte?

Chris: Ja, die Probleme mit dem Ansatz der alten Schule. Ja, ich weiß nicht, vielleicht gibt es keine. Ich meine, ich sage nicht, dass das ganze Web sein ganzes … alles über Nacht ändern muss. Ich weiß nicht. Vielleicht nicht wirklich, aber ich denke, es öffnet Türen. Es scheint nur so, als würden gute Ideen wie diese nur langsam die Art und Weise verändern, wie das Web überhaupt funktioniert. Wenn es also ein CMS gibt, das auf irgendeine Weise aufgebaut ist und eine Datenbank erwartet, bedeutet dies, dass die Hosts der Zukunft dies möglicherweise auf interessante Weise nutzen werden. Vielleicht fühlt es sich für Sie so an, als wäre es immer noch nur ein traditioneller Server, aber die Hosts selbst haben es, wie sie arbeiten, auf serverlose Architekturen ausgelagert. Sie wissen also nicht einmal wirklich, dass das passiert, aber sie haben einen Weg gefunden, ihre Kosten zu senken, indem sie die Dinge, die Sie benötigen, serverlos hosten. Vielleicht müssen Sie sich als Entwickler nicht einmal darum kümmern, aber auf einer Metaebene passiert genau das. Vielleicht. Ich weiß nicht.

Chris: Das heißt auch nicht, dass… Datenbanken noch da sind. Wenn sich herausstellt, dass eine relationale Datenbank architektonisch der richtige Weg ist, diese Daten zu speichern, großartig. Ich erwähne das, weil diese Welt von Serverless zur gleichen Zeit erwachsen wird wie JAMstack. Und JAMstack ist diese Architektur, die lautet: „Sie sollten Ihre Website von statischen Hosts aus bedienen, auf denen überhaupt nichts läuft, außer…“ Sie sind wie kleine CDNs. Sie sagen: „Ich kann nichts tun. Ich verwende kein PHP. Ich verwende Ruby nicht. Ich laufe nichts. Ich laufe auf einem winzig kleinen Webserver, der nur dafür ausgelegt ist, nur statische Dateien bereitzustellen.“

Chris: „Und wenn Sie mehr als das tun müssen, wenn Sie Daten aus einer relationalen Datenbank abrufen müssen, dann tun Sie dies bitte zu einem anderen Zeitpunkt, nicht zur Serverzeit. Sie können dies entweder im Voraus in einem Build-Prozess tun und das Zeug aus der Datenbank ziehen, statische Dateien vorab erstellen und ich werde diese bereitstellen, oder es zur Laufzeit tun.“ Das heißt, Sie erhalten diese Hülle eines Dokuments, und dann stellt es eine JavaScript-Anforderung, um einige Daten abzurufen, und füllt sie dann vorab aus. Sie tun es also vor oder nach der Zeit, aber das bedeutet nicht: „Verwenden Sie keine relationale Datenbank“. Es bedeutet nur: „Der Server muss es nicht zum Zeitpunkt der Anforderung des Dokuments generieren“, was ein … ich weiß nicht, es ist ein kleiner Paradigmenwechsel.

Chris: Es ist auch nicht nur JAMstack. Wir leben auch in der Zeit der JavaScript-Frameworks. Wir leben in einer Zeit, in der langsam mehr erwartet wird, dass eine JavaScript-Anwendung so startet, dass sie einige Komponenten einbindet und beim Einhängen dieser Komponenten nach den Daten fragt, die sie benötigt. Und so kann es für so etwas wie eine React-Website ganz natürlich sein, so zu sein: „Nun, ich drücke einfach eine serverlose Funktion, um die Daten auszuspucken, die sie benötigt. Es trifft im Wesentlichen eine JSON-API. Ich bekomme die JSON-Daten, die ich benötige, konstruiere mich selbst aus diesen Daten und rendere dann auf der Seite.“ Nun, ob das gut oder schlecht für das Web ist, es ist wie: „Ich weiß nicht. Schade. Schiff ist abgefahren. So bauen viele Leute auf Baustellen.“ Es sind nur vom Client gerenderte Dinge. Serverloses und modernes JavaScript gehen also Hand in Hand.

Drew: Ich nehme an, Sie müssen nicht pauschal… sich die eine oder andere Architektur ansehen. Es gibt einen Bereich in der Mitte, in dem Teile einer Infrastruktur eher traditionell und Teile serverlos sein könnten, schätze ich?

Chris: Ja. Nun, das versuchen sie dir sowieso zu sagen. Jeder, der Ihnen einen Teil seiner Architektur verkaufen möchte, sagt: „Sie müssen jetzt nicht alles kaufen. Mach es einfach ein bisschen.“ Denn natürlich wollen sie, dass Sie Ihren Zeh in das eintauchen, was sie verkaufen, denn sobald Sie den Zeh eintauchen, ist die Wahrscheinlichkeit, dass Sie sich in den Pool spritzen, viel höher. Also, ich denke, dass… es ist nicht notwendigerweise eine Lüge, obwohl ich etwas weniger Glück finde in… Ich möchte nicht, dass mein Stack ein bisschen von allem ist. Ich denke, da ist ein technischer Tod dabei, den ich nicht immer schlucken möchte.

Drew: Mm (bestätigend).

Chris: Aber es ist möglich. Ich denke, die am häufigsten zitierte ist … sagen wir, ich habe eine Website mit einem eCommerce-Element, was bedeutet … und sagen wir, groß angelegter eCommerce, also 10.000 Produkte oder so, dass diese JAMstack-Architektur noch nicht an dem Punkt angekommen ist, wo das ist immer besonders effizient, das statisch nachzubauen. Der Gedanke lautet also: „Dann lass es.“ Lassen Sie diesen Teil auf natürliche Weise hydrieren mit … Serverless-Funktionen treffen und die Daten abrufen, die er benötigt, und all das tun. Aber der Rest der Seite, der nicht … es gibt nicht so viele Seiten, es gibt nicht so viele Daten, man könnte es vorab rendern oder was auch immer. Also ein bisschen von beidem.

Drew: Natürlich haben viele Leute mit Legacy-Systemen zu tun, die … ein altes Datenbank-Ding, das in den 2000er Jahren gebaut wurde, auf das sie möglicherweise eine Art JSON-API-Schicht aufsetzen können …

Chris: Ja.

Drew: … und etwas Moderneres und vielleicht Serverloses bauen und dann immer noch mit diesen Legacy-Systemen interagieren, indem wir es irgendwie auf seltsame Weise zusammenkleben.

Chris: Ja. Das gefällt mir aber, oder? Sind nicht… die meisten Websites existieren bereits. Wie viele von uns betreiben völlig neue Websites? Die meisten von uns arbeiten an irgendeinem Mist, der bereits existiert und aus irgendeinem Grund in die Zukunft gezogen werden muss, weil ich nicht weiß, Entwickler wollen schneller arbeiten oder Sie können niemanden mehr in COBOL einstellen oder was auch immer die Geschichte ist ist. Du weisst?

Drew: In Bezug auf die Terminologie sprechen wir über JAMstack, bei dem es sich um diese Methode handelt, bei der ein Code so ziemlich im Browser ausgeführt und von einem CDN bereitgestellt wird. Also nichts Dynamisches auf dem Server. Und wenn wir dann über Serverless sprechen, sprechen wir über diese kleinen Funktionalitäten, die woanders auf ihrem Server laufen. Ist das richtig? Dass wir über diese Cloud-Funktion gesprochen haben –

Chris: Ja, ich meine, sie sind gerade beides ziemlich heiße Ideen. Es ist also ziemlich einfach, über das eine und über das andere zu sprechen. Aber sie müssen nicht unbedingt zusammen sein. Sie könnten eine JAMstack-Site betreiben, die nichts mit Serverless zu tun hat. Sie tun es einfach, Sie erstellen die Site einfach vor und führen sie aus, und Sie können serverlos verwenden, ohne sich um JAMstack kümmern zu müssen. Tatsächlich macht CodePen überhaupt nichts mit JAMstack. Nicht, dass wir unbedingt über CodePen sprechen wollen, aber es ist eine Ruby on Rails-App. Es läuft auf einer ganzen Reihe von AWS EC2-Instances und einer Vielzahl anderer Architekturen, um dies zu ermöglichen. Aber wir verwenden serverloses Zeug, wann immer wir können, für alles, was wir können, weil es billig und sicher ist und einfach eine gute Art zu arbeiten. Also überhaupt kein JAMstack im Einsatz, sondern überall serverlos.

Drew: Das ist ziemlich interessant. Welche Art von Aufgaben setzen Sie serverlos auf CodePen um?

Chris: Nun, es gibt eine ganze Reihe von Dingen. Eine davon ist, denke ich, hoffentlich ziemlich offensichtlich, ich brauche … der Sinn von CodePen ist, dass Sie jedes HTML, CSS und JavaScript im Browser schreiben und es vor Ihnen rendern, richtig? Sie können aber auch Präprozessorsprachen auswählen. Nehmen wir an, Sie mögen Sass. Sie aktivieren Sass im CSS und schreiben Sass. Naja, irgendwas muss die Sass verarbeiten. Heutzutage wird Sass in Dart oder so geschrieben.

Chris: Theoretisch könnte man das im Client machen. Aber diese Bibliotheken, die die Vorverarbeitung durchführen, sind ziemlich groß. Ich glaube nicht, dass ich Ihnen die gesamte Sass-Bibliothek schicken möchte, nur um das Ding zu betreiben. Ich will nicht… es ist einfach nicht, das ist nicht unbedingt die richtige Architektur dafür. Vielleicht ist es die Straße runter, ich meine, wir könnten über Offline-Mist reden, yada, yada, Web Workers. Es gibt eine Million architektonische Dinge, die wir tun könnten. Aber so funktioniert es jetzt, gibt es ein Lambda. Es verarbeitet Sass. Es hat einen winzigen, winzigen, winzigen, kleinen Job.

Chris: Du schickst ihm diesen Blob von Sass und es schickt dir Sachen zurück, das ist das verarbeitete CSS, vielleicht eine Sitemap, was auch immer. Es hat einen winzig kleinen Job und wir zahlen wahrscheinlich für dieses Lambda, so vier Cent oder so. Denn Lambdas sind einfach wahnsinnig günstig und man kann auch draufhauen. Sie müssen sich keine Sorgen um die Skalierung machen. Du triffst das Ding einfach so oft du willst und deine Rechnung wird erstaunlich günstig sein. Es gibt Momente, in denen Serverless beginnt, die Grenze zu überschreiten, zu teuer zu sein. Ich weiß nicht, was das ist, ich bin nicht so der Meister in solchen Sachen. Aber im Allgemeinen gelten alle serverlosen Dinge, die wir machen, im Grunde genommen alle fast als kostenlos, weil es so billig ist. Aber es gibt einen für Sass. Es gibt einen für weniger. Es gibt einen für Babbel. Es gibt eine für TypeScript. Es gibt einen für … All das sind individuelle Lambdas, die wir betreiben. Hier ist etwas Code, gib ihn dem Lambda, er kommt zurück, und wir tun, was immer wir damit tun wollen. Aber wir verwenden es für viel mehr als das, sogar in letzter Zeit.

Chris: Hier ist ein Beispiel. Jeder einzelne Stift auf CodePen hat einen Screenshot. Das ist irgendwie cool, oder? Also, die Leute machen etwas und dann brauchen wir ein PNG oder ein JPEG oder etwas davon, damit wir … so bekommen Sie eine kleine Vorschau davon, wenn Sie es twittern. Wenn Sie es in Slack teilen, erhalten Sie eine kleine Vorschau davon. Wir verwenden es auf der Website selbst zum Rendern … anstelle eines Iframes, wenn wir feststellen könnten, dass der Stift nicht animiert ist, weil das Bild eines Iframes viel heller ist, warum also nicht das Bild verwenden? Es ist sowieso nicht animiert. Nur solche Leistungsgewinne. Jeder dieser Screenshots hat also offensichtlich eine URL. Und wir haben es so konzipiert, dass diese URL tatsächlich eine serverlose Funktion ist. Es ist ein Arbeiter. Wenn diese URL aufgerufen wird, können wir also sehr schnell überprüfen, ob wir diesen Screenshot bereits gemacht haben oder nicht.

Chris: Das wird tatsächlich durch CloudFlare Workers ermöglicht, weil CloudFlare Workers nicht nur eine serverlose Funktion sind, sondern auch einen Datenspeicher haben. Sie haben dieses Ding namens Key-Value Store, also können wir die ID davon ganz schnell überprüfen und es wird sein: "Richtig oder falsch, haben Sie es oder nicht?" Wenn es es hat, serviert es es. Und es wird über CloudFlare bereitgestellt, was anfangs superschnell ist. Und gibt dir dann auch all diese Fähigkeit. Da es sich um ein Image-CDN handelt, können Sie sagen: „Stellen Sie es im optimalen Format bereit. Servieren Sie es als diese Dimensionen.“ Ich muss das Bild nicht in diesen Dimensionen machen. Sie geben einfach die Abmessungen in die URL ein und es kommt auf magische Weise in dieser Größe zurück. Das ist wirklich schön. Wenn es es nicht hat, fragt es eine andere serverlose Funktion, um es wirklich schnell zu machen. Also schafft es es und legt es dann irgendwo in einen Eimer … weil man einen Ursprung für das Bild haben muss, richtig? Sie müssen es normalerweise irgendwo hosten. Also legen wir es ganz schnell in einen S3-Eimer und servieren es dann.

Chris: Es gibt also keinen Warteschlangenserver, es gibt kein Nichts. Es ist, als würden serverlose Funktionen die Erstellung, Speicherung und Bereitstellung dieser Bilder verwalten. Und es gibt ungefähr 50 Millionen oder 80 Millionen von ihnen oder so. Es ist eine Menge, also behandelt es das ziemlich gut als Skalierung. Wir fassen es einfach nicht einmal an. Es passiert einfach. Es geht alles super schnell. Super nett.

Drew: Ich denke schon … nun, eine serverlose Funktion eignet sich idealerweise für eine Aufgabe, die nur sehr wenig Wissen über den Stand der Dinge erfordert. Ich meine, Sie haben die Fähigkeit von CloudFlare erwähnt, Schlüssel-Wert-Paare zu speichern, um zu sehen, ob Sie bereits etwas zwischengespeichert haben oder nicht.

Chris: Ja. Das versuchen sie aber damit zu lösen. Diese Schlüssel-Wert-Paare, ist das … Ich denke, das war traditionell wahr. Sie sagen: „Vermeide Zustand in der Sache“, weil du dich einfach nicht darauf verlassen kannst. Und CloudFlare-Arbeiter sagen: „Ja, eigentlich können Sie bis zu einem gewissen Grad mit dem Staat umgehen.“ Es ist nicht so schick wie ein … ich weiß nicht, es sind Schlüsselwerte, also ist es ein Schlüssel in einem Wert. Es ist nicht wie ein verschachteltes, relationales, ausgefallenes Ding. Dem sind also wohl Grenzen gesetzt. Aber das sind Babytage dafür. Ich denke, das Zeug wird sich weiterentwickeln, um mächtiger zu werden, also haben Sie eine gewisse Fähigkeit, einige zustandsähnliche Dinge zu tun.

Drew: Und manchmal drängt dich die Einschränkung, diese Art von eingeschränkter Fähigkeit, den Zustand aufrechtzuerhalten, oder die Tatsache, dass du keinen … du willst überhaupt keinen Zustand aufrechtzuerhalten, irgendwie in eine Architektur, die dir diese Art von … Nun, wann wir sprechen von der Software-Philosophie von „Small Pieces Loosely Joined“, nicht wahr?

Chris: Mm (bestätigend).

Drew: Wo jede kleine Komponente eine Sache macht und es gut macht. Und weiß nicht wirklich etwas über den Rest des Ökosystems um ihn herum. Und es scheint, dass dies wirklich auf dieses Konzept der serverlosen Funktionen zutrifft. Sind Sie einverstanden?

Chris: Ja. Ich denke, Sie könnten eine philosophische Debatte führen, ob das eine gute Idee ist oder nicht. Du weisst? Ich denke, manche Leute mögen den Monolithen sozusagen. Ich denke, es ist möglich ... es gibt Möglichkeiten, dies zu übertreiben und zu viele kleine Teile zu machen, die zu schwer zu testen sind. Es ist schön, einen Test zu haben, der so lautet: „Oh, ich frage mich, ob meine Sass-Funktion funktioniert. Nun, schreiben wir einfach einen kleinen Test dafür und stellen sicher, dass es so ist.“ Aber sagen wir, was für den Benutzer wichtig ist, ist eine Reihe von sieben davon. Wie testet man alle sieben zusammen? Ich glaube, die Geschichte wird etwas komplizierter. Ich weiß nicht, wie ich mit all dem Zeug superintelligent sprechen soll, aber ich weiß, dass es nicht unbedingt so ist, wenn Sie mit allen serverlosen Funktionen rollen, dass dies automatisch eine bessere Architektur ist als jede andere Architektur. Ich mag das. Das ist für mich gut nachvollziehbar, aber ich weiß nicht, ob es das A und O aller Architekturen ist. Du weisst?

Drew: Für mich fühlt es sich extrem web-ähnlich an, insofern … genau so funktioniert HTML, nicht wahr? Sie liefern etwas HTML und der Browser ruft dann Ihre Bilder ab und ruft Ihr JavaScript ab und ruft Ihr CSS ab. Es scheint, als wäre es eine Erweiterung davon -

Chris: Es ist schön.

Drew: … so eine Idee. Aber eine Sache, die wir über das Internet wissen, ist, dass es widerstandsfähig ist, weil das Netzwerk zerbrechlich ist.

Chris: Mm (bestätigend).

Drew: Wie robust ist die Art des serverlosen Ansatzes? Was passiert, wenn etwas … wenn eines dieser kleinen Stücke verschwindet?

Chris: Das wäre sehr schlecht. Du weisst? Es wäre eine Katastrophe. Ihre Website würde wie jeder andere Server ausfallen, wenn sie ausfällt, denke ich.

Drew: Gibt es Möglichkeiten, das abzumildern, insbesondere -

Chris: Ich weiß es nicht.

Drew: … geeignet für diese Art von Herangehensweise, auf die Sie gestoßen sind?

Chris: Vielleicht. Ich meine, wie ich schon sagte, eine wirklich super schicke, robuste Sache könnte so aussehen … sagen wir, Sie besuchen CodePen und sagen wir, es gibt eine JavaScript-Implementierung von Sass und wir haben festgestellt, dass Sie sich in einem ziemlich schnellen Netzwerk befinden und dass Sie untätig sind im Augenblick. Vielleicht schnappen wir uns das JavaScript und werfen es einem Servicemitarbeiter zu. Wenn wir dann feststellen, dass das Lambda fehlschlägt oder so etwas, oder dass Sie dieses Ding bereits installiert haben, greifen wir auf den Service-Worker statt auf das Lambda zu, und Service-Worker können offline arbeiten. Also das ist auch irgendwie nett. Das ist interessant. Ich meine, sie sind die gleiche Sprache. Servicemitarbeiter sind JavaScript und viele Cloud-Funktionen sind JavaScript, also gibt es einige … Ich denke, das ist eine Möglichkeit, obwohl das … es ist nur, das ist eine ernsthafte technische Sache … Es macht mir einfach Angst, diesen Brocken JavaScript zu haben, den Sie geliefert haben für wie viele tausend Benutzer, dass Sie nicht unbedingt wissen, was sie haben und welche Version sie haben. Eww, aber das ist nur meine eigene Angst. Ich bin mir sicher, dass einige Leute mit so etwas gute Arbeit geleistet haben.

Chris: Ich weiß es wirklich nicht. Vielleicht kennen Sie einige Strategien zur Ausfallsicherheit von Serverless, die ich nicht kenne.

Drew: Ich denke, es gibt einen Fehlermodus, eine Art Fehler, der bei serverlosen Funktionen auftreten kann, bei dem Sie eine Funktion einmal ausführen und sie schlägt fehl, und Sie können sie unmittelbar danach ein zweites Mal ausführen und sie würde erfolgreich sein, weil sie möglicherweise getroffen wird ein ganz anderer Server. Oder was auch immer das Problem war, wenn dieser Lauf bei einer zweiten Anfrage möglicherweise nicht vorhanden ist. Die Probleme mit dem Ausfall eines ganzen Hosts sind eine Sache, aber vielleicht gibt es … Sie haben individuelle Probleme mit der Maschine. Sie haben einen bestimmten Server, dessen Speicher ausgefallen ist und der eine Menge Fehler auswirft, und wenn Sie ihn zum ersten Mal treffen, wird er fehlschlagen. Beim zweiten Mal könnte dieses Problem verwurzelt sein.

Chris: Unternehmen, die diese Technologie anbieten, muss man vertrauen, aber sie sind auch die Art von Unternehmen, die … das ist ihr Stolz. Dies ist der Grund, warum Menschen sie verwenden, weil sie zuverlässig sind. Ich bin mir sicher, dass die Leute auf einige AWS-Ausfälle der Vergangenheit hinweisen könnten, aber sie sind eher selten und nicht sehr häufig. Wenn Sie Ihren eigenen Mist hosten, wetten sie, dass Sie von einer Art SLA-Prozentsatz geschlagen wurden. Du weisst? Es heißt also nicht „Bauen Sie nicht belastbar“, aber im Allgemeinen sind die Unternehmen, die diese Dinge anbieten, verdammt zuverlässig. Die Wahrscheinlichkeit, dass Sie ausfallen, weil Sie diese Funktion vermasselt haben, ist viel höher als weil ihre Architektur versagt.

Drew: Ich nehme an, ich meine, genau wie bei allem, wo Sie eine API oder etwas verwenden, das fehlschlagen kann, müssen Sie nur sicherstellen, dass Sie Ihren Code strukturieren, um mit diesem Fehlermodus fertig zu werden und zu wissen, was als nächstes passiert, anstatt nur zu werfen bis ein Fehler für den Benutzer, oder einfach sterben, oder was hast du. Es ist sich dessen bewusst und fordert den Benutzer auf, es erneut zu versuchen. Oder versuchen Sie es selbst noch einmal oder so.

Chris: Ja, ich mag diese Idee, es mehr als einmal zu versuchen, anstatt nur zu sagen: „Oh nein. Scheitern. Abbrechen." „Ich weiß nicht, warum versuchst du es nicht nochmal dort, Kumpel?“

Drew: Ich meine, wenn es um das Testen und Entwickeln von serverlosen Funktionen, einer Art Cloud-Funktionen, geht, ist das etwas, das lokal durchgeführt werden kann? Muss es in der Cloud gemacht werden? Gibt es Möglichkeiten, das zu verwalten?

Chris: Ich denke, es gibt einige Möglichkeiten. Ich weiß nicht, ob die Geschichte so toll ist. Es ist immer noch ein relativ neues Konzept, also denke ich, dass es immer besser wird. Aber soweit ich weiß, schreiben Sie zum einen eine ziemlich normale Node-Funktion. Angenommen, Sie verwenden JavaScript, um dies zu tun, und ich weiß, dass sie speziell auf Lambda alle möglichen Dinge unterstützen. Sie können eine verdammte PHP-Cloud-Funktion schreiben. Sie können eine Ruby Cloud Function schreiben. Ich weiß also, dass ich speziell über JavaScript spreche, weil ich das Gefühl habe, dass die meisten dieser Dinge JavaScript sind. Sogar egal, welche Sprache es ist, ich meine, Sie können lokal auf Ihre Befehlszeile gehen und das Ding ausführen. Einige dieser Tests sind … Sie testen es einfach wie jeden anderen Code. Sie rufen die Funktion einfach lokal auf und sehen, ob sie funktioniert.

Chris: Es ist eine etwas andere Geschichte, wenn Sie über eine HTTP-Anfrage sprechen, das ist das, was Sie zu testen versuchen. Reagiert es richtig auf die Anfrage? Und gibt es das Zeug richtig zurück? Ich weiß nicht. Da könnte das Netzwerk eingreifen. Vielleicht möchten Sie also Tests auf diesem Niveau schreiben. Das ist gut. Ich weiß nicht. Was ist die normale Geschichte dort? Sie starten eine Art lokalen Server oder etwas, das ihm dient. Verwenden Sie Postman, ich weiß nicht. Aber es gibt… Frameworks versuchen auch zu helfen. Ich weiß, dass das serverlose „.com“ einfach furchtbar verwirrend ist, aber es gibt buchstäblich eine Firma namens Serverless, die ein Framework zum Schreiben der serverlosen Funktionen erstellt, das Ihnen bei der Bereitstellung hilft.

Chris: Wenn Sie also NPM serverlos installieren möchten, erhalten Sie deren Framework. Und es wird allgemein als sehr gut angesehen, weil es einfach sehr hilfreich ist, aber sie haben keine eigene Cloud oder was auch immer. Sie schreiben diese und dann hilft es Ihnen, sie zu einem echten Lambda zu bringen. Oder es funktioniert mit mehreren Cloud-Anbietern. Ich weiß es heutzutage nicht einmal, aber ihr Zweck besteht darin, die Bereitstellungsgeschichte einfacher zu machen. Ich weiß nicht was… AWS ist nicht für seine Einfachheit bekannt. Du weisst? Es gibt diese ganze Welt an Tools, die Ihnen bei der Verwendung von AWS helfen, und sie sind eine davon.

Chris: Sie haben eine Art kostenpflichtiges Produkt. Ich weiß nicht einmal, was es genau ist. Ich denke, eines der Dinge, die sie tun, ist … der Zweck ihrer Verwendung ist das Testen, eine Entwicklungsumgebung zu haben, die zum Testen Ihrer serverlosen Funktion dient.

Drew: Ja, weil ich denke, dass das ein ziemlich großer Teil des Workflows ist, nicht wahr? Wenn Sie Ihre JavaScript-Funktion geschrieben und lokal getestet haben, wissen Sie, dass sie die Aufgabe erfüllen wird. How do you actually pick which provider it's going to go into and how do you get it onto that service? Now, I mean, that's a minefield, isn't it?

Chris: Ja. I mean, if you want to use no tooling at all, I think they have a really… like AWS, specifically, has a really rudimentary GUI for the thing. You can paste the code in there and hit save and be like, “Okay, I guess it's live now.” That's not the best dev story, but I think you could do it that way. I know CloudFlare workers have this thing called Wrangler that you install locally. You spin it up and it spins up a fake browser on the top and then dev tools below. Then you can visit the URL and it somehow intercepts that and runs your local cloud function against it. Because one of the interesting things about workers is… you know how I described how it… you don't hit a URL and then it returns stuff. It just automatically runs when you… when it intercepts the URL, like CDN style.

Chris: So, one of the things it can do is manipulate the HTML on the way through. The worker, it has access to the complete HTML document. They have a jQuery-esque thing that's like, “Look for this selector. Get the content from it. Replace it with this content. And then continue the request.” So you can mess with code on the way through it. To test that locally, you're using their little Wrangler tool thing to do that. Also, I think the way we did it was… it's also a little dangerous. The second you put it live, it's affecting all your web traffic. It's kind of a big deal. You don't want to screw up a worker. You know? You can spin up a dev worker that's at a fake subdomain, and because it's CloudFlare, you can… CloudFlare can just make a subdomain anyway. Ich weiß nicht. It's just kind of a nice way to do a… as you're only affecting sub-domain traffic, not your main traffic yet. But the subdomain's just a mirror of a production anyway, so that's kind of a… that's a testing story there.

Chris: It brings up an interesting thing, though, to me. It's like… imagine you have two websites. One of them is… for us it's like a Ruby on Rails app. Whatever. It's a thing. But we don't have a CMS for that. That's just like… it's not a CMS, really. I think there's probably Ruby CMSs, but there's not any renowned ones. You know? It seems like all the good CMSs are PHP, for some reason. So, you want a quality CMS. Drew, you've lived in the CMS market for a long time -

Drew: Absolutely.

Chris: … so you know how this goes. Let's say you want to manage your sites in Perch or whatever, because it's a good CMS and that's the proper thing to use to build the kind of pages you want to build. But you don't want to run them on the same server. Unless you want to manage the pages on one site, but show them on another site. Well, I don't know, there's any number of ways to do that. But one JavaScript way could be, “Okay, load the page. There's an empty div there. Run some JavaScript. Ask the other site for the content of that page and then plunk it out on the new page.” That's fine, I guess, but now you're in a client side rendered page. It's going to be slow. It's going to have bad SEO, because… Google will see it eventually, but it takes 10 days or something. It's just a bad story for SEO. It's not very resilient, because who knows what's going to happen in the network. It's not the greatest way to do this kind of “content elsewhere, content on site B, show page of site A”, situation.

Chris: You could also do it on the server side, though. Let's say you had… Ruby is capable of granting a network request too, but that's even scarier because then if something fails on the network, the whole page could die or something. It's like a nervous thing. I don't love doing that either. But we did this just recently with a worker, in that we… because the worker's JavaScript, it can make a fetch request. So, it fetches site A, it finds this div on the page, and then it goes and asks site B for the content. Gets the content. Plugs it into that div, and serves the page before it gets anything. So it looks like a server rendered page, but it wasn't. It all happened at the… on the edge, at the worker level, at the serverless level.

Chris: So it's kind of cool. I think you can imagine a fetch request on the browser probably takes, I don't know, a second and a half or something. It probably takes a minute to do it. But because these are… site B is hosted on some nice hosting and Cloudflare has some… who knows what kind of super computers they use to do it. They do. Those are just two servers talking to each other, and that fetch request happens just so super duper, duper fast. It's not limited to the internet connection speed of the user, so that little request takes like two milliseconds to get that data. So it's kind of this cool way to stitch together a site from multiple sources and have it feel like, and behave like, a server rendered page. I think there's a cool future to that.

Drew: Are there any sort of conventions that are sort of springing up around serverless stuff. I'm sort of thinking about how to architect things. Say I've got something where I want to do two sort of requests to different APIs. I want to take in a postal address and geocode it against one, and then take those coordinates and send that to a florist who's going to flower bomb my front yard or something. How would you build that? Would you do two separate things? Or would you turn that into one function and just make the request once from the browser?

Chris: Mm (affirmative). That's a fascinating question. I'd probably have an architect function or something. One function would be the one that's in charge of orchestrating the rest of them. It doesn't have to be, your website is the hub and it only communicates to this array of single sources. Serverless functions can talk to other serverless functions. So I think that's somewhat common to have kind of an orchestrator function that makes the different calls and stitches them together, and returns them as one. I think that is probably smart and faster, because you want servers talking to servers, not the client talking to a whole bunch of servers. If it can make one request and get everything that it needs, I think that's probably generally a good idea-

Drew: Yeah, that sounds smart. Ja.

Chris: But I think that's the ultimate thing. You get a bunch of server nerds talking, they'll talk about the different approaches to that exact idea in 10 different ways.

Drew: Ja. No, that sounds pretty smart. I mean, you mentioned as well that this approach is ideal if you're using APIs where you've got secret information. You've got API keys or something that you don't want to live in the client. Because I don't know, maybe this florist API charges you $100 dollars every time flower bomb someone.

Chris: Easily.

Drew: You can basically use those functions to almost proxy the request and add in the secret information as it goes, and keep it secret. That's a viable way to work?

Chris: Yeah, yeah. I think so. I mean, secrets are, I don't know, they're interesting. They're a form of buy in I think to whatever provider you go with, because… I think largely because of source control. It's kind of like, you could just put your API key right in the serverless function, because it's just going to a server, right? You don't even have to abstract it, really. The client will never see that code that executes, but in order for it to get there, there's probably a source control along the way. It's probably like you commit to master, and then master… then some kind of deployment happens that makes that thing go to the serverless function. Then you can't put your API key in there, because then it's in the repo, and you don't put your API keys in repos. That's good advice. Now there's stuff. We've just done… at CodePen recently, we started using this git-crypt thing, which is an interesting way to put keys safely into your repos, because it's encrypted by the time anybody's looking at that file.

Chris: But only locally they're decrypted, so they're useful. So it's just kind of an interesting idea. I don't know if that helps in this case, but usually, cloud providers of these things have a web interface that's, “Put your API keys here, and we'll make them available at runtime of that function.” Then it kind of locks… it doesn't lock you in forever but it kind of is… it's not as easy to move, because all your keys are… you put in some input field and some admin interface somewhere.

Drew: Yeah, I think that's the way that Netlify manage it.

Chris: They all do, you know?

Drew: Ja. You have the secret environment variables that you can set from the web interface. That seems to work quite nicely.

Chris: Yeah, right. But then you got to leave… I don't know, it's not that big of a deal. I'm not saying they're doing anything nefarious or anything. How do you deal with those secrets? Well, it's a hard problem. So they kind of booted it to, I don't know, “Just put them in this input field and we'll take care of it for you, don't worry about it.”

Drew: Is there anything that you've seen that stands out as an obvious case for things that you can do with serverless, that you just couldn't do with a traditional kind of serverfull approach? Or is it just taking that code and sort of almost deploying it in a different way?

Chris: It's probably mostly that. I don't know that it unlocks any possibility that you just absolutely couldn't run it any other way. Yeah, I think that's a fair answer, but it does kind of commoditize it in an interesting way. Like, if somebody writes a really nice serverless function… I don't know that this exists quite yet, but there could kind of a marketplace, almost, for these functions. Like, I want a really good serverless function that can take a screenshot. That could be an open source project that lots of eyeballs around, that does a tremendously good job of doing it and solves all these weird edge cases. That's the one I want to use. I think that's kind of cool. You know? That you can kind of benefit from other people's experience in that way. I think that will happen more and more.

Drew: I guess it's the benefit that we talked about, right at the top, of enabling people who write JavaScript and may have written JavaScript only for the front-end, to expand and use those skills on the back-end as well.

Chris: Ja, ja. Ich denke schon, ich denke, das ist … weil es Momente gibt wie … man muss nicht sehr geschickt sein, um zu wissen, was für eine Website angemessen ist und was nicht. Zum Beispiel habe ich neulich ein kleines Tutorial gemacht, wo es diesen Glitch gab, der diese verwendet … Wenn Sie einen Glitch speichern, geben sie Ihnen einen Slug für Ihr Ding, das Sie gebaut haben, das heißt: „Whiskey, Tango, Foxtrott. 1.000.“ Es ist wie ein cleveres kleines Ding. Die Chancen, dass es einzigartig ist, sind super hoch, weil ich denke, dass sie sogar eine Nummer oder so etwas anhängen. Aber am Ende sind sie diese lustigen kleinen Dinger. Sie öffnen ihre Bibliothek, die all diese Wörter enthält, aber es sind wie hundert, tausend Wörter. Die Datei ist riesig. Du weisst? Es ist Megabyte groß und besteht nur aus einem Wörterbuch von Wörtern. Sie lernen wahrscheinlich in Ihrem ersten Jahr der Entwicklung: „Versenden Sie keine JavaScript-Datei, die Megabytes eines Wörterbuchs ist.“ Das ist nicht gut zu versenden. Du weisst? Aber Node ist es egal. Sie können Hunderte von ihnen versenden. Es ist irrelevant für die Geschwindigkeit auf einem Server.

Drew: Ja.

Chris: Auf einem Server spielt das keine Rolle. Also könnte ich sagen: „Hmm, gut, dann mache ich das einfach in Node.“ Ich habe eine Anweisung, die besagt: „Wörter gleich sind, erfordern Wörter“ oder was auch immer, und oben eine Notiz: „Lass es eine Zahl randomisieren. Ziehen Sie es aus dem Array und geben Sie es zurück.“ Diese serverlose Funktion besteht also aus acht Codezeilen mit einem verpackten @JSON, das diese Open-Source-Bibliothek einzieht. Und dann gibt es in meinem Front-End-Code eine URL zur serverlosen Funktion. Es trifft diese URL. Die URL gibt ein Wort oder eine Gruppe von Wörtern oder was auch immer zurück. Sie bauen Ihre eigene kleine API dafür. Und jetzt habe ich ein wirklich nettes, effizientes Ding. Das Schöne daran war, dass es so einfach ist. Um die Sicherheit mache ich mir keine Sorgen. Ich weiß nicht … weißt du?

Chris: Es ist nur… ein sehr durchschnittlicher JavaScript-Entwickler oder ein Anfänger, denke ich, kann das schaffen, was cool ist. Das ist eine Möglichkeit, die sie vorher nicht hatten. Früher sagten sie: „Nun, hier ist eine 2-MB-Anordnung von Wörtern.“ „Oh, das kann ich dem Kunden nicht schicken.“ „Oh, dann hörst du einfach auf.“ Du könntest gegen diese Wand stoßen, die so ist wie: „Dann kann ich diesen Teil einfach nicht machen. Ich muss jemand anderen bitten, mir dabei zu helfen oder es einfach nicht zu tun oder langweiligere Schnecken zu pflücken oder so…“ Es ist nur, du musst einen anderen Weg gehen, der für dich eine Mauer ist, weil du es nicht tun könntest. Und jetzt sagen Sie: „Oh, nun, ich werde einfach …“ Anstatt das in meinem Skript-Slash oder in meinem Quell-Slash-Skriptordner zu haben, lege ich es stattdessen in meinen Funktionsordner.

Chris: Sie haben das Skript sozusagen von einem Ordner in den anderen verschoben. Und diese wird stattdessen als serverlose Funktion bereitgestellt. Wie cool ist das? Du weisst? Sie verwenden fast genau die gleichen Fähigkeiten. Es gibt immer noch einige Ecken und Kanten, aber es ist ziemlich nah dran.

Drew: Es ist super cool. Sie haben eine Art kleine Microsite zu diesen Ideen zusammengestellt, nicht wahr?

Chris: Ja. Ich war etwas zu früh im Spiel. Ich habe aber erst heute daran gearbeitet, weil … es Pull-Requests bekommt. Die Idee… naja, sie ist bei serverless.css-tricks.com und… es gibt übrigens einen Bindestrich in CSS-Tricks. Es ist also eine Subdomain von CSS-Tricks, und ich habe sie auch serverlos erstellt, also ist dies … CSS-Tricks ist wie eine WordPress-Site, aber dies ist eine statische Site-Generator-Site. Der gesamte Inhalt davon befindet sich im GitHub-Repo, das Open Source ist. Wenn Sie also den Inhalt der Website ändern möchten, können Sie einfach eine Umfrageanfrage stellen, was nett ist, da es im Laufe der Zeit ungefähr hundert davon gab. Aber ich habe alle Originalinhalte erstellt.

Drew: Es ist ein super nützlicher Ort, weil es auflistet … Wenn Sie denken: „Richtig, ich möchte mit serverlosen Funktionen anfangen“, listet es alle Anbieter auf, die Sie ausprobieren könnten und …

Chris: Das ist so ziemlich alles, was es ist, Listen von Technologien. Ja.

Drew: Das ist großartig, denn sonst googelt man einfach nach irgendetwas und weiß nicht, was man findet. Ja, es sind Listen von API-Anbietern, die Ihnen bei solchen Dingen helfen.

Chris: Forms ist ein Beispiel dafür, weil… also in dem Moment, in dem Sie sich entscheiden,… sagen wir, Sie gehen zu JAMstack, von dem ich weiß, dass das nicht unbedingt der Punkt ist, aber Sie sehen, wie Hand in Hand sie gehen . Plötzlich haben Sie keine PHP-Datei oder was auch immer, um dieses Formular zu verarbeiten. Wie erstellen Sie Formulare auf einer JAMstack-Site? Nun, es gibt eine Reihe von Möglichkeiten, dies zu tun. Anscheinend wollen dir alle und ihre Schwestern helfen, dieses Problem zu lösen. Ich denke also, wenn ich der Erfinder des Wortes JAMstack wäre, dann versuchen sie, Ihnen auf natürliche Weise zu helfen, aber Sie müssen sie nicht verwenden.

Chris: Tatsächlich war ich so überrascht, diese Seite zusammenzustellen. Mal sehen. Es gibt sechs, neun, zwölf, fünfzehn, achtzehn, einundzwanzig, zweiundzwanzig Dienste da draußen, die Ihnen dabei helfen möchten, Ihre Formulare auf dieser Seite jetzt serverlos zu verarbeiten. Wenn Sie der 23. sein wollen, können Sie das gerne tun, aber Sie haben da draußen einige Konkurrenz. Die Idee dahinter ist also, dass Sie ein Formular in HTML schreiben, buchstäblich wie ein Formularelement. Und dann das Aktionsattribut des Formulars, es kann intern nirgendwo hinzeigen, weil es nichts gibt, worauf es zeigen könnte. Sie können nicht verarbeiten, also zeigt es nach außen. Es zeigt auf was auch immer sie wollen, dass Sie es zeigen. Sie bearbeiten das Formular und tun dann in der Regel Dinge, die Sie von ihnen erwarten würden, z. B. das Senden einer E-Mail-Benachrichtigung. Oder sende ein Slack-Ding. Oder senden Sie es dann an Zapier und Zapier sendet es woanders hin. Sie alle haben leicht unterschiedliche Funktionen, Preise und andere Dinge, aber sie versuchen alle, dieses Problem für Sie zu lösen, wie zum Beispiel: „Sie möchten Ihre eigenen Formulare nicht verarbeiten? Kein Problem. Wir verarbeiten es für Sie.“

Drew: Ja, es ist eine super nützliche Ressource. Ich würde wirklich jedem empfehlen, es sich anzusehen. Es ist serverless.css-tricks.com. Also habe ich alles über Serverless gelernt. Was hast du in letzter Zeit gelernt, Chris?

Chris: Nun, ich bin auch immer noch sehr viel in dieser Welt und lerne etwas über serverloses Zeug. Ich hatte eine Idee … Ich habe dieses Online-Rollenspiel vor Ewigkeiten gespielt. Ich habe erst kürzlich entdeckt, dass es noch lebt. Es ist ein textbasiertes mittelalterliches Fantasy-Spiel. Ich habe es gespielt, als AOL in Mode war, weil AOL diese Spiele haben wollte, bei denen man angemeldet sein musste, um es zu spielen, weil sie wollten, dass man Stunden um Stunden bei AOL verbringt, damit sie einem diese riesigen Rechnungen schicken konnten, was war , ich bin mir sicher, warum sie irgendwann so gut abschnitten.

Drew: Also sekundengenaue Abrechnung. Ja.

Chris: Ja. Spiele waren also groß für sie. Wenn sie dich dazu bringen könnten, dort Spiele mit anderen Leuten zu spielen. Also dieses Spiel… es debütierte dort nicht, aber es wechselte zu AOL, weil ich sicher bin, dass sie einen saftigen Deal dafür bekommen haben, aber es war so… ich meine, es ist einfach, es könnte unmöglich nerdischer sein. Du bist ein Zwergenmagier und bekommst Runenstab aus deiner Lederscheide. Und Sie geben Befehle wie in ein Terminal ein. Dann reagiert das Spiel auf Sie. Ich habe das Spiel sehr lange gespielt. Ich war sehr darin. Ich kam in die Gemeinschaft und den Geist davon. Es war irgendwie … es war, als wäre ich nur alleine an meinem Computer, aber dennoch blicke ich auf diese Zeit in meinem Leben zurück und sage: „Das war eine wundervolle Zeit in meinem Leben.“ Ich war wirklich … ich mochte einfach die Leute und das Spiel und all das. Aber dann bin ich erwachsen geworden und habe aufgehört, es zu spielen, weil das Leben einem passiert.

Chris: Ich habe es erst kürzlich herausgefunden, weil jemand wieder angefangen hat, einen Podcast darüber zu machen … Ich weiß nicht, wie ich darauf gekommen bin, aber ich habe es einfach getan. Ich sagte: „Dieses Spiel ist in der heutigen Welt lebendig und gut, willst du mich verarschen? Dieses textbasierte Ding.“ Und ich war mehr als glücklich, reaktivieren und meine alten Charaktere zurückbekommen und spielen zu können. Aber nur um herauszufinden, dass sich die Clients, die Sie für dieses Spiel herunterladen lassen, überhaupt nicht weiterentwickelt haben. Sie sind schrecklich. Sie gehen fast davon aus, dass Sie Windows verwenden. Es gibt nur diese furchtbar kitschige, schlechte Wiedergabe … und es basiert auf Text, Sie denken, es hätte zumindest eine schöne Typografie. Nein. Also denke ich: „Ich könnte dabei sein. Ich könnte einen Client für dieses Spiel schreiben. Fügen Sie schöne Typografie hinzu.“ Modernisieren Sie das Ding einfach, und ich denke, die Spieler des Spiels würden es zu schätzen wissen, aber es fühlte sich für mich überwältigend an. "Wie kann ich es tun?" Aber ich finde einige Open-Source-Projekte. Eines davon ist wie … Sie können das Spiel über ein tatsächliches Terminalfenster spielen, und es verwendet einige Open-Source-Bibliotheken, um eine Art GUI aus einem Terminalfenster zu machen.

Drew: Wirklich?

Chris: Ich weiß es nicht. Also das war irgendwie cool. Ich dachte: „Wenn sie das geschrieben haben, muss es einen Code geben, wie man sich mit dem Spiel verbindet und alles zum Laufen bringt und so. Also habe ich zumindest einen Startcode.“ Ich habe versucht, der App zu folgen: „Vielleicht mache ich es in Flutter oder so“, damit die Endprodukt-App auf Mobiltelefonen funktioniert, und: „Ich könnte dieses Ding wirklich modernisieren.“ Aber dann wurde ich überwältigt. Ich sagte: „Ah, das ist zu groß … ich kann nicht. Ich bin beschäftigt." Aber ich fand eine andere Person, die die gleiche Idee hatte, und sie war schon viel weiter, also konnte ich nur auf Designebene beitragen. Und es hat wirklich Spaß gemacht, daran zu arbeiten, aber ich habe auch viel gelernt, weil ich selten in ein Projekt einsteige, das das Baby von jemand anderem ist, und ich trage nur ein bisschen dazu bei, und das hat etwas ganz anderes Technologieentscheidungen, als ich jemals getroffen hätte.

Chris: Es ist eine Electron-App. Sie haben sich dafür entschieden, was auch irgendwie cool ist, weil es meine Webfähigkeiten sind ... also lerne ich nichts zu seltsames, und es ist plattformübergreifend, was großartig ist. Ich habe also viel über Electron gelernt. Ich denke, es macht Spaß.

Drew: Das ist faszinierend. Es ist immer wieder erstaunlich, wie kleine Nebenprojekte und Dinge, die wir zum Spaß machen, am Ende der Ort sind, an dem wir manchmal am meisten lernen. Und lernen Sie Fähigkeiten, die dann in unsere tägliche Arbeit einfließen können.

Chris: Nur so lerne ich etwas. Ich werde in etwas hineingezogen, das… ich dachte: „Sie sind nicht…“ Es wird mit einer JavaScript-Bibliothek namens Mithril gerendert, was… ich weiß nicht, ob Sie jemals davon gehört haben, aber es ist seltsam. Es ist nicht … es ist fast so, als würde man React ohne JSX schreiben. Sie müssen „Elemente erstellen“ und all dies tun … aber es soll viel besser als es Benchmarking sein … Und es ist tatsächlich wichtig, denn in diesem textbasierten Spiel fliegt der Text einfach. Es gibt eine Menge Datenmanipulationen, das ist wie … man könnte meinen, dieses textbasierte Spiel wäre so einfach, dass es in einem Browserfenster ausgeführt werden könnte, aber das ist es eigentlich nicht. Es findet so viel Datenmanipulation statt, dass man wirklich wirklich sein muss… wir müssen gewissenhaft mit der Geschwindigkeit des Renderings umgehen. Du weisst?

Drew: Das ist faszinierend-

Chris: Ziemlich cool.

Drew: Ja. Wenn Sie, lieber Zuhörer, mehr von Chris hören möchten, finden Sie ihn auf Twitter, wo er @chriscoyier ist. Natürlich sind CSS-Tricks unter css-tricks.com und CodePen unter codepen.io zu finden. Aber vor allem empfehle ich Ihnen, den ShopTalk Show-Podcast auf shoptalkshow.com zu abonnieren, falls Sie dies noch nicht getan haben. Danke, dass du heute dabei bist, Chris. Hast du Abschiedsworte?

Chris: Smashingpodcast.com. Ich hoffe, das ist die echte URL.