Smashing Podcast Folge 29 mit Leslie Cohn-Wein: Wie funktioniert Netlify Dogfood The Jamstack?

In dieser Folge fragen wir, wie es aussieht, den Jamstack bei Netlify zu dogfooden. Können Sie eine ganze App in einem CDN bereitstellen? Drew McLellan spricht mit Netlify Staff Engineer Leslie Cohn-Wein, um es herauszufinden.

Notizen anzeigen

• Leslies persönliche Seite
• Leslie auf Twitter
• Netlify

Wöchentliches Update

• Ein tiefer Einblick in React und Three.js mithilfe von „React-Three-Fiber“.
  geschrieben von Fortune Ikechi
• Best Practices für das Design von E-Commerce-Benutzeroberflächen
  Geschrieben von Suzanne Scacca
• Authentifizieren von React-Apps mit Auth0
  geschrieben von Nefe Emadamerho-Atori
• Von den Experten: Globale Entwicklungen der digitalen Zugänglichkeit während COVID-19
  geschrieben von Robin Christopherson
• Was ist neu in Vue 3?
  geschrieben von Timi Omoyeni

Abschrift

Drew McLellan: Sie ist eine preisgekrönte Frontend-Spezialistin, die ursprünglich aus Austin stammt, aber jetzt über einen Aufenthalt in New York City in Dallas, Texas, lebt. Während dieser Zeit arbeitete sie für Agenturen und erstellte Websites für Kunden wie Nintendo, WorldPride und Jerry Seinfeld. Sie ist jetzt Frontend-Ingenieurin bei Netlify, wo sie unter anderem an der Entwicklung der Anwendung arbeitet, die Kunden zur Verwaltung ihrer Dienste und Bereitstellungen verwenden. Wir wissen also, dass sie eine versierte Frontend-Ingenieurin ist, aber wussten Sie, dass sie, als sie in New York City lebte, drei Jahre in Folge als stellvertretende Chili-Cook-off-Richterin diente? Und das stimmt tatsächlich. Meine großartigen Freunde, bitte heißen Sie Leslie Cohn-Wein willkommen. Hallo Leslie. Wie geht es dir?

Leslie Cohn-Wein: Ich bin der Hammer.

Drew: Ich wollte heute mit Ihnen darüber sprechen, wie Netlify sein eigenes Hundefutter isst, um diesen charmanten Ausdruck zu verwenden, wenn es darum geht, auf dem Jamstack aufzubauen. Ich sollte das ein wenig in Zusammenhang bringen, indem ich sage, dass wir bis vor ein paar Monaten im selben Team bei Netlify zusammengearbeitet haben. Und als ich dort ankam, war mir der Entwicklungsprozess auch nach 20 Jahren als Entwickler eigentlich sehr fremd. Ich fand es einfach sehr faszinierend und es lohnt sich, es mit einem breiteren Publikum ein wenig zu erkunden. Ich sollte wahrscheinlich darauf hinweisen, dass wir darüber sprechen, weil es eine wirklich interessante Fallstudie darstellt und keine gesponserte große Anzeige für Netlify ist. Jeder sollte sich Vercel ansehen. Aber ich denke, es gibt viele wertvolle Dinge, die man aus der Diskussion darüber lernen kann, insbesondere aus der Sicht von Jamstack. Weil Netlify ein wirklich großer Befürworter des Jamstack-Ansatzes ist und der Service dem Kunden quasi angeboten wird und auf der Idee des Aufbaus von Jamstack-Projekten basiert. Aber auch der Service selbst wird nach diesen Prinzipien aufgebaut. Ist es nicht?

Leslie: Das ist es, ja. Viele Leute betrachten diese Jamstack-Architektur als statische Sites, aber wir machen uns wirklich Gedanken darüber, was es bedeutet, eine Jamstack-App mit dem Netlify-Frontend zu erstellen. Weil es eine React-App ist, die eine vollständige Jamstack-App ist, stellen wir Netlify auf Netlify bereit, also … Ja, wir probieren es wirklich aus und gehen an die Grenzen des Möglichen.

Drew: Ich denke, es gibt manchmal die Idee, dass Jamstack großartig für statische Websites ist, wie Sie sagen, und der API-Aspekt kommt ins Spiel, wenn Sie ein Formular an eine E-Mail-Adresse senden möchten, und Sie können so etwas Einfaches tun, aber Sie kann auf diese Weise möglicherweise eine ganze Web-App erstellen. Aber das tust du, nicht wahr?

Leslie: Ja, absolut. Unsere App, die speziell darüber spricht, was Sie sehen, wenn Sie sich bei app.netlify.com anmelden, wird betrieben von … wir haben eine interne REST-API, aber das Frontend ist, wie gesagt, reines Jamstack. Wir haben also unseren eigenen Build-Schritt, wir beobachten die App, während sie in der App erstellt wird, und wir stellen sie auf unserem eigenen System bereit.

Drew: Also, wenn ein Backend-Prozess beteiligt ist, und es wird immer eine Art von Backend-Prozessen geben, wissen Sie, persistente Daten oder, in Netlifys Fall, beginnend mit einer Bereitstellung oder was auch immer, dieses Backend einfach wird als eine Reihe von APIs erstellt, die dann vom Frontend verwendet werden können?

Leslie: Ja, also gibt es ein paar verschiedene Modelle, wie man das zum Laufen bringen kann. In den meisten Fällen verwenden wir in unserer App clientseitiges Abrufen mit React, richtig? Wir stellen also eine Art statische Shell der App bereit und rufen dann die Benutzerinformationen zum Zeitpunkt der Anfrage von unserer internen REST-API ab. Jamstack ist interessant, weil es einige Dinge gibt, die Sie vorab erstellen können, und wir versuchen, uns darauf zu verlassen, wenn wir können. Und wenn wir über einige der dynamischeren Daten sprechen, verwenden wir das clientseitige Abrufen, um sicherzustellen, dass wir die aktuellsten Daten abrufen.

Drew: Ich denke, es hat mich überrascht, als ich anfing, an der App zu arbeiten, wie viel im Frontend erreicht wird, insbesondere wenn es um die Interaktion mit externen APIs und Dingen geht. Ich weiß, dass, wenn Netlify mit Ihrem Git-Provider interagiert, es also zu GitHub geht und eine Liste mit Repos erhält, das alles zwischen Ihrem Browser und GitHub passiert. Und abgesehen vielleicht von dem Durchlaufen einer serverlosen Funktion, die einige Geheimnisse in die Anfrage einfügt, oder so etwas Leichtes, passiert das meiste einfach auf eine Jamstack-artige Art und Weise. Es geht nicht durch eine Netlify-Kern-Backend-Infrastruktur. Also, das ist ziemlich faszinierend. Das geht wirklich so viel weiter als nur eine statische Seite mit ein paar API-Aufrufen, um kleine Dinge zu tun. Das ist die eigentliche Kernfunktionalität, nicht wahr, die im Browser implementiert wird?

Leslies: Absolut. Ich denke, es treibt das Konzept eines Frontend-Entwickleringenieurs wirklich voran, oder? Und es ist etwas, das mich als Frontend-Ingenieur dazu antreibt, besser zu werden und mehr über diese Art von … der API-Schicht nachzudenken, was etwas ist, dem ich traditionell nicht so nahe war. Ich arbeite mehr mit UI und Farben und Designsystemen, und so ist es wirklich … Ich habe tatsächlich festgestellt, dass die Arbeit an einer Jamstack-App in großem Maßstab mich dazu gebracht hat, ein besserer Entwickler zu sein.

Drew: Ein Frontend-Entwickler zu sein heißt, CSS nicht von Grund auf zu kennen, obwohl das ein Teil davon ist. Es ist nicht, HTML von Grund auf zu kennen, aber das gehört dazu. Es verirrt sich auch in dieses Gebiet, das traditionell die Domäne eines Backend-Ingenieurs war, was ziemlich interessant ist. Verwendet Netlify ein neues serverseitiges Rendering für

Leslie: Nicht, dass ich wüsste.

Drew: Also, es ist alles buchstäblich erledigt, wie Sie sagen, Sie bedienen eine Shell, und dann wird sie mit Anfragen zurück zu verschiedenen API-Endpunkten gefüllt, um sozusagen alles zu füllen.

Leslies: Genau.

Drew: Und du sagst, es ist eine React-App?

Leslies: Ja. Jawohl. Reagieren. Wir verwenden im Moment React Redux und im Moment sind wir PostCSS, aber wir experimentieren auch mit unserer CSS-Architektur.

Drew: Sind wir das nicht alle? Sie erstellen die App also in React und stellen sie dann auf Netlify bereit?

Leslies: Ja. Vielleicht ist mein Lieblingsteil dieses ganzen Prozesses die Magie von Deploy Previews, die wir durch Netlify erhalten. Was also passiert ist, Sie werden… Sie arbeiten in GitHub, Sie steigern Ihre PR. Sie öffnen also Ihre PR in GitHub, und das wird automatisch einen Build Ihrer Deploy Preview der App erstellen. Also verwenden wir Deploy Previews der App selbst zum Testen, um sicherzustellen, dass alles so funktioniert, wie es sollte. Wir führen unsere Tests durch. Das verwenden wir, um während der Codeüberprüfung manuell zu überprüfen. Wir haben also sozusagen all diese kontinuierliche Bereitstellung direkt von GitHub aus eingerichtet.

Leslie: Und eines der anderen coolen Dinge, die wir eingerichtet haben, ist, dass wir tatsächlich ein paar verschiedene Netlify-Sites haben, die aus demselben Repository ziehen, in dem sich unsere App befindet. Wir haben also sowohl unsere App als auch eine Instanz von Storybook, die eine Art unserer UI-Komponenten für die App enthält. Wir haben also unsere App selbst, wir haben die Storybook-UI-Komponenten und wir haben im Grunde eine Netlify-Site, die unsere Storybook-UI zeigt. Und dann haben wir noch eine dritte Seite, die einen Webpack-Bundle-Analyzer betreibt. Es handelt sich also um eine visuelle Benutzeroberfläche, die Ihnen eine Baumkarte und eine Visualisierung aller App-Bundles bietet, und wir können ihre Größe gewissermaßen abschätzen, und es ist nur eine Erinnerung für uns, es noch einmal zu überprüfen. Bei jedem Deployment der App können wir überprüfen und sicherstellen, dass wir dort nichts Ungewöhnliches mit unserer Bundle-Größe machen. Alle drei dieser Sites werden also in einem Pull Request der App generiert. Sie erhalten also Links zur Vorschau, im Wesentlichen zu Ihren Bereitstellungsvorschauen, sowohl des App-Storybooks als auch zu diesem App-Profil, damit wir es überprüfen können.

Drew: Und mit den Bereitstellungsvorschauen wird das im Wesentlichen zu Ihrer Staging-Umgebung, oder?

Leslies: Genau. Wir betreiben nicht wirklich eine traditionelle Staging-Umgebung, weil wir wirklich darauf vertrauen, dass unsere Bereitstellungsvorschauen im Wesentlichen das sind, was live gehen wird, wenn wir auf die Zusammenführungsschaltfläche klicken und den offiziellen Build unseres Hauptzweigs in unserer Haupt-App starten. Daher finde ich es toll, dass wir uns auf Deploy Previews als Staging-Umgebung verlassen können. Wir vertrauen wirklich darauf, dass es mit der Produktion übereinstimmen wird. Wir bauen es mit all den Produktionsvariablen, allem, was … Umgebungsvariablen, all diese Dinge werden in der Bereitstellungsvorschau eingebaut. Es ist also so ziemlich eine Situation, in der Sie sich keine Sorgen machen müssen. Solange Ihre Bereitstellungsvorschau funktioniert, wissen Sie, dass die App auch funktionieren wird.

Drew: Und ich denke, wenn Ihre Bereitstellungsvorschau als Unternehmen nicht mit dem übereinstimmt, was live gestellt wird, dann ist das ein Serviceproblem, das Netlify lösen möchte. Also, es funktioniert eigentlich ganz gut aus dieser Sicht. Sie haben also eine Bereitstellungsvorschau überprüft, alles sieht gut aus, die PR wird zusammengeführt. Was passiert dann?

Leslie: Da Netlify unser gesamtes kontinuierliches Deployment ausführt, haben wir im Wesentlichen alles miteinander verbunden, sodass jede Zusammenführung mit unserem Hauptzweig automatisch ein offizielles Produktionsdeployment mit der App auslöst. Wenn Sie also der Entwickler sind, der Ihre eigene PR zusammengeführt hat, werden Sie in der Regel in die eigentliche… Sie müssen sicherstellen, dass Sie Ihre Tabs noch einmal überprüfen, denn wenn Sie eine Deploy Preview der App geöffnet haben und die App, Sie müssen sicherstellen, dass Sie normalerweise in der echten App mitmachen möchten. Sie müssen also Ihren Tab überprüfen. Aber ja, in der App gehen Sie normalerweise hinein, Sie können die Build-Protokolle für diese Zusammenführung ansehen, die Sie gerade gestartet haben, also ist alles automatisch. Und sobald diese Build-Protokolle abgeschlossen sind und die Website live ist, müssen Sie nur noch Ihr Browserfenster aktualisieren und sehen, was Sie gerade bereitgestellt haben, sollte in der App aktualisiert werden.

Drew: Und sagen wir mal, du erkennst ein Problem, sobald es live gegangen ist, was machst du dann?

Leslie: Das ist eine sehr gute Frage. Und vielleicht eine meiner Lieblingsbeschäftigungen bei der Verwendung von Netlify, noch bevor ich bei Netlify gearbeitet habe, war dies wie ein bisschen Magie für mich, weil Netlify sozusagen Rollbacks eingebaut hat, wie wir es nennen. Also im Grunde jede Bereitstellung auf Netlify … da wir diese Jamstack-Architektur verwenden, ist jede Bereitstellung atomar. Das bedeutet also, dass Sie über diesen vollständigen Verlauf aller Arten von Bereitstellungen verfügen, die Sie jemals auf einer Website vorgenommen haben, und Sie können sofort auf eine davon zurückgreifen. Wenn wir also versehentlich einen Fehler bereitstellen oder etwas kaputt ist, ist das erste, was wir normalerweise tun, dass wir diese kontinuierliche Integration tatsächlich stoppen. Wir gehen also hinein und es ist nur eine Schaltfläche in der Netlify-Benutzeroberfläche, auf die Sie sagen: „Stopp die automatische Veröffentlichung“, und das wird diese Verbindung mit GitHub beenden. Also, wenn mein Teamkollege plötzlich auch seine PR zusammenführt, werden wir den Fehler nicht wieder einführen, nichts dergleichen wird passieren.

Leslie: Also stoppen wir all diese automatischen Bereitstellungen. Und dann muss ich nur noch zu meiner Deployment-Liste zurückkehren und das letzte funktionierende Deployment finden, eine weitere Schaltfläche mit der Aufschrift „Publish this one“ drücken und es geht live. Das nimmt also den Druck, wirklich zurückgehen zu können, sich den Code anzusehen und herauszufinden, was tatsächlich passiert ist. Manchmal bedeutet das, einen Git-Revert auf Ihrem Hauptzweig durchzuführen und den Hauptzweig wieder dorthin zu bringen, wo er sein sollte. Und manchmal ist es ein Hotfix oder Sie gehen auf einen Zweig und Sie bekommen es repariert und müssen sich nicht einmal Gedanken über die Wiederherstellung in Git machen. Und dann, wenn Sie bereit sind, zurückzukehren, stellen Sie sicher, dass alles in Ihrer Bereitstellungsvorschau der App funktioniert, und Sie können all diese Dinge einfach zurücksetzen. Sobald Sie also mit diesen automatischen Bereitstellungen beginnen, sind Sie im Grunde wieder im Geschäft.

Drew: Also, ich habe hier ein Problem entdeckt.

Leslie: Oh oh.

Drew: Sie verwenden Netlify, um Änderungen an der Netlify-App bereitzustellen. Was ist, wenn der Fehler, den Sie bereitgestellt haben, Sie an einem Rollback hindert? Was machst du dann?

Leslie: Ich habe Alpträume. Nein. Eigentlich haben wir ein paar Möglichkeiten, wie wir damit umgehen könnten. Wenn wir also die App herunterfahren und die Benutzeroberfläche nicht verwenden können, um diesen Prozess zu durchlaufen, laufen unsere Deploy Previews tatsächlich gegen unsere Produktions-API. Das bedeutet also, selbst wenn die App nicht funktioniert, haben wir immer noch diese atomaren Deployments. Wenn Sie also einen Link von GitHub haben, vielleicht von einem alten oder neueren PR, und Sie diese Bereitstellungsvorschau-URL haben, können Sie tatsächlich auf die Bereitstellungsvorschau der App zugreifen und alle erforderlichen Änderungen vornehmen, zurückgehen und eine ältere Bereitstellung veröffentlichen aus der Bereitstellungsvorschau. Und es trifft immer noch unsere Produktions-API, was sich immer noch auf die App auswirkt, und das bringt die App dann wieder zum Laufen. Es ist wie eine Art explodierendes Gehirn-Emoji, aber es ist eine Möglichkeit, es zu tun. Wir könnten auch ein älteres Deployment von einigen unserer Backend-Systeme veröffentlichen. Wir könnten unsere Backend-Ingenieure dazu bringen, das für uns zu veröffentlichen. Oder Sie können immer Git verwenden, um zurückzukehren und zu versuchen, das nach oben zu verschieben, aber es ist ein bisschen beängstigend, weil Sie nicht sehen können, was Sie tun.

Drew: Ich schätze, man braucht einfach einen sehr klaren Kopf, um mit dieser Situation umzugehen.

Lesly: Ja.

Drew: Aber es ist vollständig wiederherstellbar, es hört sich so an.

Lesly: Ja. Nun, und sobald Sie Ihre Arbeitsbereitstellung veröffentlicht haben, ist der ganze Druck weg. Das ist wirklich der schönste Teil. Und das fand ich auch in Agenturen. Die Möglichkeit, ein Rollback durchzuführen, war wirklich ein Lebensretter … Es macht Ihnen auch weniger Sorgen über die Veröffentlichung neuer Änderungen. Wenn Sie etwas kaputt machen, dauert es eine Sekunde, um es zurückzurollen, was sehr gut zu der Art passt, sich schnell zu bewegen und Dinge herauszubekommen.

Drew: Definitiv. Ich denke, normalerweise funktioniert diese Art von Arbeitsablauf am besten, wenn Sie es mit wirklich kleinen Änderungen zu tun haben. Ich meine, im Idealfall möchten Sie einen Zweig erstellen, eine kleine Änderung implementieren, eine PR erhöhen und das dann so schnell wie möglich wieder zusammenführen. Das funktioniert offensichtlich gut für Optimierungen, Fehlerkorrekturen und kleine Dinge, aber es funktioniert nicht so gut für die Arbeit an wichtigen Funktionen, wenn diese Funktion Wochen oder vielleicht sogar Monate vom Start bis zur Bereitstellung dauern kann. Wie managen Sie einen solchen Prozess?

Leslie: Ja, das ist eine großartige Frage. Daher haben wir kürzlich damit begonnen, Feature-Flags etwas mehr zu verwenden. Bevor ich ein bisschen mehr darüber erzähle, wie wir das machen, werde ich darüber sprechen, was wir früher gemacht haben. Also, bevor wir Feature-Flags verwendet haben, denke ich, dass jeder mit der Idee des langlaufenden Feature-Zweigs irgendwie vertraut ist. Wir alle hassen sie irgendwie, oder? Aber wir würden an unseren kleineren PRs arbeiten. Wir würden diese einzeln nach der Codeüberprüfung in diesen länger laufenden Feature-Zweig zusammenführen. Sie hätten also im Grunde genommen alle Ihre neuen Funktionen an einem Ort, Sie könnten eine Bereitstellungsvorschau haben, mit der Sie diese neue Funktion testen können. Manchmal erforderte dieses Modell koordinierte Bereitstellungen über andere Teams hinweg. Wenn wir also bereit waren zu sagen: „Okay, dieser Feature-Zweig, wir sind bereit, ihn zusammenzuführen und live zu bringen“, bedeutete das gelegentlich: „Okay, Sie müssen sicherstellen, dass das Backend seine Änderung bereits implementiert hat“, also was auch immer Die API-Arbeit, die wir in unserem Feature durchführen, ist einsatzbereit. Wenn es Dokumente auf unserer Dokumentseite gibt, die gleichzeitig mit dem Feature live gehen müssen, müssen Sie sich irgendwie koordinieren und gleichzeitig auf die Schaltflächen klicken.

Leslie: Dieses Modell ist… es hat bei uns funktioniert, aber Sie haben Recht, dass es vielleicht nicht das glatteste war. Es ist eigentlich schon komisch, dass unser Mitbegründer und CEO von Netlify, Matt Biilmann, letztes Jahr unsere Analysefunktion mit diesem Prozess auf der Bühne der Jamstack Conf London eingeführt hat. Also nutzte er unsere Lock-Deployment-Funktion, um im Grunde die Deploy-Vorschau der neuen Analysefunktion zu nehmen und sie live auf der Bühne zu veröffentlichen. Das war ziemlich cool.

Leslie: Aber, wie Sie sagten, es ist… Sie haben ein bisschen weniger Selbstvertrauen. In diesem Pull Request ist noch alles versteckt. Es wird etwas unhandlich. Jemand muss diesen letzten Pull-Request genehmigen, der normalerweise ziemlich groß ist. Das ist ein wenig überwältigend. Heutzutage verwenden wir also hauptsächlich Feature-Flags. Wir verwenden einen Dienst namens LaunchDarkly, mit dem wir unsere Benutzeroberfläche für neue Funktionen im Grunde mit diesen Flags umschließen können, sodass wir Code kontinuierlich zusammenführen können, selbst wenn die Benutzeroberfläche nicht etwas ist, von dem wir möchten, dass Kunden es sehen. Stellen Sie also in der Produktionsumgebung sicher, dass Ihr Feature-Flag deaktiviert ist, wir den Code bereitstellen und zusammenführen können, und niemand … vorausgesetzt, Sie sind ein allgemeiner Benutzer, werden Sie diese neue Benutzeroberfläche nicht sehen.

Drew: Ein Feature-Flag ist also im Grunde wie ein Schalter im Code, der besagt: „Wenn diese Funktion aktiviert ist, verwenden Sie diesen neuen Code, andernfalls verwenden Sie diesen alten Code.“

Leslies: Genau.

Drew: Bedeutet das, dass Sie mit all diesen Gabeln eine Art unordentliche Codebasis bekommen? Wie gehen Sie damit um?

Leslie: Ja, ich denke, das ist … jeder, der Feature-Flags verwendet, ist wahrscheinlich an diese Art von Kampf gewöhnt, wann bereinigen Sie die Feature-Flags? Wie lange lässt du sie dort? Wir sind ungefähr zwei Wochen nach der Veröffentlichung eines wichtigen Features gelandet, wir haben Erinnerungen. Glücklicherweise hat LaunchDarkly kürzlich eine Funktion eingerichtet, die Slack benachrichtigt. Sie können es also mit Slack verbinden und es wird Ihnen nur sagen: „Hey, Ihr Feature-Flag war … Sie waren zwei Wochen lang live in der Produktion. Es ist an der Zeit, dafür zu sorgen, dass Sie Ihre Flagge im Code bereinigen.“

Leslie: Also, wir versuchen es und räumen es ziemlich schnell auf, aber es ist schön zu wissen, dass die Flagge in der Zwischenzeit immer noch da ist. Selbst wenn Sie die Funktion veröffentlicht haben, bedeutet dies, dass Sie mit einem Klick wieder hineingehen und das Flag wieder ausschalten können, wenn ein Fehler vorliegt, wenn etwas auftaucht. Also lassen wir sie gerne ein wenig drin, nur während das Feature wirklich backt, während sich die Leute daran gewöhnen, um sicherzustellen, dass es keine größeren Probleme gibt. Aber dann versuchen wir, zurück in den Code zu gehen, und es ist ein bisschen Aufräumen, also ist es kein idealer Prozess, aber normalerweise dauert das Entfernen des Flags nicht sehr lange, Sie löschen nur ein paar Codezeilen.

Drew: Also, ich denke, der einfachste Ansatz zum Implementieren eines Feature-Flags könnte einfach ein … wie eine Konfigurationsvariable in Ihrer App sein, die besagt: „Dieses Feature ist ein- oder ausgeschaltet“, aber dann müssen Sie eine Möglichkeit haben, dies sicherzustellen es ist für die richtigen Leute an und für die richtigen Leute aus. Und ich schätze, hier kommt ein Dienst wie LaunchDarkly ins Spiel, weil er das braucht … Ich meine, es braucht im Grunde das, was das Ein- und Ausschalten einer Variablen auf einem extremen Niveau ist, nicht wahr?

Leslies: Ja. Jawohl. Genau das ist es. Es gibt also Möglichkeiten, wie wir auch ohne LaunchDarkly im Grunde selbst eine Konfigurationsvariable einrichten könnten, die wir auf unserer Seite irgendwie verwalten. Eines der Dinge, die ich an LaunchDarkly liebe, ist, dass es verschiedene Umgebungen gibt. Wir können also im Wesentlichen ein Feature-Flag für unsere Deploy Previews aktivieren. Jeder, der sich intern bei Netlify eine Deploy-Vorschau der App ansieht, kann Zugriff auf die neue Funktion haben, sie ausprobieren, aber andererseits, sobald sie in Produktion geht, ist dieses Flag deaktiviert. Also, es gibt sehr wenig … noch einmal, Sie müssen Ihren Tab überprüfen und sicherstellen, dass Sie sich darüber im Klaren sind, in welchem ​​​​Segment Sie sich befinden, weil Sie sich nicht selbst überraschen wollen und glauben, dass Sie etwas in der Art gestartet haben hast du nicht, da musst du ein bisschen aufpassen. Aber im Allgemeinen funktioniert es recht gut, und mit LaunchDarkly können Sie auch diese selektiven Rollouts durchführen. Sie können also eine Funktion für einen bestimmten Prozentsatz Ihrer Codebasis oder für ein bestimmtes Benutzersegment, Personen mit einem bestimmten Plantyp oder einen bestimmten Benutzertyp einführen. Es gibt dir also viel mehr Kontrolle darüber, an wen du etwas veröffentlichst.

Drew: Ja. Das kann sehr leistungsfähig sein, denke ich, insbesondere bei neuen Funktionen oder Funktionen, von denen Sie erwarten, dass sie ein Problem lösen. Vielleicht verbessern Sie eine Funktion, um sie verständlicher zu machen, Sie können es vielleicht mit 10 % der Benutzer ausprobieren und sehen, ob sie dieselben Probleme haben und …

Leslies: Genau. Es ist auch eine großartige Möglichkeit, Feedback zu erhalten, ja.

Drew: Ich denke, LaunchDarkly auf diese Weise zu verwenden, anstatt eine eigene Lösung zu entwickeln, ist eine Art weiterer Aspekt des Jamstack-Ansatzes, nicht wahr? Es ist nur die Verwendung einer API, die Ihnen diese Funktionalität bietet, ohne sich Gedanken darüber machen zu müssen, wie Sie das selbst implementieren und wie Sie es entwickeln und wie Sie es warten und behalten, damit Sie es einfach auslagern können, sagen Sie: „Richtig, wir sind Ich werde diese API verwenden und alles andere wird erledigt.“

Leslie: Ja. Ja, genau.

Drew: Dieser Ansatz ermöglicht es Ihnen also, im Wesentlichen kleine Teile neuer Funktionen in die Produktion zu übernehmen, aber sie sind nur irgendwie hinter der Flagge versteckt. Und wenn alles bereit ist, können Sie einfach die Flagge umdrehen und sie schnell wieder zurückstellen, wenn etwas schief geht.

Leslie: Ja, genau. Das macht unsere Produkteinführungen etwas weniger aufregend. Früher haben Sie diese großen Knöpfe gedrückt und all dieser Code wird zusammengeführt und Sie beobachten Ihre Build-Protokolle und es ist dieser Moment der Vorfreude. Und jetzt steigen Sie in einen Zoom-Anruf ein, klicken auf eine Schaltfläche und es ist live.

Drew: Ja. Ich denke, beim letzten Feature-Launch habe ich an Netlify gearbeitet, wir haben diesen Ansatz verwendet. Und es waren wochenlange Arbeit für ein ganzes Team von Leuten, und wir bekamen einen Zoom-Anruf, um die Veröffentlichung zu koordinieren, und alle bestätigten, dass ihre Teile fertig waren. Und dann habe ich das Feature-Flag umgedreht und für alle Benutzer aktiviert, und das war es.

Leslie: Fertig.

Drew: Und es war in ein paar Minuten vorbei und es war wirklich enttäuschend.

Leslie: Ja, es ist irgendwie traurig.

Drew: Es gab keine verschwitzten Handflächen, es gab nichts, was natürlich genau das ist, was Sie wollen, nicht wahr? So wissen Sie, dass Sie einen robusten Prozess haben, wenn es keine große Sache ist, etwas für alle zu aktivieren.

Leslies: Genau. Und wenn Sie es wieder zurückrollen müssen, ist es so einfach, es ist dieser eine Klick. Es entlastet etwas von diesem Druck, Angst.

Drew: Also, ich meine, vermutlich werden nicht alle Änderungen nur Frontend-Änderungen sein. Manchmal wird es Backend-Änderungen geben, und vermutlich haben sie in den meisten Backend-Systemen auch ihre eigenen Feature-Flags. Sie haben also auch Dokumente erwähnt. Gibt es eine Möglichkeit, das alles miteinander zu koordinieren? Hissen alle gleichzeitig ihre Flaggen? Oder wie geht das?

Lesly: Ja. Das ist also ein Bereich, an dem wir gerade in den Teams bei Netlify aktiv arbeiten, wir arbeiten an einer Lösung, die es uns ermöglichen würde, vielleicht alles an ein einziges Flag in LaunchDarkly zu binden, das alle unsere Systeme verwenden , alle unsere Codebasen verwenden. In einer idealen Welt könnten wir also ein Flag umdrehen und sagen: „Okay, das ist das Umschalten des neuen API-Endpunkts, der auch im Frontend mit dieser neuen Benutzeroberfläche verwendet wird, die in ein Feature-Flag gehüllt ist. sowie dieser Teil der Dokumentationsseite, der neue Informationen zu dieser neuen Funktion enthält.“ Und wenn Sie dieses eine Flag darin umdrehen, wirkt es sich auf alle diese Repositories aus. So weit sind wir noch nicht. Wir arbeiten daran, aber ich bin gespannt, ob wir das alles koordinieren und zum Laufen bringen können.

Drew: Netlify als Service ist in dieser Hinsicht sehr auf Baustellen zugeschnitten. Hat die Arbeit, die Sie und Ihr Team mit dem Produkt leisten, tatsächlich die Produktentwicklung beeinflusst?

Leslie: Ich würde sagen, das tut es definitiv. Jeder sagt immer, dass Sie nicht Ihr Benutzer sind, was meiner Meinung nach meistens zutrifft, außer manchmal, wenn Sie Ihr Benutzer sind. Was bei Netlify lustig ist, weil ich denke, dass die meisten Leute im Frontend-Team vor allem Leute sind, die Netlify schon einmal als Produkt verwendet haben. Und da wir Netlify zum Bereitstellen von Netlify verwenden, stoßen wir auf die gleichen Herausforderungen, die meiner Meinung nach einige unserer Benutzer haben. Wenn wir also auf ein Problem stoßen, versuchen wir in gewisser Weise, es dem Rest des Unternehmens zur Sprache zu bringen. Wir erwähnen es in einem technischen Anruf oder wir ziehen unseren CTO hinzu und sagen: „Hey, das ist etwas, womit wir zu kämpfen haben. Gibt es etwas, das wir in das Produkt einbauen könnten, das dies für uns und alle unsere Benutzer, die ähnliche Dinge wie wir einsetzen, einfacher machen würde?“ Es ist also eine Art einzigartige Position, aber es macht Spaß zu sehen, wie die Produkt-Roadmap entwickelt wird.

Drew: Ich denke, es gibt wahrscheinlich nur wenige Leute da draußen, die Netlify so intensiv nutzen wie Netlify selbst.

Lesly: Ja. Ja. Ich denke, das ist ungefähr richtig. Ich starre Netlify an, sowohl wenn ich es baue als auch wenn ich es einsetze, also bin ich damit ziemlich vertraut.

Drew: Und dann arbeitest du am Wochenende an einem Nebenprojekt und findest dich wieder bei Netlify wieder.

Leslie: Ja. Das ist eigentlich sehr wahr. Ja. Jawohl. ja, in der Tat.

Drew: Hast du Beispiele dafür, wie die Produktausrichtung überhaupt durch die Arbeit des Teams beeinflusst wurde?

Leslie: Ja. Wir haben also vor kurzem eine neue Art von Landing-Dashboard für die App eingeführt, die wir The Team Overview nennen. Wenn Sie sich also bei Netlify angemeldet haben, landeten Sie auf der Seite der Website, die im Grunde nur eine lange Liste Ihrer Websites war. Und wir wollten den Leuten ein bisschen mehr von einem Missionskontrollbereich geben, wo sie viele wichtige Informationen auf einen Blick sehen können, Zugang zu Dingen erhalten, die für sie am nützlichsten sein werden. Das war also ein neues Feature, das wir gebaut haben. In der ersten Iteration versuchen wir, es schnell herauszubringen, wir haben eine kleine Karte auf dieser Benutzeroberfläche, die auf Ihre neuesten Builds verweist. Es zeigt Ihnen alle Builds in Ihrem gesamten Team, die auf dieser Karte erscheinen sollten.

Leslie: Und anfangs hatten wir diese tatsächlich nicht mit dem Build verknüpft … dem Anzeigeprotokoll selbst. Es war also nur eine Liste, in der Sie es überprüfen konnten. Sie können auf die Build-Seite klicken, um eine ähnliche Ansicht zu erhalten. Aber ich habe tatsächlich über das Wochenende an etwas gearbeitet, einer persönlichen Seite, und ich hatte diese Teamübersicht aktiviert und ich war verärgert, weil mir klar wurde, dass ich mich bei Netlify angemeldet hatte und mir diesen Build ansehen wollte, der in meinem Projekt stattfand. und ich konnte nicht einfach darauf klicken und direkt darauf zugreifen. Ich musste auf die Build-Seite klicken und dann erneut klicken. Also ging ich am nächsten Tag bei der Arbeit hinein und fügte diese Änderung hinzu und verknüpfte diese Builds, weil es mich störte. Das war also ein Beispiel dafür, wie man einfach durch die Verwendung des Produkts erkannt hat, dass es eine sehr kleine Möglichkeit gibt, es zu verbessern. Und das haben wir genommen.

Leslie: Aber wir haben auch einige andere Beispiele. Wahrscheinlich etwas wirkungsvoller. Zum einen haben wir diese Formularerkennungsfunktion hinzugefügt. Also, ein bisschen Hintergrundwissen, wenn Sie nicht vertraut sind, Netlify Forms ist eine Funktion in Netlify, mit der Sie ein Frontend-Formular erstellen können. Und Netlify erledigt sozusagen die gesamte Backend-Arbeit zur Verwaltung von Einreichungen. Es ist so etwas wie Ihre Datenbank für Ihr Formular, das Sie auf Ihrem Frontend erstellt haben. Das bedeutet, dass Sie keinen serverseitigen Code oder eine ganze Menge zusätzliches JavaScript schreiben müssen, um Formularübermittlungen zu verwalten. Wirklich jede Site, die Sie für Netlify bereitgestellt haben, analysieren unsere Build-Bots während Ihres Builds den HTML-Code Ihrer Site zum Zeitpunkt der Bereitstellung, um im Grunde zu erkennen, ob Sie ein Netlify-Formular haben, das Netlify beachten und verwalten muss. Und diese Formularerkennung, die der Build-Bot sucht, ist standardmäßig aktiviert.

Leslie: Aber das bedeutet, wie Sie sich vorstellen können, dass das ein wenig Ihrer Bauzeit verschlingt, weil die Bots nach diesem zusätzlichen Schritt suchen müssen. Die Netlify-App selbst verwenden wir also nicht, wir haben derzeit keine Netlify-Formulare in der App. Dies ist also ein Schritt, der unsere Build-Zeit im Grunde ein wenig verlängert, aber es muss nicht unbedingt passieren. Netlify hat also tatsächlich eine neue Funktion entwickelt, die es jedem Benutzer ermöglicht, diese Formularerkennung zu deaktivieren. Das bedeutet, dass Sie diese Einstellung in Ihren Site-Einstellungen deaktivieren können. Die Build-Bots erkennen, dass sie nach nichts suchen müssen, sodass Sie ein wenig zusätzliche Verarbeitungszeit in den Builds sparen.

Drew: Ich denke, das ist großartig in Bezug auf die Produktivität, weil die Dinge einfach ein bisschen schneller fertig sind.

Leslies: Genau.

Drew: Als gebührenpflichtiger Dienst können Sie aber auch mehr aus den Zulagen herausholen, die Sie haben.

Leslie: Ja. Exakt. Das haben wir auch von einigen unserer Benutzer und Kunden gehört, und es ist uns auch irgendwie aufgefallen. Es war: „Nun, wir brauchen diesen zusätzlichen Schritt in unserem eigenen Produkt nicht. Gibt es also eine Möglichkeit, etwas, das wir allen unseren Benutzern geben könnten, um das Leben aller ein wenig einfacher zu machen, das Bauen für alle ein bisschen schneller zu machen, wenn sie diese Funktion nicht verwenden?“

Drew: Gibt es eine Gefahr… Ich meine, du sagst, dass du nicht dein Benutzer bist, aber bei Netlify bist du oft dein Benutzer. Besteht die Gefahr, dass Sie bei der Intensität, mit der Sie das Produkt verwenden, die Art von Benutzern übersehen, die es nur sehr leicht verwenden, und alles könnte zu komplex und zu fortgeschritten werden, und es würde nur sehr schwer zu bekommen sein begann mit?

Leslie: Das ist eine großartige Frage. Wir haben auch unsere Benutzerforschungsfunktion bei Netlify und unsere Data-Science-Funktion wirklich ausgebaut, und ich denke, insgesamt vertrauen wir ihnen viel mehr als meinen anekdotischen Erfahrungen mit der Nutzung und Bereitstellung der App. Aber ich denke, all diese Daten kommen zusammen, damit wir uns ein besseres Bild davon machen können, wer Netlify verwendet, mit welcher Art von Benutzer sprechen wir? Es gibt Menschen mit unterschiedlichen Bedürfnissen. Wir haben Leute in unseren Starterteams, die Blogs und persönliche Websites verwalten, und wir haben auch riesige Unternehmen, die große Marketingkampagnen und große Web-Apps starten, nicht so unähnlich zu Netlify selbst. Es ist also aufregend zu sehen, wie die Benutzerbasis wächst und über all diese Anwendungsfälle nachzudenken und herauszufinden, wie wir all diese Benutzer bedienen können. Und nutzen Sie sicherlich mehr unserer Recherchefunktionen, um sich darauf zu stützen, wer diese Benutzer sind, und nicht nur auf unsere interne Erfahrung.

Drew: Erzählen Sie mir, Leslie, von dem Screenshot-Dienst, den Netlify eingerichtet hat? Denn das fand ich sehr interessant.

Lesly: Ja. In der Benutzeroberfläche haben wir … wenn Sie eine Site auf Netlify bereitstellen, haben wir in der Benutzeroberfläche einen kleinen Screenshot, der Ihnen normalerweise zeigt, wie die Startseite der Site Ihrer Meinung nach aussieht. Es ist eigentlich lustig, dass wir das angesprochen haben, weil ich Chris Coyier vor nicht allzu langer Zeit seine Episode auf Serverless angehört habe und er darüber gesprochen hat, wie sie auch Screenshots in CodePen machen, was eigentlich nicht so unähnlich ist, wie Netlify es macht. Aber im Grunde führen wir Puppeteer aus, um diesen Screenshot der Benutzerseite aufzunehmen, und die Art und Weise, wie alles ausgeführt wird, besteht darin, dass es mit einer Netlify-Funktion eingerichtet wird. Das ist also wieder ein Beispiel dafür, wie wir unser eigenes Produkt dogfooden. Also verwenden wir im Wesentlichen diesen Endpunkt, der eine Netlify-Funktion in unserer eigenen App ist, um die URL dieses Bildes des Screenshots zurückzugeben, die wir dann in der App bereitstellen können.

Drew: Netlify-Funktionen sind also Netlifys Implementierung einer serverlosen Funktion, nicht wahr? Dabei legen Sie im Grunde einfach eine JavaScript-Datei in einem bestimmten Ordner als Teil Ihrer Quelle ab, und diese wird dann zur Ausführung als Cloud-Funktion verfügbar.

Leslie: Ja, genau.

Drew: Superschlau, nicht wahr?

Lesly: Ja. Es ist brilliant. This is one of those areas where it really pushes me as a frontend engineer to really be more of this JavaScript or Serverless engineer, and think a little bit more about how you're basically writing like an internal API end point for yourself when you create one of these Serverless functions. So, it's exciting because there's so much you can do, but that can make it a little intimidating also because there's so much you can do.

Drew: I sort of find it funny how it's like… that's seemingly a core piece of functionality for Netlify, displaying images alongside your site of what it looks like, yet, it's just implemented with another Netlify feature. And you wonder how far you go before it all disappears in on itself in a big cloud of smoke.

Leslie: Yeah. Ja.

Drew: This sounds like a really nice way to be working, and a very modern way to we're working, but it can't be without its challenges, can it?

Leslie: Absolutely not. I think I've spoken a little bit about what it means sort of as a frontend engineer pushing into sort of some new areas just for me to be thinking about in terms of Serverless and how can we leverage this in the product? I think for me, mastering that sort of back of the frontend side has been an exciting challenge, but certainly there's a lot to learn there. An example of that in our app right now, is that we use Cypress for end-to-end testing of some of the critical flows in our app, and right now we have that set up so that the Cypress end-to-end tests are running on our Deploy Previews in Pull Requests using a GitHub action. So, we use the GitHub action to run those Cyprus tests against the Deploy Previews of the app.

Leslie: Which is really cool, but there's probably a better way to do this than actually using a GitHub action. I actually think that we could use a Netlify Serverless function because those can be triggered on certain events, like a deploy succeeded event. So, there's an opportunity there for us to actually leverage again, Netlify, a little bit more, instead of relying on some of these other tools that maybe we're more familiar with or more comfortable using. So, in terms of challenges, I think it's opening our minds to what this sort of new model of development allows us to do and trying to leverage it.

Drew: Yes, there's so many different ways on there to… with the tooling that's available, to be able to attack a particular problem. At Smashing, we probably shouldn't say there's more than one way to skin a cat.

Leslie: Yikes.

Drew: What's interesting about the workflow as well, is that it's really intensively Git based, which I think suits… it's really developer friendly, isn't it? As a frontend engineer, something that's Git based kind of just feels like home. So, is that all great or are there any problems that come in with that?

Leslie: I think as a developer Git is wonderful. I think in general it solves big, big problems and I'm very happy to have it. But, because we rely on it so heavily and as our internal team has grown as well, you end up having the same problems that Git has when you're talking about Netlify in this workflow, right? So, you end up with a bug on your main branch, yes, it's really easy to roll back the app itself, we talked through what that looks like, and then go in the code and fix it. But what if someone else on your team is working from a broken version of that main branch? Everyone's going to have to rebase, everyone's going to have to communicate, or at least be aware of what happened. And so, it's not so much a Jamstack problem or a Netlify problem, but more of just the age old, how do you coordinate on a team of human beings and how do you use the technology to do that properly?

Drew: And of course, as you add more tools and infrastructure in around what you're doing, then you've got the problem of everything taking a long time to run. I mean, you mentioned Cypress is one thing. I know Cypress is a real headache with the amount of time those end-to-end tests can take to run. Is there other challenges around that growing build time?

Leslie: Yeah, I think that's one of the other things that Jamstack… You're introducing this build time, which for developers is not great. I always try and think about it as what I sort of eat up in that build time, my users are saving in the performance of what they're getting. So, I always try to keep that in mind when I'm frustrated about how long something is taking to build, but certainly I think that's an area of opportunity and a challenge, is figuring out how to keep those build times fast, how to make sure that we can deploy as quickly as possible. Some of it is this sort of tension between wanting to run all your tests, wanting to make sure that you don't deploy a build if a test fails, but at the same time, then you've got to run all those tests.

Leslie: So, it's this constant sort of back and forth between wanting to keep the build times fast, while also making sure that you feel like you're doing your due diligence before you actually deploy something. And we're playing around with some ideas here as well about potentially moving our Cypress tests to be running against production and having some alerting setup that would let us know after the fact, if something had failed. Which is sort of an interesting model, too. So yeah, stay tuned.

Drew: I certainly know that, yes, the dangers of growing build times, just from a developer point of view, from productivity point of view, that if something takes too long to run, you context switch, you start working on something else, and then it just… you lose all the momentum, and maybe you forget to go back and find out whether the build succeeded because you're then so far into the next task.

Leslie: Yeah, definitely.

Drew: So, I guess this isn't the ultimate workflow as it stands at the moment. There must be further we can take it. What sort of opportunities might lie ahead for this way of working?

Leslie: Yeah. So, I think for me, and Netlify in particular, is sort of the thought of collaboration for larger teams. I mean, I know a lot of developers are sort of… have used Netlify for side projects and other things that they're working on, on their own, but thinking about how it can be leveraged on larger teams, like mine. As we get larger and we're growing, more of us are in the app, more of us are using Netlify to deploy our own services, and so everything from even more robust audit logs so that you can go and see who changed this site setting, or who was the last person to deploy something. I think having the ability to organize your sites within your Netlify dashboard, even knowing… assigning someone to a build is sort of an interesting idea to me. Could that be helpful if I knew that my teammate had worked on this build, but then I realized they had to roll it back? And maybe I'm just aware of who's managing that process could be a really useful thing within Netlify itself.

Leslie: And one thing that I've seen sort of thrown around a little bit is perhaps the ability to link to a specific log line in build log. So, for debugging, if you have your build log of your Deploy Preview, and there's an error that got thrown, either from Netlify or from your own code, it'd be nice to be able to link directly to that log line. So, that's sort of a fun, small improvement that I've been thinking about a bit. And that's not even to say we have some new features at Netlify as well, that are pretty exciting. Edge handlers and background functions. I'm still trying to wrap my head around what they all do and exactly how they work, but I know that edge handlers are going to give us the opportunity to do some things with localized content, which could be… have some interesting implications for features we could build in the Netlify app as well.

Drew: Yeah, it's really exciting. I think there are all sorts of people within the Jamstack community who are pushing this the whole thing forward. But I think Netlify, as a service, is one that is really behind it and doing exciting things. And, as I say, I didn't want this to be a big ad for Netlify, but I think you and I both really love the service, so it is exciting to talk about isn't it? If listeners want to get more engaged with learning how to build Jamstack sites or want to get more into this ecosystem, is there a good place to go to learn this stuff?

Leslie: I feel like it's exploding right now. I would certainly point you to the Netlify blog. We try and post some tips and tricks there and announce new features as well. I would give a shout out too, to Learn With Jason. My coworker, Jason Lengstorf does sort of a live stream show, and he does cover… he covers a range of topics, but does some Jamstack specific ones as well. And it's a fun hour of live coding and picking that out. Twitter, I think, is huge, too. So check out Jamstack hashtag.

Drew: Good advice. So, we've been learning all about how Netlify builds Netlify on Netlify. What have you been learning about, Leslie?

Leslie: Oh, that's always a big question. I mentioned Cypress before, we've been working through some of our processes around exactly how we want to run our end-to-end tests, and so I would say that, in general, I've been thinking a lot about that workflow. So, less about the technology itself, but more about what workflows exist for end-to-end testing on the frontend, and what makes sense sort of in this Jamstack model. So, that's been a fun sort of side tangent. And then, on the CSS side of things, we talked a bit about CSS architecture, and I'm starting to get my hands dirty with Tailwind, which has been a fun and exciting and lots to learn and lots of class names to memorize and… Yeah.

Drew: That's exciting stuff. If you, dear listener, would like to hear more from Leslie, you can find her on Twitter where she's @lesliecdubs, and her personal site is leslie.dev. Thanks for joining us today, Leslie, did you have any parting words?

Leslie: Have a great day?