JAMstack-Grundlagen: Was, was und wie

Wir lieben es, die Grenzen des Webs zu erweitern, und deshalb haben wir uns entschieden, etwas Neues auszuprobieren. Sie haben wahrscheinlich schon von JAMstack gehört – dem neuen Webstack auf Basis von JavaScript, APIs und Markup – aber was bedeutet es für Ihren Workflow und wann ist es in Ihren Projekten sinnvoll?

Als Teil unserer Smashing-Mitgliedschaft veranstalten wir jede Woche Smashing TV , eine Reihe von Live-Webinaren. Kein Schnickschnack – nur praktische, umsetzbare Webinare mit Live-Fragen und Antworten, die von angesehenen Praktikern aus der Branche geleitet werden. In der Tat sieht das Smashing-TV-Programm bereits ziemlich dicht aus und ist für Smashing-Mitglieder kostenlos, zusammen mit Aufnahmen – offensichtlich .

Wir haben Phil Hawksworth freundlich gebeten, ein Webinar zu veranstalten, in dem erklärt wird, was JAMStack tatsächlich bedeutet und wann es sinnvoll ist und wie es sich auf Tools und die Front-End-Architektur auswirkt. Das einstündige Webinar ist jetzt ebenfalls verfügbar. Wir könnten nicht glücklicher sein, Phil als Co-Moderator unserer bevorstehenden SmashingConf Toronto (25.-26. Juni) und der JAMStack_conf London zu begrüßen, die wir dieses Jahr ebenfalls vom 9.-10. Juli mitorganisieren. Also, lass uns hineingehen!

Phil Hawksworth: Ausgezeichnet, okay, dann lass uns damit anfangen. Nur als ganz schnelles Hallo, ich meine, ich habe schon Hallo gesagt, Scott hat mich nett vorgestellt. Aber ja, ich arbeite derzeit bei Netlify, ich arbeite dort im Developer Experience Team. Wir werden hoffentlich viel Zeit für Fragen und Antworten haben, aber, wie Scott erwähnt hat, wenn Sie dort keine Gelegenheit haben, Fragen zu stellen, oder wenn Sie es einfach vorziehen, können Sie mich direkt auf Twitter anpingen, also mein Twitter-Handle ist mein Name, es ist Phil Hawksworth, also können Sie mir jederzeit Fragen zu JAMstack oder überhaupt irgendetwas auf Twitter stellen.

Phil Hawksworth: Aber ich möchte heute damit beginnen, dass ich ein wenig in der Zeit zurückgehe zu diesem Zitat, das wirklich sehr, sehr stark in mir nachhallt. Dies ist ein Zitat des wunderbaren Aaron Schwartz, der natürlich so viel zu Creative Commons und dem offenen Web beigetragen hat, und er schrieb dies bereits 2002 in seinem Blog und sagte: „Es ist mir wichtig, nicht launisch bleiben zu müssen AOL-Server, Postgres und Oracle-Installationen.“ AOL-Server, ich musste nachschlagen, um mich daran zu erinnern, war zu dieser Zeit ein Open-Source-Webserver.

Phil Hawksworth: Aber das kommt mir wirklich sehr entgegen. Ich möchte auch keine Infrastruktur unterhalten, um einen Blog am Leben zu erhalten, und genau das meinte er. Und es war in diesem Blogpost auf seinem eigenen Blog und es trug den Titel „Bake, Don't Fry“. Er wählte einen Begriff aus, den jemand, der kürzlich ein CMS erstellt hatte, zu verwenden begann, und er machte diesen Begriff über das Backen populär (Bake, Don't Fry); Er spricht dort eher von Pre-Rendering als von Rendering auf Abruf, also Backen des Inhalts im Voraus, anstatt ihn auf Abruf zu braten, wenn Leute kommen und danach fragen – Dinge weg von der Anfragezeit und in eine Art Build-Zeit zu bringen.

Phil Hawksworth: Und wenn wir über Pre-Rendering und Rendering sprechen, meinen wir damit, dass wir über das Generieren von Markup sprechen. Ich fühle mich manchmal etwas unsicher, wenn ich über eine Art Server-Rendering oder isomorphes Rendering oder viele dieser Schlagwortbegriffe spreche. Ich wurde vor ein paar Jahren zu einer Konferenz, der Frontiers Conference in Amsterdam, gerufen, als ich über das Rendern auf dem Server sprach, und jemand sagte zu mir: „Du meinst das Generieren von HTML? Nur etwas, das HTML ausgibt?“ Und das meine ich natürlich.

Phil Hawksworth: Aber all das trägt viel dazu bei, den Stack zu vereinfachen. Wenn wir an den Stack denken, von dem aus wir Websites bedienen; Mir geht es nur darum, Dinge zu vereinfachen, ich bin sehr daran interessiert, den Stack zu vereinfachen. Und das ist irgendwie das Herzstück dieses Dings namens „JAMstack“, und ich möchte versuchen, das ein wenig zu erklären. Das „JAM“ in JAMstack steht für JavaScript, APIs und Markup. Aber das reicht nicht wirklich aus, um uns zu helfen zu verstehen, was es bedeutet – was um alles in der Welt bedeutet das wirklich?

Phil Hawksworth: Nun, was ich in der nächsten halben Stunde oder so versuchen möchte, ist, diese Definition zu erweitern und mehr zu beschreiben, was JAMstack ist. Ich möchte ein wenig über die Auswirkungen und Auswirkungen von JAMstack sprechen und darüber nachdenken, was uns das bringen kann, warum wir uns dafür entscheiden könnten. Unterwegs werde ich versuchen, einige der Tools und Dienste zu erwähnen, die nützlich sein werden, und hoffentlich werde ich mit einigen Ressourcen abschließen, in die Sie sich vielleicht vertiefen möchten, und vielleicht einige erste Schritte erwähnen, um Sie zu erreichen im Gange.

Phil Hawksworth: Das ist also der Plan für die nächste halbe Stunde. Aber ich möchte irgendwie auf diese Vorstellung über die Vereinfachung des Stacks zurückkommen, denn hoffentlich haben Leute, die sich dem anschließen oder dieses Video später ansehen, vielleicht eine Vorstellung davon, was JAMstack ist, oder Vielleicht ist es ein völlig neuer Begriff, und Sie sind nur neugierig. Aber letztendlich gibt es da draußen schon viele Stacks. Es gibt viele Möglichkeiten, wie Sie eine Website bereitstellen können. Es fühlt sich an, als hätten wir schon sehr lange verschiedene Arten von Infrastruktur aufgebaut, sei es ein LAMP-Stack oder der MAMP-Stack oder – ich weiß nicht – der MEAN-Stack. Hier schweben ein paar davon auf dem Bildschirm vorbei. Es gibt viele, viele von ihnen.

Phil Hawksworth: Also, warum um alles in der Welt sollten wir noch einen brauchen? Nun, JAMstack ist, wie ich bereits erwähnt habe, JavaScript/API/Markup, aber wenn wir versuchen, ein bisschen anschaulicher zu sein, soll JAMstack eine moderne Architektur sein, um dabei zu helfen, schnelle und sichere Websites und dynamische Apps mit JavaScript zu erstellen. APIs und vorgerendertes Markup, das ohne Webserver bereitgestellt wird, und es ist dieser letzte Punkt, der es irgendwie von anderen unterscheidet und es vielleicht ein bisschen interessanter und ungewöhnlicher macht.

Phil Hawksworth: Diese Vorstellung, etwas ohne Webserver bereitzustellen, klingt entweder magisch oder lächerlich, und hoffentlich werden wir im Laufe der Zeit herausfinden, was das ist. Aber um zu versuchen, etwas Licht ins Dunkel zu bringen und es etwas detaillierter zu beschreiben, ist es manchmal nützlich, es mit dem zu vergleichen, was wir uns unter einem traditionellen Stack oder einer traditionellen Art der Bereitstellung von Dingen im Internet vorstellen. Also, machen wir das nur für eine Sekunde. Lassen Sie uns vielleicht einfach durchgehen, wie eine Anfrage aussehen könnte, wenn sie in einem traditionellen Stack bedient wird.

Phil Hawksworth: In diesem Szenario haben wir also jemanden, der einen Webbrowser öffnet und eine Anfrage zum Anzeigen einer Seite stellt. Und vielleicht trifft diese Anfrage ein CDN, aber wahrscheinlicher trifft sie eine andere Infrastruktur, die wir hosten – als die Leute, denen diese Website gehört. Vielleicht haben wir versucht, sicherzustellen, dass dies unter viel Last skaliert, weil wir natürlich einen sehr beliebten und erfolgreichen Anblick wollen. Vielleicht haben wir also einen Load Balancer mit einer gewissen Logik, der diese Anfrage an einen von mehreren Webservern weiterleitet, die wir bereitgestellt, konfiguriert und bereitgestellt haben. Möglicherweise gibt es mehrere dieser Server.

Phil Hawksworth: Und diese Server werden eine Logik ausführen, um zu sagen: „Okay, hier ist unsere Vorlage, wir müssen sie mit einigen Daten füllen.“ Wir können unsere Daten von einem von mehreren Datenbankservern erhalten, die eine Logik ausführen, um einige Daten nachzuschlagen, diese an den Webserver zurückzugeben und eine Ansicht zu erstellen, die wir dann durch den Load Balancer zurückgeben. Vielleicht auf dem Weg zum CDN anrufen, einige Assets im CDN verstauen, und ich sollte klarstellen, dass ein CDN ein Content Delivery Network ist, also ein Netzwerk von Maschinen, die über das Internet verteilt sind, um zu versuchen, einen Anfragedienst so nah wie möglich zu bekommen an den Benutzer und fügen Dinge wie Caching hinzu.

Phil Hawksworth: Wir könnten also einige Assets dort verstauen und letztendlich einen Blick in den Browser zurückgeben, in die Augäpfel des Benutzers, der dann die von uns erstellte Website erleben kann. Das ist also offensichtlich entweder eine zu starke Vereinfachung oder eine sehr allgemeine Sichtweise darauf, wie wir eine Anfrage in einem traditionellen Stack bedienen könnten. Wenn wir das mit dem JAMstack vergleichen, der die Dinge auf eine etwas andere Weise bedient, könnte es so aussehen.

Phil Hawksworth: Also noch einmal dasselbe Szenario, wir beginnen in einem Webbrowser. Wir fordern eine Ansicht der Seite an, und diese Seite befindet sich bereits in einem CDN. Von dort aus wird es statisch bereitgestellt, also wird es an den Benutzer in den Browser zurückgegeben, und wir sind fertig. Also, natürlich eine sehr vereinfachte Ansicht, aber Sie können sofort die Unterschiede in Bezug auf die Komplexität erkennen. In Bezug auf die Orte, an denen wir Code verwalten müssen, tief codieren, all diese verschiedenen Dinge. Für mich ist eines der Kernattribute eines JAMstacks, dass Sie eine Site erstellen, die direkt von einem CDN oder sogar von einem statischen Dateiserver bedient werden kann. CDN ist etwas, das wir vielleicht einrichten möchten, um die Last zu bewältigen, aber letztendlich könnte dies direkt von jeder Art von statischem Dateiserver, Art von statischer Hosting-Infrastruktur, bereitgestellt werden.

Phil Hawksworth: JAMstack bietet gewissermaßen eine Möglichkeit, die Komplexität zu reduzieren. Wenn Sie nur diese beiden Teile des Diagramms vergleichen, auf die wir im Laufe der nächsten halben Stunde noch einige Male zurückkommen werden, können Sie sehen, dass dies eine Gelegenheit ist, die Komplexität zu reduzieren und das Risiko zu verringern. Das bedeutet, dass wir anfangen können, einige der Vorteile der Bereitstellung statischer Assets zu genießen, und ich werde etwas später darüber sprechen, was das ist. Aber vielleicht sehen Sie sich das an und denken: „Nun, großartig, aber ist das nicht nur der neue Name für statische Websites?“ Das ist eine vernünftige Sache, wenn ich sage: „Wir werden die Dinge statisch bedienen.“

Phil Hawksworth: Aber darauf möchte ich zurückkommen. Ich möchte ein bisschen mehr darüber sprechen, aber zuerst möchte ich sozusagen über diese Vorstellung von Stacks sprechen und was um alles in der Welt ist ein Stack überhaupt? Und ich betrachte einen Stack als die Technologieschichten, die Ihre Website oder Anwendung bereitstellen. Und wir sprechen nicht über die Build-Pipeline oder den Entwicklungsprozess, aber sicherlich kann die Art und Weise, wie wir Sites bedienen, einen großen Einfluss darauf haben, wie wir entwickeln und wie wir Dinge bereitstellen und so weiter.

Phil Hawksworth: Aber hier sprechen wir über den Technologie-Stack, die Technologieschichten, die Ihre Website und Ihre Anwendung tatsächlich für die Benutzer bereitstellen. Machen wir also nochmal einen kleinen Vergleich. Lassen Sie uns kurz über den LAMP-Stack sprechen.

Phil Hawksworth: Der LAMP-Stack besteht, wie Sie sich vielleicht erinnern, aus einem Apache-Webserver, der Dinge wie das HCP-Routing und das Servieren statischer Assets erledigt. PHP, für etwas Vorverarbeitung, also hübsche Hypertextverarbeitung; Anwenden der Logik, vielleicht Erstellen der Ansichten für die Vorlagen und was Sie haben. Und hat einen gewissen Zugriff auf Ihre Daten, durch mein NISQL, und dann ist LINUX das Betriebssystem, das unter all dem sitzt, das alles am Leben erhält. Wir können das gedanklich als diesen Webserver zusammenfassen. Und wir haben vielleicht viele dieser Server, die zusammensitzen, um eine Website zu bedienen.

Phil Hawksworth: Das ist eine Art traditioneller Blick auf den LAMP-Stack, und wenn wir das mit dem JAM-Stack vergleichen, nun, hier gibt es eine entscheidende Änderung. Hier bewegen wir uns tatsächlich auf einer höheren Ebene, anstatt über das Betriebssystem nachzudenken und darüber nachzudenken, wie wir die Logik ausführen, um eine Website bereitzustellen. Hier gehen wir davon aus, dass wir diese Dinge statisch bedienen werden. Wir führen also das ACP-Routing und die Bereitstellung von Assets von einem statischen Server aus durch. Das kann man vernünftig machen. Darin sind wir im Laufe der Jahre sehr gut geworden, indem wir Möglichkeiten zur Bereitstellung statischer Websites oder statischer Assets entwickelt haben.

Phil Hawksworth: Das könnte ein CDN sein, und darauf werden wir gleich noch einmal zu sprechen kommen. Aber der für uns interessante Bereich spielt sich mehr im Browser ab. Hier wird also unser Markup geliefert und geparst. Hier kann JavaScript ausgeführt werden, und dies geschieht im Browser. Der Browser ist in vielerlei Hinsicht zur Laufzeitumgebung für das moderne Web geworden. Anstatt die Laufzeit in der Serverinfrastruktur selbst zu haben, haben wir sie jetzt eine Ebene höher, näher zum Benutzer und in den Browser verschoben.

Phil Hawksworth: Wenn es um den Zugriff auf Daten geht, geschieht dies möglicherweise über externe APIs, Aufrufe über JavaScripts an diese externen APIs, um Serverzugriff zu erhalten, oder wir können uns APIs als Browser-APIs vorstellen, die in der Lage sind, mit JavaScript zu interagieren mit Funktionen direkt in Ihrem Browser.

Phil Hawksworth: Wie auch immer, der Schlüssel zum JAMstack ist, dass wir über vorgerenderte Dinge sprechen: Sie werden statisch bereitgestellt und dann möglicherweise im Browser schrittweise verbessert, um Browser-APIs, JavaScripts, zu nutzen , und was hast du.

Phil Hawksworth: Lassen Sie uns hier einfach diesen kleinen direkten Vergleich anstellen. Ich möchte noch einmal wiederholen, dass der JAMstack eine Ebene höher in den Browser gerückt ist. Und wenn wir die beiden Seiten dieses Diagramms sehen, mit dem LAMP-Stack auf der linken Seite und effektiv dem JAM-Stack auf der rechten Seite, könnten Sie sogar denken, dass wir, selbst als wir mit dem LAMP-Stack gebaut haben, immer noch da sind Markup ausgeben. Wir geben immer noch JavaScript aus. Wir greifen möglicherweise immer noch auf APIs zu. In vielerlei Hinsicht ist der JAMstack also fast wie eine Teilmenge dessen, was wir zuvor erstellt haben.

Phil Hawksworth: Ich habe früher manchmal über JAMstack als den gesicherten Stack gesprochen, weil er eine Reihe von Tools und Technologien sicherstellt, die wir benötigen, um eine Website bereitzustellen. Aber so oder so, es ist eine stark vereinfachte Art, eine Site bereitzustellen, die gewissermaßen die Notwendigkeit überflüssig macht, Dinge zur Anforderungszeit auf dem Server auszuführen und Logik auszuführen.

Phil Hawksworth: Das kann also eine Menge bewirken. Dies kann Bereitstellungen in gewisser Weise vereinfachen, und ich werde von Zeit zu Zeit auf dieses Diagramm zurückgreifen. Wenn wir darüber nachdenken, wie wir unseren Code und unsere Website für jede Bereitstellung bereitstellen, von der allerersten über den gesamten Entwicklungslebenszyklus bis hin zur Lebensdauer der Website. Auf dem traditionellen Stack müssen wir möglicherweise die Logik und den Inhalt für jede Box in diesem Diagramm ändern.

Phil Hawksworth: Wohingegen wir im JAMstack, wenn wir über das Deployment sprechen, davon sprechen, Dinge zum CDN zu bringen, Dinge zum statischen Server zu bringen, und das ist es, was das Deployment mit sich bringt. Der Build, die Art von Logik, die den Build ausführt – die überall ausgeführt werden kann. Das muss nicht in derselben Umgebung ausgeführt werden, in der der Webserver gehostet wird. Tatsächlich tut es das nicht! Es startet den Schlüssel zum JAMstack. Wir legen die Trennung auf das, was zum Zeitpunkt der Anfrage passiert, und dienen diesen statischen Assets, im Vergleich zu dem, was zum Zeitpunkt des Builds passiert, was Ihre Logik sein kann, die Sie zum Erstellen und dann zur Bereitstellung ausführen.

Phil Hawksworth: Also, diese Art der Entkopplung ist eine Schlüsselsache, und ich werde später darauf zurückkommen. Wir sind sehr gut darin geworden, statische Dateien bereitzustellen, und Dinge zu einem CDN oder zum Dateisystem (dem Dateiserver) zu bringen, ist etwas, wo wir in den letzten Jahren enorme Fortschritte gesehen haben. Es gibt mittlerweile viele Tools und Prozesse, die uns dabei helfen können, dies wirklich gut zu tun. Um nur einige Dienste zu nennen, die statische Ressourcen gut bedienen und Arbeitsabläufe bereitstellen können, um Ihren Build in diese Umgebung zu bringen, sind sie die üblichen Verdächtigen, die Sie sich vielleicht bei den großen Cloud-Infrastrukturanbietern wie Azure, AWS und Google Cloud vorstellen.

Phil Hawksworth: Aber es gibt noch andere. Der obere rechts ist also ein Dienst namens Surge, den es seit einigen Jahren gibt. Es ermöglicht Ihnen, einen Befehl in Ihrer Build-Umgebung auszuführen und Ihre Assets in ihrer Hosting-Umgebung bereitzustellen. Netlify, das nächste unten, ist mein Arbeitsplatz und wir machen fast das Gleiche, aber wir haben auch unterschiedliche Automatisierungen. Darauf könnte ich ein andermal eingehen. Und die untere, eine weitere statische Hosting-Umgebung namens Now.

Phil Hawksworth: Es gibt also eine Reihe verschiedener Möglichkeiten, dies zu tun, und alle diese Bereiche bieten unterschiedliche Werkzeuge, um so schnell wie möglich zum CDN zu gelangen. Stellen Sie Ihre Websites so nahtlos wie möglich bereit. Und sie alle haben etwas gemeinsam, wo sie auf dem Prinzip aufbauen, etwas lokal zu betreiben. Ich denke oft an einen statischen Site-Generator als etwas, das wir in einem Build ausführen könnten, das, wenn wir das ausführen, Dinge wie Inhalte und Vorlagen und vielleicht Daten von verschiedenen Diensten nimmt und etwas ausgibt, das statisch bereitgestellt werden kann.

Phil Hawksworth: Wir können das lokal auf unserem statischen Server vorab ansehen. Etwas, das in jeder lokalen Entwicklungsumgebung ziemlich einfach zu tun ist, und dann der Prozess der Bereitstellung, der das in die Hosting-Umgebung und idealerweise in ein CDN bringt, um eine gewisse Skalierung zu erreichen. Mit dieser Art von Grundlage möchte ich also ein weit verbreitetes Missverständnis ansprechen, wenn es um JAMstack-Sites geht. Und ich habe mir keinen Gefallen getan, indem ich dies so eröffnet habe, als würde ich JAMstack-Sites als JavaScript, APIs und Markup beschreiben. Weil das allgemeine Missverständnis ist, dass jede JAMstack-Site JavaScript und APIs und Markup sein muss, aber wir haben übersehen, dass wir nicht alle drei verwenden müssen – jede einzelne davon ist irgendwie , Optional. Wir können so viel oder so wenig davon verwenden, wie wir möchten. Genauso wie eine LAMP-Stack-Site nicht unbedingt auf eine Datenbank zugreifen muss. Nun, ich habe in der Vergangenheit Dinge gebaut, die von einem Apache-Server auf einer Linux-Maschine bedient werden, und ich habe PHP verwendet, aber ich habe keine Datenbank getroffen und ich würde nicht anfangen, einen Stack umzubenennen unbedingt dafür.

Phil Hawksworth: Wenn wir also darüber nachdenken, was eine JAMstack-Site ist, dann könnte es ein Haufen verschiedener Dinge sein. Es könnte etwas sein, das mit einem statischen Website-Generator wie Jekyll aufgebaut ist, der Inhalte aus YAML-Dateien zieht, um eine Website zu erstellen, die kein JavaScript hat, überhaupt nicht auf APIs trifft, und wir stellen sie auf etwas wie GitHub Pages bereit. Oder das wäre eine JAMstack-Site. Oder vielleicht verwenden wir einen Static-Site-Generator wie Gatsby, der sich eher in einer Ruby-Umgebung für Jekyll befindet, jetzt ist dies ein JavaScript-Static-Site-Generator, der in das React-Ökosystem integriert ist.

Phil Hawksworth: Das könnte wieder Inhalt ziehen und Markdown-Dateien organisieren. Es könnte das mit Aufrufen von APIs, den APIs von GraphQL, bereichern. Es könnte Dinge im Browser tun, wie z. B. das Ausführen von JavaScript-Hydratation zum Ausfüllen von Vorlagen direkt im Browser. Und es könnte auf Amazon S3 bereitgestellt werden. Ist das eine JAMStack-Seite? Ja, absolut!

Phil Hawksworth: Weiter zu einem anderen statischen Site-Generator, Hugo, der mit Go! Auch hier organisieren wir möglicherweise Inhalte in Markdown-Dateien und fügen mithilfe von JavaScript Interaktionen im Browser hinzu. Möglicherweise keine externen APIs aufrufen und diese möglicherweise in Google Cloud hosten. Ist es JAMStack? Absolut! Sehen Sie, ich baue hier auf ein Thema auf. Verwendung von etwas wie Nuxt, einem weiteren statischen Site-Generator, der jetzt im View-Ökosystem integriert ist. Vielleicht zieht das Inhalte aus verschiedenen benachbarten Dateien? Auch hier verwenden wir möglicherweise JavaScript-Interaktionen im Browser, rufen möglicherweise APIs auf, um Dinge wie E-Commerce zu erledigen, und stellen ihm eine andere statische Website zur Verfügung. Ist eine andere Hosting-Infrastruktur wie Netlify ein JAMstack? Ja, so ist es!

Phil Hawksworth: Aber wir könnten sogar, wissen Sie, auch an dieses Ende der Skala gehen. Und denken Sie an eine handgefertigte, progressive Web-App, die wir handwerklich erstellt haben, handgerolltes JavaScript, das wir selbst erstellt haben. Wir verpacken es mit webpack. Wir verwenden vielleicht JavaScript-Webtoken und rufen APIs auf, um die Authentifizierung durchzuführen, interagieren mit verschiedenen Browser-APIs und hosten sie auf Azure. Ja, das ist auch JAMstack!

Phil Hawksworth: Und wissen Sie, all diese Dinge und viele mehr können als JAMstack betrachtet werden, weil sie alle ein gemeinsames Attribut haben, und das ist, dass keines von ihnen mit einem Ursprungsserver bedient wird. Keiner von ihnen muss einen Server treffen, der zum Zeitpunkt der Anfrage Logik ausführt. Diese werden als statische Assets bereitgestellt und anschließend mit JavaScript und Aufrufen von APIs angereichert.

Phil Hawksworth: Ich möchte noch einmal wiederholen, dass ein JAMstack bedeutet, dass er direkt vom CDN bedient werden kann. Also, ich möchte nur einige der Auswirkungen und Implikationen davon nennen, denn warum sollten wir das tun wollen? Nun, der erste Gedanke betrifft die Sicherheit, und wir haben hier eine stark reduzierte Angriffsfläche. Wenn wir an die Stellen denken (um noch einmal auf dieses alte Diagramm zurückzukommen), wo wir möglicherweise mit einem Angriff fertig werden müssen, müssen wir Dinge wie den Load Balancer, die Webserver und die Datenbankserver sichern. All diese Dinge müssen wir sicherstellen, dass sie nicht von irgendeiner Art von Angriff durchdrungen werden können, und zwar vom CDN.

Phil Hawksworth: Je mehr Teile wir aus diesem Puzzle herausnehmen können, desto weniger Orte können angegriffen werden und desto weniger Orte müssen wir sichern. Es ist wirklich sehr wertvoll, nur wenige bewegliche Teile anzugreifen. Bei Netlify betreiben wir unsere eigenen CDNs, sodass wir den Luxus haben, den Datenverkehr überwachen zu können, der darauf stößt, und obwohl alle Websites auf Netlify gehostet werden, alle JAMstack-Websites, die Sie sich vorstellen können, keine davon haben eine WordPress-Admin-Seite, weil sie vollständig entkoppelt ist. Es gibt keinen WordPress-Administrator, aber wir sehen ein riesiges Verkehrsaufkommen, das nach Dingen wie WP Admin sucht, nach Wegen sucht, nach Angriffsvektoren sucht.

Phil Hawksworth: Ich liebe einige der Dinge, die Kent C. Dodds getan hat. Ich weiß nicht, ob Sie mit der React-Community vertraut sind, Sie sind wahrscheinlich in der Vergangenheit Kent C. Dodds begegnet. Er verwendet kein WordPress, leitet aber trotzdem diese URL, den WPAdmin, weiter. Ich glaube, er hat es früher zu einem Rick-Roll-Video auf YouTube weitergeleitet. Er hat sicherlich Leute getrollt, die danach gesucht haben. Aber der Punkt ist, indem wir die Dinge auf diese Weise entkoppeln und Dinge, die passieren, verschieben, Zeit von dem, was in der Anfragezeit passiert, aufbauen, können wir unsere Exposition einfach drastisch reduzieren. Wir haben keine beweglichen Teile zur Anfragezeit. Alle beweglichen Teile sind zur Bauzeit vollständig entkoppelt. Potenziell auf ganz, naja, notwendigerweise auf ganz anderer Infrastruktur.

Phil Hawksworth: Das wirkt sich natürlich auch auf die Performance aus. Zurück zu unserem alten Freund hier, den Stellen, an denen wir vielleicht versuchen sollten, die Leistung im gesamten Stack hier zu verbessern, wenn an diesen verschiedenen Stellen Logik ausgeführt werden muss. Bei herkömmlichen Stacks geschieht dies häufig so, dass sie beginnen, Schichten hinzuzufügen, statische Schichten hinzuzufügen, um die Leistung zu verbessern. Mit anderen Worten, versuchen Sie Wege zu finden, wie wir anfangen können, uns so zu verhalten, als ob es statisch wäre. Diese Logik muss nicht auf jeder Ebene des Stapels ausgeführt werden, um die Dinge zu beschleunigen. Also fangen wir an, Dinge wie Caching in der gesamten Infrastruktur einzuführen, und offensichtliche Stellen, die wir finden könnten, sind im Webserver, anstatt diese Logik auszuführen, möchten wir etwas sofort bereitstellen, ohne diese Logik auszuführen.

Phil Hawksworth: Es ist also so etwas wie ein Schritt in Richtung Pseudo-Statik. Ebenso möchten wir bei Datenbankservern Caching-Layer zu cache-com-Abfragen hinzufügen. Selbst im niedrigen Guthaben kann man sich das gesamte CDN als Cache vorstellen. Aber auf dem traditionellen Stack müssen wir herausfinden, wie wir diesen Cache verwalten, da nicht alles zwischengespeichert wird. Es geht also um etwas Logik. Was muss dynamisch ausgefüllt werden im Vergleich zu dem, was zwischengespeichert werden kann. Und beim JAMstack-Modell wird alles zwischengespeichert. Ab dem Zeitpunkt, an dem die Bereitstellung abgeschlossen ist, wird alles zwischengespeichert, sodass wir ganz anders darüber nachdenken können.

Phil Hawksworth: Dies deutet also auch auf eine Art Skalierung hin. Und nach Größenordnung, ich spreche davon, wie gehen wir mit großen Verkehrslasten um? Herkömmliche Stacks werden beginnen, Infrastruktur hinzuzufügen, um zu skalieren. Also, ja, zum Caching. Wir fangen an, unseren traditionellen Stack einzurichten. Das wird helfen – bis zu einem gewissen Grad. Was normalerweise passiert, ist, dass wir, um große Verkehrslasten zu bewältigen, damit beginnen, die Infrastruktur zu erweitern und mehr Server hinzuzufügen, mehr Teile, um diese Anfragen zu verarbeiten, diese Dinge zu kalkulieren und die Last zu schätzen, ist ein großer Overhead und es kann Kopfschmerzen für jeden, der sich mit technischer Architektur befasst. Es war sicherlich für mich, weshalb ich anfing, mich viel mehr dem JAMstack-Ansatz zuzuwenden, bei dem ich einfach weiß, dass alles vom CDN bereitgestellt wird, das standardmäßig für die Skalierung ausgelegt ist, um die Leistung von Anfang an zu bewältigen .

Phil Hawksworth: Ich möchte also auch auf die Erfahrung von Entwicklern und die Auswirkungen, die dies dort haben kann, hinweisen. Nun, die Entwicklererfahrung sollte niemals als etwas angesehen werden, das die Benutzererfahrung übertrumpft, aber ich glaube, dass eine gute Entwicklererfahrung die Reibung verringern kann und es den Entwicklern ermöglichen kann, eine viel bessere Arbeit beim Aufbau großartiger Benutzererfahrungen zu leisten!

Phil Hawksworth: Wenn wir also darüber nachdenken, wo die Entwicklererfahrung lebt und wo die Problembereiche für einen Entwickler liegen: Nun, in einem traditionellen Stack müssen wir vielleicht darüber nachdenken, wie wir den Code für all diese unterschiedlichen Bereiche bekommen Teile der Infrastruktur und wie sie alle zusammenspielen. In der JAMstack-Welt sprechen wir wirklich von dieser Box hier unten. Wissen Sie, wie führen wir den Build aus und wie automatisieren wir eine Bereitstellung, damit überhaupt etwas bereitgestellt wird? Und das Schöne ist, dass es beim JAMstack-Modell ganz bei Ihnen liegt, was Sie in diesem Build tun.

Phil Hawksworth: Das ist ein wirklich gut definierter Problemraum, denn letztendlich versucht man, etwas aufzubauen, das man direkt von einem CDN bedienen kann. Sie möchten etwas mit beliebigen Tools vorab rendern: Ob es sich um einen statischen Website-Generator handelt, der in Ruby oder Python oder JavaScript oder Go oder PHP erstellt wurde, Sie haben die Freiheit, diese Wahl zu treffen. Dies kann eine viel angenehmere Arbeitsumgebung für Sie schaffen. Außerdem bietet es die Möglichkeit, echtes Entwicklervertrauen zu haben, da ein echtes Merkmal von JAMstack-Sites darin besteht, dass sie viel einfacher als unveränderliche und atomare Bereitstellung bereitgestellt werden können.

Phil Hawksworth: Und ich möchte kurz von den Folien wegspringen, um zu beschreiben, was das bedeutet, denn ein unveränderliches Deployment und ein atomares Deployment können … (das kann nur ein bisschen nach Marketingsprache klingen), aber Was ich tun werde, ist, in meinen Browser zu springen. Jetzt … eigentlich werde ich für eine Sekunde zurückgehen. Lass mich … mach einfach das.

Phil Hawksworth: Hier sind wir. Das wird einfacher. Direkt in die Seite springen. Nun, Scott, du wirst mir sagen, Scott, wenn du meinen Browser nicht sehen kannst, hoffe ich. Angenommen, jeder kann meinen Browser sehen.

Scott: Alles sieht gut aus.

Phil Hawksworth: Ausgezeichnet! Danke sehr!

Phil Hawksworth: Also, was ich hier mache, ist, dass ich Netlify als Beispiel verwende, als Beispiel für den Dienst. Dies ist jedoch ein Attribut, das Websites gemeinsam ist, die statisch gehostet werden können. Wenn wir also von einer unveränderlichen Bereitstellung sprechen, meinen wir damit, dass jede Codebereitstellung viele verschiedene Teile der Infrastruktur berühren und viele Dinge ändern muss, hier ändern wir nicht den Zustand der Site der Kellner. Wir erstellen für jede durchgeführte Bereitstellung eine völlig neue Instanz der Website. Und das können wir tun, weil die Website eine Sammlung statischer Assets ist.

Phil Hawksworth: Hier schaue ich mir die Bereitstellung an, die von meiner eigenen Website aus stattgefunden hat. Ich gebe dir ein Leckerli. So sieht es aus. Es ist nur ein Blog, es sieht nicht nach etwas besonders Bemerkenswertem oder Aufregendem aus. Es ist ein statisch generierter Blog, aber was ich hier habe, ist, dass jede Bereitstellung, die jemals stattgefunden hat, für immer weiterlebt, weil es eine Sammlung statischer Assets ist, die von einem CDN bereitgestellt werden. Jetzt könnte ich so weit zurückgehen, wie meine Geschichte mich tragen kann, und mir die Seite ansehen, wie sie damals war … wann war das? Das war August 2016. Und da es sich um eine Reihe statischer Assets handelt, können wir dies auf einer eigenen URL hosten, die für immer weiterlebt, und wenn ich überhaupt wollte, könnte ich mich entscheiden, hineinzugehen und das zu veröffentlichen Einsatz.

Phil Hawksworth: Also, jeder, der sich meine Website ansieht, wenn ich hierher zu meiner Website zurückkehre, wenn ich diese Seite aktualisiere, wird jetzt direkt vom CDN mit den Assets bedient, die vorher dort waren. Jetzt kann ich wieder navigieren. Hier sieht man. Schauen Sie, ich habe darüber geredet, ich habe diese schrecklichen Begriffe wie isomorphes Rendering verwendet und 2016 über den JAMstack gesprochen. Das ist es also, was jetzt live auf meiner Website serviert wird. Auch hier, weil es gegenseitige Einsätze gibt, die einfach ewig weiterleben. Ich werde einfach meine eigene Art von Seelenfrieden einfügen, ich werde – ist dies die erste Seite? Ja. Ich werde zu meinem letzten Einsatz zurückkehren. Ich muss wieder schließen und mich zurück in die reale Welt bringen. Lassen Sie mich nur sicherstellen, dass das in Ordnung ist.

Phil Hawksworth: Okay! Toll! Also, jetzt dient dies wieder dazu, meine vorherige Version oder meine neueste Version der Website bereitzustellen. Ich komme zurück zur Keynote. Das ist also möglich, weil die Dinge unveränderlich und atomar sind. Der atomare Teil davon bedeutet wiederum, dass die Bereitstellung vollständig enthalten ist. Sie erreichen also nie den Punkt, an dem einige der Assets auf dem Webserver verfügbar sind, andere jedoch nicht. Erst wenn alles im Kontext und vollständig vorhanden ist, schalten wir die Bereitstellung der Website auf die neue Version um. Auch dies ist die Art von Dingen, die Sie viel einfacher tun können, wenn Sie Dinge als JAMstack-Site aufbauen, die direkt vom CDN als eine Reihe von Assets dient.

Phil Hawksworth: Ich habe bemerkt, dass mein Timer zurückgesetzt wurde, nachdem ich von der Keynote vor und zurück gegangen bin, also denke ich, dass ich noch etwa sechs oder sieben Minuten übrig habe. Sag mir, Scott, wenn –

Scott: Also, ja, wir sind immer noch gut für etwa zehn Minuten.

Phil Hawksworth: Zehn Minuten? Okay, wunderbar!

Scott: Es gibt keine Eile.

Phil Hawksworth: Danke, das sollte gut sein!

Phil Hawksworth: Also, wenn wir nur ein bisschen umschalten und über APIs und Dienste sprechen (da APIs Teil von JAMstack sind), ist die Art von Diensten, die wir dann möglicherweise verwenden können, hauptsächlich JAMstack. Wissen Sie, wir verwenden möglicherweise Dienste, die wir intern erstellt haben, oder wir verwenden möglicherweise gekaufte Dienste. Es gibt viele verschiedene Anbieter, die Dinge für uns tun können, und das liegt daran, dass sie ihre Expertise haben. Über APIs beziehen wir möglicherweise Inhalte aus Content-Management-Systemen als Service, und es gibt eine Reihe verschiedener Anbieter dafür, die sich darauf spezialisiert haben, ein großartiges Content-Management-Erlebnis zu bieten und die Inhalte dann über API bereitzustellen, so wie Sie es früher waren sie einziehen können.

Phil Hawksworth: Ebenso gibt es verschiedene Möglichkeiten, Vermögenswerte zu bedienen. Leute wie Cloudary sind großartig darin, Bilder zu optimieren und Assets direkt über APIs auf Ihren Websites bereitzustellen. Oder was ist mit E-Commerce? Wissen Sie, es gibt Orte wie Stripe oder Snipcart, die uns APIs bereitstellen können, sodass wir diese Dienste nicht selbst erstellen müssen und uns mit den sehr komplexen Problemen befassen müssen, die mit dem Versuch einhergehen, eine E-Commerce-Engine zu erstellen. Ebenso die Identität von Personen wie Auth0, die Oauth verwenden. Es gibt viele Dienste, die verfügbar sind, und wir können diese Dinge über APIs nutzen, entweder im Browser oder zur Build-Zeit oder manchmal eine Kombination aus beidem.

Phil Hawksworth: Now, some people might think, “Well, that's fine, but I don't want to give the keys to the kingdom away. I don't want to risk giving these services over to external providers,” and to that, I say, well, you know, vendors who provide a single service really depend on its success. If there's a company that's core business, or entire business, is in building-out an e-Commerce engine, an e-Commerce service for you, they're doing that for all of their clients, all of their customers, so they really depend on its success and they have the specialist skills to do that.

Phil Hawksworth: So, that kind of de-risks it from you a great deal. Especially when you start to factor in the fact that you can have your technical and service-level contracts to give you that extra security. But it's not all about bought services, it's also about services you can build yourselves. Now, there's a number of ways that this can happen, but sometimes, you absolutely need a little bit of logic on the server. And so far, I've just been talking about taking the server out of the equation. So, how do we do that?

Phil Hawksworth: Well, this is where serverless can really come to the rescue. Serverless and JAMstack, they just fit together really beautifully. And when I'm talking about serverless, I'm talking about no functions as a service. I know that serverless can be a bit of a loaded term, but here, I'm talking about functions as a service. Because functions as a service can start to enable a real micro-services architecture. Using things like AWS Lambda or Google Cloud functions or similar functions as a service, can allow you to build out server infrastructure without a server. Now, you can start deploying JavaScript logic to something that just runs on demand.

Phil Hawksworth: And that means, you can start supplementing some of these other services with, maybe, very targeted small services you build yourselves that can run the serverless functions. These kind of smaller services are easier to reason about, understand, build out and they create much greater agility. I want to just mention a few examples and results from JAMstack sites. I'm not going to go down the server list avenue too much, right now. We can, maybe, come back to that in the questions. I really just kind of want to switch gear and, thinking about time a little bit, talk about some examples and results.

Phil Hawksworth: Because there are some types of sites that lend themselves in a very obvious way to a JAMstack site. Things like the documentation for React, or Vuejs, those [inaudible 00:32:40], pre-rendered JAMstacks sites. As do sites for large companies, such as Citrix, this is a great example of Citrix multi-language documentation. You can actually view the video from the JAMstack conference that happened in New York, where Beth Pollock had worked on this project, talked about the change that went on in that project. From building on traditional, non-enterprised infrastructure to a JAMstack approach and building with Jekyll, which is not necessarily the fastest generating static site generator, but still, they saw a huge improvement.

Phil Hawksworth: Beth talked about the turnaround time for updates went from weeks to minutes. Maybe people are kind of frowning at the idea of weeks for updates to sites, but sometimes in big complex infrastructure, with lots of stakeholders and lots of moving parts, this really is the situation we're often finding ourselves in. Beth also talked about estimating the annual cost savings for this move to a JAMstack site. To get the site running properly, estimated their savings of around 65%. That's huge kind of savings. Changing gear to a slightly different type of site, something a little closer to home, Smashing Magazine itself is a JAMstack site, which might be a little bit surprising, because on one hand, yes, there's lots of articles and it's also content, which is published regularly, but not every minute of the day, for sure.

Phil Hawksworth: So, that might lend itself, perhaps, for something that's pre-generated, but of course, there's also a membership area and an event section, and a job board, and e-Commerce, and all of these things. This is all possible on the JAMstack because not only are we pre-rendering, but we're also enriching things with JavaScript and the front end to call out to APIs, which let some of these things happen. The project that I think I saw Vitaly arrive in the call, so that's going to be good, we might be able to come back to this in a few minutes.

Phil Hawksworth: But the project that migrated, Smashing Magazine onto a JAMstack approach, I believe, simplified the number of platforms from five, effectively down to one. And I'm using Vitaly's words directly here: Vitaly talked about having some caching issues, trying to make the site go quickly, using probably every single WordPress caching plug-in out there, and goodness knows, there are a few of them! So, Smashing Magazine saw an improvement in performance, time to first load went from 800 milliseconds to 80 milliseconds. Again, I'm simplifying the infrastructure that served the site up in the first place. So, it's kind of interesting to see the performance gains that can happen there.

Phil Hawksworth: Another totally different type of site. This is from the Google Chrome team, who built this out to demonstrate at Google I/O this year. This very much feels like an application. This is Minesweeper in a browser. I apologize if you're watching me play this. I'm not playing it while talking to you; I recorded this sometime ago and it's agony to see how terrible I seem to be at Minesweeper while trying to record. That's not a mine, that can't be!

Phil Hawksworth: Anyway, we'll move on.

Phil Hawksworth: The point of that is, this is something that feels very much more like an app, and it was built in a way to be very responsible about the way it used JavaScript. The payload to interactive was 25KB. This progressively would download and use other resources along the way, but it meant that the time to interact was under five seconds on a very slow 3G network. So, you can be very responsible with the way you use JavaScript and still package up JavaScript, as part of the experience for a JAMstack site.

Phil Hawksworth: So, I'm kind of mindful of time. We're almost out of time, so what is the JAMstack? Well, it's kind of where we started from. JAMstack sites are rendered in advance: they're not dependent on an origin server (that's kind of key), and they may be progressively enhanced in the browser with JavaScript. But as we've shown, you don't have to use JavaScript at all. You might just be serving that statically, ready to go, without that. It's an option available to you.

Phil Hawksworth: This key tenant, I think of, JAMstack sites is they're served without web service. They're pre-rendered and done in advance.

Phil Hawksworth: If you're interested in more, it's already been mentioned a little bit, there is a conference in London in July — July 9th and 10th. The speakers are going to be talking about all kinds of things to do with performance in the browser, things that you can do in the browser, results of building on the JAMstack and things to do with serverless.

Phil Hawksworth: There's also a bunch of links in this deck that I will share, after this presentation, including various bits and pieces to do with static site generation, things like headless CMS, the jamstack.org site itself, and a great set of resources on a website called “The New Dynamic” which is just always full of latest information on JAMstack. We're out of time, so I'll wrap it up there, and then head back across to questions. So, thanks very much for joining and I'd love to take questions.

Scott: Thanks, Phil. That was amazing, thank you. You made me feel quite old when you pulled up the Minesweeper reference, so—

Phil Hawksworth: (laughs) Yeah, I can't take any credit for that, but it's kind of fascinating to see that as well.

Scott: So, I do think Vitaly is here.

Vitaly: Yes, always in the back.

Phil Hawksworth: I see Vitaly's smiling face.

Vitaly: Hello everyone!

Phil Hawksworth: So, I'm going to hand it over to Vitaly for the Q&A, because I seem to have a bit of a lag on my end, so I don't want to hold you guys up. Vitaly, I'll hand it over to you.

Scott: Okay. Thanks, Scott.

Vitaly: Thanks, Scott.

Vitaly: Hello—

Vitaly: Oh, no, I'm back. Hallo, alle miteinander. Now Scott is back but Phil is gone.

Scott: I'm still here! Still waiting for everything.

Vitaly: Phil is talking. Aw, Phil, I've been missing you! I haven't seen you, for what, for days, now? It's like, “How unbelievable!” Phil, I have questions!

Vitaly: So, yeah. It's been interesting for us, actually, to move from WordPress to JAMstack — it was quite a journey. It was quite a project, and the remaining moving parts and all. So, it was actually quite an undertaking. So, I'm wondering, though, what would you say, like if we look at the state of things and if we look in the complexes, itself, that applications have. Especially if you might deal with a lot of legacy, imagine you have to deal with five platforms, maybe seven platforms here, and different things. Maybe, you have an old legacy project in Ruby, you have something lying on PHP, and it's all kind of connected, but in a hacky way. Rechts? It might seem like an incredible effort to move to JAMstack. So, what would be the first step?

Scott: So … I mean, I think you're absolutely right, first of all. Re-platforming any site is a big effort, for sure. Particularly if there's lots of legacy. Now, the thing that I think is kind of interesting is an approach that I've seen getting more popular, is in identifying attributes of the site, parts of the site, that might lend themself more immediately to being pre-generated and served statically than others. You don't necessarily have to everything as a big bang. You don't have to do the entire experience in one go. So, one of the examples I shared, kind of, briefly was the Citrix documentations site.

Scott: They didn't migrate all of Citrix.com across to being JAMstack. They identified a particular part that made sense to be pre-rendered, and they built that part out. And then, what they did was they started to put routing in front of all the requests that would come into their infrastructure. So, it would say, “Okay, well, if it's in this part of the past the domain, either in the sub-domain or maybe, through to a path, route that through something which is static, then the rest of it, pass that through to the rest of the infrastructure.

Scott: And I've seen that happen, time and time again, where with some intelligent redirects, which, thankfully, is something that you can do reasonably simply on the JAMstack. You can start to put fairly expressive redirect engines in front of the site. It means that you can pass things through just that section of the site that you tried to take on as a JAMstack project. So, choosing something and focusing on that first, rather than trying to do a big bang, where you do all of the legacy and migration in one. I think that's key, because, yeah, trying to do everything at once is pretty tough.

Vitaly: It's interesting, because just, I think, two days, maybe even today, Chris Coyier wrote an article renaming JAMstack to SHAMstack where, essentially, it's all about JavaScript in which we need think about steady coasting, because JavaScript could be hosted steadily as well. And it's interesting, because he was saying exactly that. He actually — when we think about JAMstack, very often, we kind of tend to stay in camps. It's either, fully rendered and it lives a static-thing. Somewhere there, in a box and it's served from a city and that's it, or it's fully-expressive and reactive and everything you ever wanted. And actually, he was really right about a few things, like identifying some of the things that you can off-load, to aesthetic-side, generated assets, so to say, to that area.

Vitaly: And, JAMstackify, if you might, say some of the fragments of your architecture. Well, that's a new term, I'm just going to coin, right there! JAMstackify.

Phil Hawksworth: I'm going to register the domain quickly, before anybody else.

Phil Hawksworth: And it's a nice approach. I think, it kind of makes my eye twitch a little bit when I hear that Chris Coyier has been redubbing it the SHAMstack, because it makes it sound like he thinks it's a shambles. But I know that he's really talking about static-hosting and markup, which I—

Vitaly: Yes, that's right.

Phil Hawksworth: Ich mag es wirklich, weil der Begriff JAMstack wirklich irreführend sein kann, weil er versucht, so viele verschiedene Dinge abzudecken, und der Punkt, den ich versuchte, ich habe es wahrscheinlich viele Male in dieser Folie gehämmert, ist, dass es alles Mögliche sein kann von Sachen. Es ist so breit gefächert, aber der Schlüssel liegt darin, den Kern der Sites vorab zu rendern und statisch zu hosten. Es ist sehr einfach für uns, in Religionskriege darüber zu geraten, wo es eine React-Site sein muss. Es muss eine React-App sein, um eine JAMstack-Site zu sein, oder es ist eine React-App, also kann es kein JAMstack sein. Aber der springende Punkt ist, ob Sie JavaScript verwenden oder nicht, ob Sie APIs aufrufen oder nicht, ob Sie vorab rendern und Dinge in einen statischen Host bringen, der sehr leistungsfähig sein kann, das ist der Kern von JAMstack.

Vitaly: Ja, absolut.

Phil Hawksworth: Wir haben das große Glück, dass die Browser so viel leistungsfähiger werden, und die APIs, die in den Browsern selbst vorhanden sind, können uns auch ermöglichen, viel mehr zu tun. Das öffnet die Türen also noch weiter, aber es bedeutet nicht, dass alles, was wir als JAMstack-Site bauen, alles nutzen muss. Je nachdem, was wir zu liefern versuchen, sollten wir damit beginnen, die Tools auszuwählen, mit denen wir spielen, um diese Dinge bereitzustellen.

Vitali: Absolut. Wir haben Doran hier. Doran, ich glaube, ich weiß es, Doran. Ich habe das Gefühl, Doran zu kennen. Er fragt: „Erwarten Sie, dass Serverless von [unverständlich 00:44:36] zu einer nahtlosen Integration mit JAMstack tendiert? Was in JAM als das A bezeichnet wird.

Phil Hawksworth: Das ist eine großartige Frage, denn ich denke, dass serverlose Funktionen – sie passen einfach so gut zu JAMstack-Sites, denn in vielerlei Hinsicht glaube ich, dass mich jemand einmal gefragt hat, ob JAMstack-Sites serverlos sind, und so habe ich mich gewunden diese Frage, weil Serverless ein so belasteter Begriff ist. Aber in vielerlei Hinsicht ist es genau richtig, weil ich immer wieder davon gesprochen habe, dass es keinen Ursprungsserver gibt. Sie müssen keine Serverinfrastruktur verwalten. Tatsächlich habe ich einmal einen Blogbeitrag mit dem Titel „Web Serverless“ geschrieben, weil die Welt einen anderen Modebegriff braucht, nicht wahr?

Phil Hawksworth: Und wirklich, der Sinn dahinter war, ja, wir bauen Dinge ohne Server. Wir wollen diese Server nicht verwalten müssen, und serverlose Funktionen oder Funktionen als Dienst passen einfach perfekt dazu. In den Fällen, in denen Sie also eine API benötigen, an die Sie eine Anfrage stellen möchten, ist es für Sie wirklich nicht sinnvoll, diese Anfrage direkt vom Browser aus zu stellen. Wenn Sie also beispielsweise Geheimnisse oder Schlüssel in dieser Anfrage haben, möchten Sie möglicherweise nicht, dass diese Anfragen – diese Informationen – jemals im Client offengelegt werden. Aber wir können diese Dinge sicherlich als Proxy einsetzen, und was wir dann normalerweise tun müssen, ist, einen Server hochzufahren, eine Infrastruktur zu haben, die effektiv kaum mehr tut, als Anfragen zu bearbeiten, Sicherheitsauthentifizierung hinzuzufügen und diese Anfragen weiterzuleiten , indem sie sie zurückverweisen.

Phil Hawksworth: Serverless-Funktionen sind dafür perfekt. Dafür sind sie absolut ideal. Daher denke ich manchmal an serverlose Funktionen oder Funktionen eines Dienstes fast wie an eine Notluke, bei der Sie nur etwas Logik auf einem Server benötigen, aber keine ganze Infrastruktur erstellen müssen. Und Sie können immer mehr damit machen und die Entwicklungs-Pipelines für Entwicklungs-Workflows für Funktionen als Service reifen lassen. Es wird für JavaScript-Entwickler immer zugänglicher, diese Dinge auszubauen. Also, ja, ich denke wirklich, dass diese beiden Dinge sehr gut zusammenpassen.

Vitaly: Gut, das ist eine sehr umfassende Antwort. Tatsächlich habe ich erst kürzlich an einem Vortrag teilgenommen, bei dem ein Front-End-Ingenieur von Amazon über Serverless- und Lamda-Funktionen sprach, die sie verwenden – ich war fast weg. Er sprach immer über Docker und Kubernetes und all diese Dinge, Devox World, ich saß da ​​und dachte: „Wie ist er dort gelandet? Ich verstehe nicht, was los ist!“ Ich hatte keine Ahnung, was los ist.

Phil Hawksworth: Genau, aber die Sache ist die, es war früher … ich war … ich habe akzeptiert, dass ich nichts von dieser Welt verstehe, aber ich hatte keine Lust darauf, weil das für eine ganz andere Disziplin war . Und diese Disziplin ist immer noch sehr wichtig. Wissen Sie, Leute, die Infrastruktur entwerfen – das ist immer noch der Schlüssel. Aber jetzt fühlt es sich an, als wäre ich versucht. Als jemand mit Front-End-Entwicklungshintergrund, als JavaScript-Entwickler, bin ich viel mehr versucht, in dieser Welt spielen zu wollen, weil die Tools irgendwie näher zu mir kommen.

Phil Hawksworth: Es ist viel wahrscheinlicher, dass ich einige dieser Dinge verwenden und die Dinge irgendwie sicher liefern kann, anstatt nur als eigenes Experiment, wo ich früher gesprenkelt habe. Es fühlt sich also so an, als würden wir als Webentwickler mächtiger, was für mich aufregend ist.

Vitaly: Wie Power Rangers, nicht wahr?

Vitaly: Eines möchte ich Sie jedoch fragen, und das ist eigentlich etwas, das wir vielleicht schon vor einer Woche besprochen haben, aber ich wollte es trotzdem ansprechen, denn das einzige, was Sie in der Sitzung erwähnt haben, war der Begriff eine eigenständige Instanz jeder einzelnen Bereitstellung zu haben, was wirklich cool ist. Die Frage ist jedoch, wenn Sie eine große Aufgabe mit Zehntausenden von Seiten haben, möchten Sie wirklich nicht alles jedes Mal neu bereitstellen. Also, im Wesentlichen, wenn Sie, wie, wenn Sie hauptsächlich die statische Seite der Dinge verwenden. Also, wir hatten diese Idee für eine Weile und ich weiß, dass Sie das letzte Mal tatsächlich darauf angesprochen haben. Die Idee der atomaren Bereitstellungen.

Vitaly: Wo Ihnen tatsächlich buchstäblich eine Art Div zwischen zwei verschiedenen Versionen von Schnappschüssen des Setups serviert wurde. Wenn Sie also sagen, ändern Sie den Header überall, dann muss natürlich jede einzelne Seite neu bereitgestellt werden. Aber wenn Sie vielleicht eine Komponente ändern, wie zum Beispiel ein Karussell, das vielleicht nur 1000 Seiten betrifft, dann wäre es sinnvoll, 15000 Seiten neu bereitzustellen. Aber nur diese 1000. Können wir also dorthin gelangen? Ist es eine magische Idee, die da draußen ist, oder ist es etwas, das an diesem Punkt ziemlich greifbar ist?

Phil Hawksworth: Ich denke, das ist wahrscheinlich der Heilige Gral für Static-Site-Generatoren und diese Art von Modell, weil Sie sicherlich die größte Hürde identifiziert haben, die es zu überwinden gilt. Oder die größte Decke, an die Sie stoßen. Und das sind Websites mit vielen, Zehntausenden oder Hunderttausenden oder Millionen von URLs – die Vorstellung, dass der Build sehr lang werden kann. Es ist eine Herausforderung, anhand einer Codeänderung erkennen zu können, welche URLs sich ändern werden. Es ist nicht unüberwindbar, aber es ist eine große Herausforderung. Zu verstehen, was das Abhängigkeitsdiagramm auf Ihrer gesamten Website ist, und es dann intelligent bereitzustellen – das ist wirklich schwierig.

Phil Hawksworth: Wie Sie bereits erwähnt haben, kann eine Komponentenänderung sehr weitreichende Auswirkungen haben, aber Sie – es ist immer schwierig zu wissen, wie das funktionieren wird. Es gibt also eine Reihe statischer Site-Generatoren, die Projekte, die dieser Herausforderung etwas Gewicht beimessen und versuchen herauszufinden, wie sie teilweise Regenerierung und inkrementelle Builds durchführen. Ich freue mich sehr über die Aussicht, dass das Problem gelöst werden könnte, aber im Moment ist es definitiv eine große Herausforderung. Sie können anfangen, Dinge zu tun, wie zum Beispiel versuchen, Ihre Website logisch zu teilen, und wieder über ähnliche Probleme wie das Migrationsproblem nachdenken. Nun, dieser Abschnitt, den ich kenne, ist in Bezug auf einige der verwendeten Assets oder die Art der darin enthaltenen Inhalte unabhängig, sodass ich sie einzeln bereitstellen kann.

Phil Hawksworth: Aber das ist nicht ideal für mich. Das ist nicht wirklich das perfekte Szenario. Einer der Ansätze, die ich ein wenig untersucht habe, nur als Proof of Concept, ist das Nachdenken darüber, wie Sie Dinge tun, wie z. B. die intelligente Nutzung von 404-Befehlen. Ein großer Anwendungsfall für sehr große Schilder, vielleicht Nachrichtenseiten, ist also, wenn sie eine URL benötigen, wenn eine Eilmeldung passiert, müssen sie als Erste dafür sorgen, dass sie veröffentlicht wird. Sie müssen dort oben eine URL erhalten. Dinge wie die BBC News, Sie werden sehen, dass die Nachrichten auf der Website ankommen, und dann werden sie im Laufe der Zeit schrittweise etwas hinzufügen, aber es ist entscheidend, zuerst dorthin zu gelangen. Also, einen Build zu haben, der 10 Minuten, 20 Minuten dauert, was auch immer es sein wird, das könnte ein Problem sein.

Phil Hawksworth: Aber wenn ihr Inhalt abstrahiert ist und vielleicht früher von einer API aufgerufen wurde. Ich habe Content-Management-Systeme erwähnt, die abstrahiert sind, wie Contentful oder Sanity oder ein paar davon. Alles, was eine Inhalts-API hat, ändert sich in diese Inhaltsstruktur, die einen Build auslöst, und wir werden den Lauf durchlaufen, aber die andere Sache, die passieren könnte, ist, dass Sie Ihre URL dafür veröffentlichen und dann diese URL veröffentlichen , selbst wenn der Build nicht ausgeführt wurde, wenn jemand diese URL hackt, wenn der erste Stopp auf seinem 404 ist, anstatt zu sagen: „Wir haben es nicht“, ist tatsächlich, diese API direkt zu treffen, dann können Sie sagen , "Nun, der Build ist noch nicht fertig, um das zu füllen, aber ich kann es im Client tun." Ich kann direkt zur API gehen, das bekommen, es im Client füllen.

Vitaly: Hm, interessant.

Phil Hawksworth: Sogar während der Build noch im Gange ist, können Sie damit beginnen, diese Dinge zu bestücken. Und dann, sobald der Build fertig ist, würde er natürlich keinen 404 erreichen. Sie würden diese statisch laufende Seite treffen. Es gibt also Techniken und Strategien, um damit umzugehen, aber es ist trotzdem eine sehr lange, weitschweifige Antwort, es tut mir leid, aber meine Schlussfolgerung ist, ja, das ist eine Herausforderung. Daumen drücken, wir bekommen bessere Strategien.

Vitaly: Ja, das ist großartig. Ich frage mich also, an diesem Punkt denken wir wirklich nicht nur, was die Leistung in Bezug auf die Bereitstellung von Inhalten betrifft, sondern auch die Leistung in Bezug auf die Build-Geschwindigkeit. Wie Gebäudeeinsatz. Das ist also auch etwas, womit wir uns schon seit geraumer Zeit beschäftigen.

Vitaly: Eine Sache wollte ich Sie noch fragen. Das ist also interessant, wie diese Technik, die Sie erwähnt haben. Wie erfahren Sie davon? Dies ist nur etwas, was die Leute in der Regel in ihren eigenen Blogs veröffentlichen, oder ist es ein Medium oder gibt es ein zentrales Repository, in dem Sie eine Art Fallstudien finden können, wie JAMstack – wie Unternehmen beim Entladen umgezogen sind oder nicht umgezogen sind JAMstack.

Phil Hawksworth: Also, im Moment reift diese Landschaft ein bisschen. Ich meine, einige dieser Beispiele, ich denke, ich bin in einer sehr glücklichen Position, ich arbeite irgendwo, wo ich in einer Rolle bin, in der ich mit den Spielzeugen spiele, interessante Wege finde, sie zu benutzen und zu experimentieren mit ihnen. Diese Proofs of Concepts sind also gewissermaßen Dinge, mit denen ich experimentieren und versuchen kann, diese Herausforderungen anzugehen. Aber die, wie ich bereits erwähnt habe, eine Fallstudie, die auf der JAMstack-Konferenz in New York gezeigt wurde, und natürlich bei Veranstaltungen wie dieser, wir sehen allmählich, dass bei solchen Veranstaltungen über Best Practices oder Branchenpraktiken und Branchenansätze gesprochen wird von Veranstaltungen. Und sicherlich möchte ich mehr sehen und an mehr Fallstudien arbeiten, um an Orte wie Smashing Magazines zu gelangen, damit wir diese Informationen viel leichter teilen können.

Phil Hawksworth: Ich denke, große Unternehmen und der Unternehmensbereich übernehmen JAMstack allmählich, an verschiedenen Orten und auf unterschiedliche Weise, aber die Welt ist immer noch geneigt, dorthin zu gelangen, also denke ich, jedes Mal, wenn ein Unternehmen es einführt und seine teilt Erfahrung, daraus können wir alle lernen. Aber ich möchte wirklich, dass mehr und mehr dieser Fallstudien veröffentlicht werden, damit wir uns besonders darüber informieren können, wie diese Art von Herausforderungen bewältigt werden.

Vitaly: Okay, dann vielleicht nur die letzte Frage von mir, weil ich immer gerne Fragen lese. Also, das JAMstack-Land, wenn Sie etwas ändern könnten, gibt es vielleicht etwas, das Sie verzweifelt gerne sehen würden, jenseits von Bereitstellungen. Gibt es sonst noch etwas, das Sie sehr glücklich machen würde? Das würde Ihren Tag versüßen? Was würde das sein? Was steht auf deiner Wunschliste für JAMstack?

Phil Hawksworth: Was für eine Frage. Ich meine, wenn wir nicht über inkrementelle Builds gesprochen hätten, wäre das …

Vitaly: Das haben wir. Das ist jetzt zu spät. Diese Karte wurde bereits bestanden. Wir brauchen etwas anderes.

Phil Hawksworth: Also—

Vitaly: Was ich meine, wie auf einem Bahnsteig, wenn man sich den hinteren Bahnsteig ansieht, passieren so viele aufregende Dinge. Wir haben Houdini, wir haben kommende Webkomponenten und alles, da Sie die gesamte Landschaft aller richtigen Komponenten ändern könnten. Auf der anderen Seite haben wir all diese magische, ausgefallene Welt mit SS NGS, und natürlich haben wir auch Single-Page-Anwendungen und so. Worauf freust du dich am meisten?

Phil Hawksworth: Ich werde hier etwas begriffsstutzig sein, weil so viel passiert, es aufregend ist und es so viele neue Möglichkeiten gibt, die Sie im Browser nutzen können. Was mich wirklich begeistert, sind Menschen, die Zurückhaltung zeigen (lacht) und wie gesagt, langweilige Antworten, aber ich liebe es, großartige Hinrichtungen zu sehen, die mit Zurückhaltung durchgeführt werden, in einem nachdenklichen – über das breitere Publikum. Es macht wirklich viel Spaß und ist erfreulich, mit der glänzendsten neuen JavaScript-Bibliothek oder der neuen Browser-API zu bauen, die, ich weiß nicht, Scratch- und Sniff-Funktionen im Browser bietet, die wir jeden Tag dringend brauchen.

Phil Hawksworth: Aber ich mag es wirklich, Dinge zu sehen, von denen ich weiß, dass sie an vielen, vielen Orten funktionieren werden. Sie werden wirklich leistungsfähig sein, werden mit den existierenden Browsern sympathisieren – nicht nur auf den Schreibtischen von CEOs und CTOs, die die schicken Spielzeuge haben, sondern auch von Leuten, die Geräte mit viel geringerer Leistung haben, oder sie Ich habe herausfordernde Netzwerkbedingungen und solche Dinge. Ich sehe gerne interessante Erfahrungen und reichhaltige Erfahrungen, die auf eine Weise präsentiert werden, die mit der Plattform sympathisch ist, und irgendwie mitfühlend für das breitere Publikum, weil ich denke, dass das Web viel weiter reicht als wir, die Entwickler, die Dinge dafür bauen . Und ich bin begeistert, wenn ich sehe, wie interessante Dinge auf eine Weise getan werden, die mehr Menschen erreicht.

Phil Hawksworth: Das ist wahrscheinlich nicht unbedingt die Antwort, die Sie waren –

Vitaly: Oh, das ist ein schönes Ende. Ich danke dir sehr. Nein, das ist perfekt, das ist es wirklich. In Ordnung, ich hatte das Gefühl, dass alles gut gelaufen ist! Vielen Dank, dass Sie bei uns sind! Ich verteile an Scott!

Phil Hawksworth: Großartig!

Vitaly: Ich bin nur hier, um Fragen und Antworten zu spielen. Also, vielen Dank, Phil! Ich bin immer noch hier, aber Scott, die Bühne gehört jetzt dir! Vielleicht können Sie uns mitteilen, was als nächstes auf Smashing TV ansteht?

Scott: Das werde ich, aber zuerst, Phil, kann ich es kaum erwarten zu sehen, wie die Implementierung der Scratch-and-Sniff-API funktioniert. Klingt sehr interessant. Und, Vitaly, JAMstackify ist bereits vergeben.

Vitaly: (niedergeschlagen) Besetzt?! Können wir es kaufen?

Scott: Nein, es existiert!

Vitaly: Nun, das ist zu spät. Ich bin immer zu spät.

Phil Hawksworth: Das ist auf seine Weise spannend.

Vitaly: Das ist die Geschichte meines Lebens. Ich bin immer zu spät.

Scott: Die nächsten Mitglieder kommen, glaube ich, am Donnerstag, dem 13., wir haben meinen alten Vater, Zach Leatherman, der darüber spricht, worüber er am besten spricht, nämlich Schriftarten. Er spricht also von den fünf Ys der Font-Implementierung. Und dann interessiere ich mich auch sehr für die, die wir am 19. haben, und zwar Videobearbeitung mit JavaScript und CSS mit Eva Faria. Bleiben Sie also dran für beide.

Scott: Also, nächsten Donnerstag wieder mit Zach Leatherman und dann am 19. mit Eva, die über das Bearbeiten von Videos in JavaScript und CSS sprechen wird. In diesem Sinne, Phil, ich kann dich nicht mehr sehen, bist du noch da?

Phil Hawksworth: Ich bin hier!

Scott: In diesem Sinne vielen Dank an alle! Ist auch jemand in der Nähe von Toronto? Oder jemand, der schon immer Toronto besuchen wollte? Wir haben Ende Juni eine Konferenz, und es sind noch ein paar Tickets übrig. Also, vielleicht sehen wir einige von euch dort.

Vitaly: Vielen Dank an alle anderen!

Vitaly: Ach übrigens, noch was! Vielleicht hat Phil es erwähnt, aber wir haben auch die JAMstack-Konferenz im Juli in London. Also, das ist auch etwas, worauf man achten sollte. Aber ich melde mich ab und hole meinen Salat! Ich bin mir nicht sicher, was Sie—

Scott: Okay, auf Wiedersehen, alle zusammen!

Vitaly: In Ordnung, auf Wiedersehen, alle zusammen.

Das ist ein Wrap!

Wir danken Smashing Members von ganzem Herzen für ihre kontinuierliche und freundliche Unterstützung – und wir können es kaum erwarten, in Zukunft weitere Webinare zu veranstalten.

Außerdem wird Phil nächste Woche auf der SmashingConf Toronto 2019 und auf der JAMstack_conf MCing sein – wir würden uns freuen, Sie auch dort zu sehen!

Bitte lassen Sie uns wissen, ob Sie diese Reihe von Interviews nützlich finden und wen Sie gerne interviewen würden oder welche Themen wir behandeln sollen, und wir werden uns gleich darum kümmern.