Smashing Podcast Episode 29 z Leslie Cohn-Wein: Jak Netlify Dogfood The Jamstack?

W tym odcinku pytamy, jak wygląda testowanie Jamstack w Netlify. Czy możesz wdrożyć całą aplikację w sieci CDN? Drew McLellan rozmawia z inżynierem personelu Netlify, Leslie Cohn-Wein, aby się tego dowiedzieć.

Pokaż notatki

• Strona osobista Leslie
• Leslie na Twitterze
• Netlifikuj

Cotygodniowa aktualizacja

• Zanurz się w React i Three.js przy użyciu reakcji retrieve-three-fiber
  napisany przez Fortune Ikechi
• Najlepsze praktyki projektowania interfejsu użytkownika w handlu elektronicznym
  napisane przez Suzanne Scacca
• Uwierzytelnianie aplikacji React za pomocą Auth0
  napisany przez Nefe Emadamerho-Atori
• Od ekspertów: globalny rozwój dostępności cyfrowej podczas COVID-19
  napisane przez Robina Christophersona
• Co nowego w Vue 3?
  napisany przez Timiego Omoyeni

Transkrypcja

Drew McLellan: Jest wielokrotnie nagradzaną specjalistką od frontendu, pochodzącą z Austin, ale teraz mieszka w Dallas w Teksasie, przez krótki czas w Nowym Jorku. W tym czasie pracując dla agencji budowała strony dla takich klientów jak Nintendo, WorldPride czy Jerry Seinfeld. Obecnie jest inżynierem frontendu personelu w Netlify, gdzie między innymi pracuje nad tworzeniem aplikacji używanych przez klientów do zarządzania swoimi usługami i wdrożeniami. Tak więc wiemy, że jest znakomitą inżynierką frontendu, ale czy wiesz, że mieszkając w Nowym Jorku, trzy lata z rzędu pełniła funkcję asystentki sędziego ds. gotowania chili. I to jest rzeczywiście prawda. Moi drodzy przyjaciele, witajcie Leslie Cohn-Wein. Cześć Leslie. Jak się masz?

Leslie Cohn-Wein: Rozwalam.

Drew: Chciałem dzisiaj z tobą porozmawiać o tym, jak Netlify w pewnym sensie zjada własną karmę dla psów, używając tego uroczego wyrażenia, jeśli chodzi o budowanie na Jamstack. Powinienem umieścić to trochę w kontekście, mówiąc, że jeszcze kilka miesięcy temu pracowaliśmy razem w tym samym zespole w Netlify. A kiedy tam dotarłem, proces tworzenia był dla mnie naprawdę obcy, nawet po 20 latach jako programista. Pomyślałem, że to po prostu naprawdę fascynujące i warte nieco odkrycia, z szerszą publicznością. Powinienem chyba zaznaczyć, że mówimy o tym, ponieważ jest to naprawdę interesujące studium przypadku i nie jest to sponsorowana duża reklama Netlify. Każdy powinien sprawdzić Vercel. Ale myślę, że jest wiele cennych rzeczy, których można się nauczyć z omawiania tego, szczególnie z punktu widzenia Jamstack. Ponieważ Netlify jest naprawdę dużym zwolennikiem podejścia Jamstack, a usługa jest w pewnym sensie oferowana klientowi i opiera się na idei budowania projektów Jamstack. Ale usługa jest również budowana na podstawie tych zasad. Prawda?

Leslie: Tak, tak. Wiele osób myśli o architekturze Jamstack jako o witrynach statycznych, ale my naprawdę sprawdzamy, co to znaczy budować aplikację Jamstack z interfejsem Netlify. Ponieważ jest to aplikacja React, która jest pełną aplikacją Jamstack, którą wdrażamy na Netlify, więc… Tak, naprawdę ją wypróbowujemy i przesuwamy granice tego, co jest możliwe.

Drew: Myślę, że czasami pojawia się pomysł, że Jamstack jest świetny tylko dla statycznych stron, jak mówisz, a aspekt API pojawia się, jeśli chcesz wysłać formularz na adres e-mail i możesz po prostu zrobić coś prostego w ten sposób, ale może w ten sposób zbudować całą aplikację internetową. Ale robisz to, prawda?

Leslie: Tak, absolutnie. Nasza aplikacja, mówiąca konkretnie o tym, co widzisz po zalogowaniu się na app.netlify.com, jest oparta na… mamy wewnętrzne API REST, ale frontend, jak powiedziałem, to czysty Jamstack. Mamy więc własny krok kompilacji, obserwujemy tworzenie aplikacji w aplikacji i wdrażamy ją w naszym własnym systemie.

Drew: Tak więc, gdy zaangażowany jest proces backendu i zawsze będzie jakiś poziom procesów backendowych, wiesz, utrwalanie danych lub, w przypadku Netlify, rozpoczynanie od wdrożenia lub co tam, ten backend po prostu powstaje jako seria interfejsów API, które mogą być następnie wykorzystywane przez frontend?

Leslie: Tak, więc istnieje kilka różnych modeli tego, jak to działa. W większości przypadków w naszej aplikacji korzystamy z pobierania po stronie klienta za pomocą React, prawda? Tak więc obsługujemy rodzaj statycznej powłoki aplikacji, a następnie pobieramy informacje o użytkowniku z naszego wewnętrznego interfejsu API REST w momencie żądania. Jamstack jest interesujący, ponieważ jest kilka rzeczy, które możesz wstępnie zbudować, a my staramy się na nich polegać, kiedy tylko możemy. A kiedy mówimy o niektórych bardziej dynamicznych danych, użyjemy pobierania po stronie klienta, aby upewnić się, że pobieramy najświeższe dane.

Drew: Myślę, że zaskoczyło mnie, kiedy zacząłem pracować nad aplikacją, jak wiele udało się osiągnąć w interfejsie użytkownika, szczególnie jeśli chodzi o interakcję z zewnętrznymi interfejsami API i innymi rzeczami. Wiem, że kiedy Netlify wchodzi w interakcję z dostawcą Git, przechodzi do GitHub i otrzymuje listę repozytoriów, to wszystko dzieje się między twoją przeglądarką a GitHub. Poza może… przechodzeniem przez funkcję bezserwerową, która wprowadza pewne tajemnice do żądania lub coś takiego, większość z tego dzieje się po prostu w sposób przypominający Jamstack. Nie przechodzi przez podstawową infrastrukturę zaplecza Netlify. Więc to jest całkiem fascynujące. To naprawdę idzie o wiele dalej niż tylko statyczna witryna z kilkoma wywołaniami API do robienia drobiazgów. To jest ta prawdziwa podstawowa funkcjonalność, prawda, która jest wdrażana w przeglądarce?

Leslie: Absolutnie. Myślę, że to naprawdę promuje koncepcję tego, czym jest inżynier programisty frontend, prawda? I to jest coś, co popycha mnie jako inżyniera frontendu do bycia lepszym i do myślenia o tego rodzaju… warstwie API, która nie jest czymś, do czego tradycyjnie byłem tak blisko. Pracuję więcej w interfejsie użytkownika, kolorach i systemach projektowania, więc naprawdę… Właściwie odkryłem, że praca nad aplikacją Jamstack na dużą skalę pchnęła mnie do bycia lepszym programistą.

Drew: Bycie programistą frontendu nie oznacza znajomości CSS od początku do końca, chociaż to jest część tego. Nie jest to znajomość HTML od początku do końca, ale to część tego. To także zabłąkanie się w to terytorium, które tradycyjnie było domeną inżyniera backendu, co jest dość interesujące. Czy Netlify używa nowego renderowania po stronie serwera do-

Leslie: Nie jestem tego świadomy.

Drew: Więc wszystko jest dosłownie zrobione, jak mówisz, obsługujesz powłokę, a następnie jest ona wypełniana żądaniami z powrotem do różnych punktów końcowych API, aby w pewnym sensie wypełnić to wszystko.

Leslie: Dokładnie.

Drew: A mówisz, że to aplikacja React?

Leslie: Tak. TAk. Reagować. Używamy React Redux w tej chwili, a teraz jesteśmy PostCSS, ale eksperymentujemy również z naszą architekturą CSS.

Drew: Czyż nie wszyscy? Czyli budujesz aplikację w React, a następnie wdrażasz ją na Netlify?

Leslie: Tak. Może moją ulubioną częścią tego całego procesu jest magia Deploy Previews, którą otrzymujemy za pośrednictwem Netlify. Tak więc dzieje się tak, że… pracujesz w GitHub, podnosisz swój PR. Otwierasz więc swój PR w GitHub, a to automatycznie tworzy kompilację twojego podglądu wdrożenia aplikacji. Tak więc używamy podglądów wdrażania samej aplikacji do testowania, aby upewnić się, że wszystko działa tak, jak powinno. Przeprowadzamy nasze testy. Tego używamy do ręcznej weryfikacji podczas przeglądu kodu. Tak więc mamy całe to ciągłe wdrażanie skonfigurowane bezpośrednio z GitHub.

Leslie: A jedną z innych fajnych rzeczy, które stworzyliśmy, jest to, że mamy kilka różnych witryn Netlify, które pobierają z tego samego repozytorium, w którym znajduje się nasza aplikacja. Mamy więc zarówno naszą aplikację, jak i instancję Storybook, która ma coś w rodzaju naszych komponentów interfejsu użytkownika dla aplikacji. Tak więc mamy zarówno samą naszą aplikację, mamy komponenty interfejsu użytkownika Storybook, jak i zasadniczo witrynę Netlify, która pokazuje nasz interfejs użytkownika Storybook. Mamy też trzecią witrynę, która uruchamia analizator pakietów internetowych. Jest to więc wizualny interfejs użytkownika, który udostępnia mapę drzewa, wizualizację wszystkich pakietów aplikacji, a my możemy określić ich rozmiar, a to tylko przypomnienie, abyśmy dokładnie to sprawdzili. Ponieważ każde wdrożenie aplikacji wygasa, możemy sprawdzić i upewnić się, że nie robimy nic dziwnego z naszym rozmiarem pakietu. Tak więc wszystkie trzy z tych witryn są generowane w jednym żądaniu ściągania aplikacji. Otrzymasz więc linki do podglądu, zasadniczo do Twoich podglądów wdrażania, zarówno aplikacji Storybook, jak i do tego profilu aplikacji, abyśmy mogli je sprawdzić.

Drew: A w przypadku Deploy Previews, to w zasadzie staje się twoim środowiskiem inscenizacyjnym, prawda?

Leslie: Dokładnie. Tak naprawdę nie prowadzimy tradycyjnego środowiska testowego, ponieważ naprawdę wierzymy, że nasze podglądy wdrażania będą w zasadzie tym, co zostanie uruchomione, gdy naciśniemy przycisk scalania i rozpoczniemy oficjalną kompilację naszej głównej gałęzi w naszej głównej aplikacji. Dlatego uwielbiam to, że możemy polegać na Deploy Previews jako środowisku postojowym. Naprawdę wierzymy, że będzie pasował do produkcji. Budujemy go ze wszystkimi zmiennymi produkcyjnymi, wszystkim, co… zmiennymi środowiskowymi, wszystko to jest budowane w podglądzie wdrażania. Więc to jest prawie sytuacja bez zmartwień. Dopóki działa podgląd Wdrożenia, wiesz, że aplikacja również będzie działać.

Drew: I myślę, że jako organizacja, jeśli Twój podgląd wdrażania nie pasuje do tego, co jest wprowadzane na żywo, to jest to problem z usługą, który Netlify chce rozwiązać. Tak więc z tego punktu widzenia wygląda to całkiem nieźle. Tak więc sprawdziłeś podgląd wdrażania, wszystko wygląda świetnie, PR się scala. Co się wtedy stanie?

Leslie: Tak więc, ponieważ Netlify obsługuje wszystkie nasze ciągłe wdrożenia, zasadniczo wszystko jest połączone tak, aby każde scalenie z naszą główną gałęzią automatycznie rozpoczęło oficjalne wdrożenie produkcyjne z aplikacją. Tak więc zazwyczaj, jeśli jesteś programistą, który połączył swój własny PR, wpadniesz do rzeczywistego… musisz się upewnić, dokładnie sprawdź swoje karty, ponieważ jeśli masz otwarty podgląd aplikacji i aplikacji, musisz się upewnić… zwykle chcesz śledzić w prawdziwej aplikacji. Więc musisz sprawdzić swoją kartę. Ale tak, w aplikacji zwykle wchodzisz, możesz oglądać dzienniki kompilacji dla tego połączenia, które właśnie rozpoczęłeś, więc wszystko odbywa się automatycznie. A potem, gdy tylko te dzienniki kompilacji zostaną zakończone, a witryna będzie działać, wystarczy odświeżyć okno przeglądarki, a zobaczysz, że to, co właśnie wdrożyłeś, powinno zostać zaktualizowane w aplikacji.

Drew: I powiedzmy, że wyłapiesz problem, gdy już zniknie, co wtedy robisz?

Leslie: To bardzo dobre pytanie. I być może jedną z moich ulubionych rzeczy w korzystaniu z Netlify, jeszcze zanim pracowałem w Netlify, było to dla mnie trochę magii, ponieważ Netlify w pewnym sensie wtopił się w to, co nazywamy, wycofaniem. Tak więc zasadniczo każde wdrożenie w Netlify… ponieważ używamy tej architektury Jamstack, każde wdrożenie jest atomowe. Oznacza to, że masz pełną historię każdego rodzaju wdrożeń, jakie kiedykolwiek wykonałeś w witrynie, i możesz natychmiast wrócić do dowolnego z nich. Tak więc, jeśli przypadkowo wdrożymy błąd lub coś zostanie zepsute, pierwszą rzeczą, którą zwykle robimy, jest zatrzymanie ciągłej integracji. Więc wejdziemy i to tylko jeden przycisk w interfejsie użytkownika Netlify, który mówisz „Zatrzymaj automatyczne publikowanie”, a to spowoduje zatrzymanie połączenia z GitHub. Tak więc, jeśli mój kolega z drużyny nagle również scali swój PR, nie wprowadzimy ponownie błędu, nic takiego się nie wydarzy.

Leslie: Więc zatrzymujemy wszystkie te automatyczne wdrożenia. A potem wszystko, co muszę zrobić, to wrócić do mojej listy wdrożeń i znaleźć ostatnie działające wdrożenie, nacisnąć jeszcze jeden przycisk z napisem „Opublikuj to” i gotowe. Więc to, co to robi, to zdejmuje tę presję, aby móc naprawdę wrócić, spojrzeć na kod, dowiedzieć się, co się właściwie wydarzyło. Czasami oznacza to cofnięcie Gita na głównej gałęzi i przywrócenie głównej gałęzi z powrotem tam, gdzie powinna być. A czasami jest to poprawka na gorąco lub uruchamiasz gałąź i zostajesz naprawiony i tak naprawdę nie musisz się nawet martwić o powrót w Git. A potem, gdy będziesz gotowy do powrotu, upewnisz się, że wszystko działa na Twoim podglądzie wdrażania aplikacji, i możesz po prostu zresetować wszystkie te dane w kopii zapasowej. Tak więc, gdy tylko zaczniesz te automatyczne wdrożenia, w zasadzie wracasz do pracy.

Drew: Więc zauważyłem tutaj problem.

Leslie: Och.

Drew: Używasz Netlify do wdrażania zmian w aplikacji Netlify. Co się stanie, jeśli wdrożony przez Ciebie błąd przestanie się cofać? Co wtedy robisz?

Leslie: Mam koszmary. Nie. Właściwie mamy kilka sposobów, aby sobie z tym poradzić. Jeśli więc usuniemy aplikację i nie będziemy mogli użyć interfejsu użytkownika do przejścia przez ten proces, nasze wersje zapoznawcze wdrożeń faktycznie działają w naszym produkcyjnym interfejsie API. Oznacza to, że nawet jeśli aplikacja nie działa, nadal mamy te atomowe wdrożenia. Tak więc, jeśli masz link z GitHub, być może ze starego lub niedawnego PR, i masz ten adres URL podglądu wdrożenia, możesz faktycznie uzyskać dostęp do podglądu wdrożenia aplikacji i wprowadzić dowolne zmiany, wróć i opublikuj starsze wdrożenie z podglądu wdrożenia. I nadal uderza w nasz produkcyjny interfejs API, więc nadal będzie to miało wpływ na aplikację, a następnie przywróci aplikację z powrotem. To jak rodzaj eksplodującego emoji mózgu, ale jest to jeden ze sposobów na zrobienie tego. Moglibyśmy również opublikować starsze wdrożenie z niektórych naszych systemów zaplecza. Moglibyśmy poprosić naszych inżynierów backendu, aby opublikowali to za nas. Lub zawsze możesz użyć Git, aby cofnąć i spróbować to podnieść, ale jest to trochę przerażające, ponieważ nie możesz patrzeć na to, co robisz.

Drew: Myślę, że po prostu potrzebujesz bardzo jasnego umysłu, aby poradzić sobie z tą sytuacją.

Leslie: Tak.

Drew: Ale jest to całkowicie możliwe do odzyskania, tak to brzmi.

Leslie: Tak. Cóż, a kiedy już opublikujesz swoje robocze wdrożenie, cała presja zniknie. To naprawdę najmilsza część. I znalazłem to również w agencjach. Możliwość cofnięcia zmian była naprawdę ratunkiem dla… Dzięki temu mniej martwisz się publikowaniem nowych zmian. Jeśli coś złamiesz, odwrócenie tego zajmuje sekundę, co bardzo dobrze pasuje do tego rodzaju ruchu i szybkiego wyrzucenia rzeczy.

Drew: Zdecydowanie. Myślę, że zazwyczaj ten rodzaj całego przepływu pracy działa najlepiej, gdy masz do czynienia z naprawdę małymi zmianami. Chodzi mi o to, że najlepiej byłoby stworzyć gałąź, wprowadzić małą zmianę, podnieść PR, a następnie jak najszybciej przywrócić to połączenie. Co oczywiście działa dobrze w przypadku poprawek i poprawek błędów oraz drobiazgów, ale nie działa tak dobrze w przypadku głównych funkcji, gdy ta funkcja może zająć tygodnie, a może nawet miesiące od momentu jej rozpoczęcia do gotowości do wdrożenia. Jak zarządzasz takim procesem?

Leslie: Tak, to świetne pytanie. Dlatego ostatnio zaczęliśmy nieco częściej używać flag funkcji. Zanim pójdę trochę więcej o tym, jak to robimy, opowiem o tym, co robiliśmy. Tak więc, zanim używaliśmy flag funkcji, myślę, że wszyscy są zaznajomieni z ideą długiej gałęzi funkcji. Wszyscy ich nienawidzimy, prawda? Ale pracowalibyśmy nad naszymi mniejszymi PR-ami. Po przejrzeniu kodu połączylibyśmy każdy z nich z osobna w tę dłużej działającą gałąź funkcji. Tak więc w zasadzie wszystkie nowe funkcje znajdują się w jednym miejscu, możesz mieć jedną wersję zapoznawczą, za pomocą której możesz przetestować tę nową funkcję. Czasami ten model wymaga skoordynowanych wdrożeń w innych zespołach. Tak więc, kiedy byliśmy gotowi powiedzieć: „OK, ta gałąź funkcji, jesteśmy gotowi, aby ją scalić i uruchomić”, czasami oznaczało to: „Ok, musisz się upewnić, że backend już wdrożył ich zmianę”, więc cokolwiek Praca API, którą wykonujemy w naszej funkcji, jest gotowa do pracy. Jeśli w naszej witrynie z dokumentami znajdują się dokumenty, które muszą zostać uruchomione w tym samym czasie, co funkcja, musisz poniekąd koordynować działania i naciskać przyciski w tym samym czasie.

Leslie: Ten model… zadziałał dla nas, ale masz rację, może nie był najpłynniejszy. To trochę zabawne, nasz współzałożyciel i dyrektor generalny Netlify, Matt Biilmann, faktycznie uruchomił naszą funkcję analityczną, wykorzystując ten proces na scenie podczas Jamstack Conf London w zeszłym roku. Dlatego użył naszej funkcji wdrożeń blokad, aby w zasadzie wziąć podgląd wdrożenia nowej funkcji analityki i opublikować ją na żywo na scenie. Więc to było całkiem fajne.

Leslie: Ale, jak powiedziałeś, to… masz trochę mniej pewności siebie. W tym żądaniu ściągnięcia wszystko jest nadal jakby ukryte. Staje się trochę nieporęczny. Ktoś musi zatwierdzić ostatnie żądanie ściągnięcia, które zwykle jest dość duże. To trochę przytłaczające. Tak więc obecnie używamy głównie flag funkcji. Korzystamy z usługi o nazwie LaunchDarkly, która pozwala nam w zasadzie otoczyć nasz nowy interfejs funkcji tymi flagami, dzięki czemu możemy stale scalać kod, nawet jeśli interfejs użytkownika nie jest czymś, co chcemy, aby klienci widzieli. Więc po prostu upewnij się, że w środowisku produkcyjnym, że flaga funkcji jest wyłączona, możemy wdrożyć kod, scalić go i nikt… zakładając, że jesteś zwykłym użytkownikiem, nie zobaczysz tego nowego interfejsu użytkownika.

Drew: Tak więc flaga funkcji jest po prostu jak przełącznik w kodzie, który mówi: „Jeśli ta funkcja jest włączona, użyj nowego kodu, w przeciwnym razie użyj starego kodu”.

Leslie: Dokładnie.

Drew: Czy to oznacza, że ​​masz trochę niechlujnej bazy kodu z tymi wszystkimi widelcami? Jak sobie z tym radzisz?

Leslie: Tak, myślę, że to… każdy, kto używa flag funkcji, prawdopodobnie jest przyzwyczajony do tego rodzaju bitwy o to, kiedy czyścisz flagi funkcji? Jak długo je tam zostawiasz? Wylądowaliśmy około dwóch tygodni po wydaniu ważnej funkcji, czy mamy przypomnienia. Na szczęście LaunchDarkly ostatnio skonfigurował funkcję, która powiadomi Slacka. Możesz więc podłączyć go do Slacka, a powie ci on tylko: „Hej, twoja flaga fabularna była… Byłeś na żywo w produkcji przez dwa tygodnie. Najwyższy czas, aby upewnić się, że wyczyściłeś swoją flagę w kodzie”.

Leslie: Więc staramy się i dość szybko to posprzątamy, ale w międzyczasie fajnie jest wiedzieć, że flaga wciąż tam jest. Nawet jeśli zwolniłeś tę funkcję, oznacza to, że ponownie, jednym kliknięciem, możesz wejść i wyłączyć tę flagę, jeśli jest błąd, jeśli coś się wyskakuje. Dlatego lubimy zostawiać je na chwilę, gdy funkcja naprawdę się piecze, podczas gdy ludzie się do niej przyzwyczajają, aby upewnić się, że nie ma żadnych poważnych problemów. Ale potem próbujemy wrócić do kodu i jest to trochę porządkowanie, więc nie jest to idealny proces, ale zwykle usunięcie flagi nie zajmuje dużo czasu, po prostu usuwasz kilka linijek kodu.

Drew: Wydaje mi się, że najprostszym podejściem do implementacji flagi funkcji może być po prostu… jak zmienna konfiguracyjna w Twojej aplikacji, która mówi „Ta funkcja jest włączona lub wyłączona”, ale wtedy potrzebujesz jakiegoś sposobu, aby się upewnić, że jest włączony dla właściwych ludzi i wyłączony dla właściwych ludzi. I wydaje mi się, że właśnie w tym miejscu pojawia się usługa taka jak LaunchDarkly, ponieważ zajmuje to… To znaczy, w zasadzie zajmuje to, co jest włączaniem i wyłączaniem zmiennej do ekstremalnego poziomu, prawda?

Leslie: Tak. TAk. To jest dokładnie to. Są więc sposoby, w jakie moglibyśmy, nawet bez LaunchDarkly, po prostu sami skonfigurować zmienną konfiguracyjną, którą w pewnym sensie zarządzamy po naszej stronie. Jedną z rzeczy, które uwielbiam w LaunchDarkly, jest to, że istnieją różne środowiska. Możemy więc zasadniczo włączyć flagę funkcji dla naszych podglądów wdrażania. Tak więc każdy, kto ogląda wewnętrznie na Netlify, podgląd wdrożenia aplikacji może mieć dostęp do nowej funkcji, może ją przetestować, ale z drugiej strony, gdy tylko zostanie uruchomiona w produkcji, ta flaga jest wyłączona. Tak więc jest bardzo mało… znowu, trochę musisz sprawdzić swoją kartę i upewnić się, że wiesz, w jakim segmencie się znajdujesz, ponieważ nie chcesz się zaskoczyć i pomyśleć, że uruchomiłeś coś, co tego nie zrobiłeś, musisz być tam trochę ostrożny. Ale ogólnie działa całkiem dobrze, a LaunchDarkly pozwala również na te selektywne wdrożenia. Możesz więc wdrożyć funkcję do pewnego procentu bazy kodu lub do określonego segmentu użytkowników, osób z określonym typem planu lub określonym typem użytkownika. Dzięki temu masz dużo większą kontrolę nad tym, komu w pewnym sensie uwalniasz.

Drew: Tak. To może być naprawdę potężne, jak sądzę, szczególnie w przypadku nowych funkcji lub funkcji, które mogą rozwiązać problem. Być może ulepszasz funkcję, aby była bardziej zrozumiała, możesz wypróbować ją z 10% użytkowników i sprawdzić, czy mają te same problemy i…

Leslie: Dokładnie. To także świetny sposób na uzyskanie opinii, tak.

Drew: Myślę, że używanie LaunchDarkly w ten sposób, zamiast rozwijania własnego rozwiązania, jest kolejnym aspektem podejścia do Jamstack, prawda? To po prostu użycie interfejsu API, który zapewnia tę funkcjonalność, bez martwienia się o to, jak sami to zaimplementujecie i jak to rozwinąć, a także jak to utrzymać i zachować, abyś mógł po prostu zlecić to na zewnątrz, powiedz: „Dobrze, jesteśmy zamierzam korzystać z tego interfejsu API, a wszystko inne jest już załatwione.”

Leslie: Tak. Tak, dokładnie.

Drew: Tak więc takie podejście pozwala na wprowadzenie małych fragmentów nowych funkcji do produkcji, ale są one po prostu ukryte za flagą. A kiedy wszystko jest gotowe, możesz po prostu odwrócić flagę i szybko ją przełączyć z powrotem, jeśli coś pójdzie nie tak.

Leslie: Tak, dokładnie. To sprawia, że ​​nasze premiery są trochę mniej ekscytujące. Kiedyś naciskałeś te duże przyciski i cały ten kod się scalał, a ty obserwujesz swoje logi budowy i to jest ten moment oczekiwania. A teraz wskakujesz na rozmowę Zoom, klikasz jeden przycisk i jest na żywo.

Drew: Tak. Myślę, że podczas ostatniego uruchomienia funkcji, pracowałem nad Netlify, zastosowaliśmy to podejście. To były tygodnie pracy całego zespołu ludzi i otrzymaliśmy telefon Zoom, aby skoordynować wydanie, i wszyscy potwierdzili, że ich części są gotowe. A potem odwróciłem flagę funkcji i włączyłem ją dla wszystkich użytkowników i to było to.

Leslie: Gotowe.

Drew: I skończyło się za kilka minut i było naprawdę nieprzyjemnie.

Leslie: Tak, to trochę smutne.

Drew: Nie było spoconych dłoni, nie było nic, co oczywiście jest dokładnie tym, czego chcesz, prawda? W ten sposób wiesz, że masz solidny proces, jeśli włączenie czegoś dla wszystkich nie jest wielkim problemem.

Leslie: Dokładnie. A jeśli musisz to cofnąć, znowu, to jest tak proste, to jedno kliknięcie. Uwalnia część tej presji, niepokoju.

Drew: Tak więc przypuszczam, że nie wszystkie zmiany będą tylko zmianami frontendu. Czasami nastąpią zmiany zaplecza i prawdopodobnie mają one również własne flagi funkcji w większości systemów zaplecza. Więc wspomniałeś również o dokumentach. Czy istnieje sposób na skoordynowanie tego wszystkiego razem? Czy wszyscy po prostu rzucają flagami w tym samym czasie? Albo jak to działa?

Leslie: Tak. Jest to więc obszar, nad którym obecnie aktywnie pracujemy w zespołach Netlify, pracujemy nad rozwiązaniem, które pozwoliłoby nam być może powiązać wszystko z jedną flagą w LaunchDarkly, z której korzystają wszystkie nasze systemy , z których korzystają wszystkie nasze bazy kodu. Tak więc w idealnym świecie moglibyśmy odwrócić flagę i powiedzieć: „OK, to jest przełączanie nowego punktu końcowego interfejsu API, który jest również używany w interfejsie użytkownika z nowym interfejsem użytkownika, który jest opakowany we flagę funkcji, jak również ta część witryny z dokumentami, która zawiera nowe informacje o tej nowej funkcji”. Odwrócenie tej jednej flagi wpływa na wszystkie te repozytoria. Jeszcze tam nie dotarliśmy. Pracujemy nad tym, ale jestem podekscytowany, aby zobaczyć, czy jesteśmy w stanie to wszystko skoordynować i działać.

Drew: Netlify, jako usługa jest w dużym stopniu dostosowana do budowy witryn w ten sposób. Czy praca, którą ty i twój zespół wykonujecie przy użyciu produktu, w ogóle wpłynęła na rozwój produktu?

Leslie: Powiedziałbym, że zdecydowanie tak. Wszyscy zawsze mówią, że nie jesteś swoim użytkownikiem, co moim zdaniem jest prawdą w większości przypadków, z wyjątkiem sytuacji, gdy jesteś swoim użytkownikiem. Co jest zabawne w Netlify, ponieważ myślę, że większość ludzi w zespole frontendowym to ludzie, którzy wcześniej używali Netlify jako produktu. I na pewno dlatego, że używamy Netlify do wdrażania Netlify, napotykamy te same wyzwania, które, jak sądzę, mają niektórzy nasi użytkownicy. Tak więc w pewnym sensie, jeśli napotkamy problem, postaramy się przekazać go reszcie firmy. Wspomniemy o tym podczas rozmowy inżynierskiej lub wezwiemy naszego CTO i powiemy: „Hej, to jest coś, z czym się zmagamy. Czy jest coś, co moglibyśmy wbudować w produkt, co ułatwiłoby to nam i wszystkim naszym użytkownikom, którzy wdrażają podobne rozwiązania do nas?” Jest to więc w pewnym sensie wyjątkowa pozycja, ale fajnie jest patrzeć, jak rozwija się mapa drogowa produktu.

Drew: Wydaje mi się, że prawdopodobnie niewiele osób korzysta z Netlify tak intensywnie, jak sam Netlify.

Leslie: Tak. Tak. Myślę, że to w porządku. Wpatruję się w Netlify zarówno kiedy go buduję, jak i wdrażam, więc jestem z nim całkiem zaznajomiony.

Drew: A potem w weekend pracujesz nad projektem pobocznym i znów znajdujesz się w Netlify.

Leslie: Tak. To rzeczywiście bardzo prawdziwe. Tak. TAk. w rzeczy samej.

Drew: Czy masz jakieś przykłady tego, w jaki sposób praca zespołu wpłynęła na kierunek produktu?

Leslie: Tak. Dlatego całkiem niedawno wprowadziliśmy nowy rodzaj pulpitu nawigacyjnego dla aplikacji, którą nazywamy Przeglądem zespołu. Tak więc, kiedy logowałeś się do Netlify, wylądowałeś na stronie witryny, która byłaby po prostu długą listą twoich witryn. Chcieliśmy dać ludziom trochę więcej obszaru kontroli misji, w którym mogą na pierwszy rzut oka zobaczyć wiele ważnych informacji, uzyskać dostęp do rzeczy, które będą dla nich najbardziej przydatne. To była nowa funkcja, którą zbudowaliśmy. W początkowej iteracji staramy się to szybko wydać, mamy małą kartę w tym interfejsie użytkownika, która zawiera linki do twoich najnowszych kompilacji. Pokazuje dowolną kompilację w całym zespole, powinna pojawić się na tej karcie.

Leslie: I na początku właściwie nie połączyliśmy ich z kompilacją… samym dziennikiem wyświetlania. Była to więc tylko lista, na której można było to sprawdzić. Możesz kliknąć stronę kompilacji, aby uzyskać podobny widok. Ale tak naprawdę pracowałem nad czymś przez weekend, osobistą witryną, i miałem włączony przegląd zespołu i byłem zirytowany, ponieważ zdałem sobie sprawę, że zalogowałem się do Netlify i chciałem sprawdzić ten build, który miał miejsce w moim projekcie, i nie mogłem po prostu kliknąć i przejść do tego. Musiałem kliknąć stronę kompilacji, a następnie kliknąć ponownie. Więc następnego dnia w pracy wszedłem i dodałem tę zmianę i połączyłem te kompilacje, ponieważ przeszkadzało mi to. Był to więc jeden przykład pewnego rodzaju uświadomienia sobie poprzez użycie produktu, że istnieje bardzo mała szansa na jego ulepszenie. I wzięliśmy to.

Leslie: Ale mamy też inne przykłady. Prawdopodobnie trochę bardziej wpływowy. Jednym z nich jest to, że dodaliśmy tę funkcję wykrywania formularzy. Więc trochę tła, jeśli nie jesteś zaznajomiony, formularze Netlify to funkcja w Netlify, która pozwala zbudować formularz frontendowy. A Netlify wykonuje całą pracę zaplecza związaną z zarządzaniem zgłoszeniami. To trochę jak twoja baza danych dla twojego formularza, który zbudowałeś na swoim interfejsie. Oznacza to, że nie musisz pisać żadnego kodu po stronie serwera ani mnóstwa dodatkowego kodu JavaScript, aby zarządzać przesyłaniem formularzy. Właściwie każda witryna, którą wdrożyłeś w Netlify, w trakcie tworzenia, nasze boty budujące analizują kod HTML Twojej witryny podczas wdrażania, aby w zasadzie wykryć, czy masz formularz Netlify, na który Netlify musi zwrócić uwagę i którym należy zarządzać. A to wykrywanie formularzy, którego szuka bot budujący, jest domyślnie włączone.

Leslie: Ale oznacza to, że, jak możesz sobie wyobrazić, zabiera to trochę czasu na budowę, ponieważ boty muszą iść i poszukać tego dodatkowego kroku. Tak więc sama aplikacja Netlify, w rzeczywistości, nie używamy, nie mamy obecnie żadnych formularzy Netlify w aplikacji. Tak więc jest to krok, który zasadniczo wydłuża nasz czas budowy, ale niekoniecznie musi się to dziać. Tak więc Netlify faktycznie zbudowało nową funkcję, która pozwala każdemu użytkownikowi wyłączyć wykrywanie formularzy. Oznacza to, że możesz wyłączyć to ustawienie w ustawieniach witryny, boty budujące zdają sobie sprawę, że nie ma niczego, czego muszą szukać, więc oszczędzasz trochę dodatkowego czasu przetwarzania w kompilacjach.

Drew: Myślę, że to świetnie, jeśli chodzi o produktywność, ponieważ sprawy po prostu kończą się trochę szybciej.

Leslie: Dokładnie.

Drew: Ale także, jako usługa odmierzana, pozwala ci uzyskać więcej z tego rodzaju zasiłków, które masz.

Leslie: Tak. Dokładnie tak. I to było coś, co również usłyszeliśmy od niektórych naszych użytkowników i klientów, i to też jakoś zauważyliśmy. Było to: „Cóż, nie potrzebujemy tego dodatkowego kroku w naszym własnym produkcie. Czy jest więc sposób, coś, co moglibyśmy dać wszystkim naszym użytkownikom, aby ułatwić wszystkim życie, sprawić, by wszyscy budowali trochę szybciej, jeśli nie korzystają z tej funkcji?

Drew: Czy istnieje niebezpieczeństwo… To znaczy, mówisz, że nie jesteś swoim użytkownikiem, ale z Netlify często jesteś swoim użytkownikiem. Czy istnieje niebezpieczeństwo, że przy intensywności, z jaką korzystasz z produktu, możesz przeoczyć użytkowników, którzy używają go bardzo lekko i wszystko może stać się zbyt złożone i zbyt zaawansowane, a uzyskanie zacząłem?

Leslie: To świetne pytanie. Naprawdę zbudowaliśmy również naszą funkcję badania użytkowników w Netlify i naszą funkcję analizy danych i myślę, że ogólnie ufamy im o wiele bardziej niż moje anegdotyczne doświadczenie z używaniem i wdrażaniem aplikacji. Ale myślę, że wszystkie te dane łączą się, aby umożliwić nam uzyskanie lepszego obrazu tego, kto korzysta z Netlify, z jakim typem użytkownika rozmawiamy? Są ludzie o różnych potrzebach. W naszych początkowych zespołach są ludzie, którzy zarządzają blogami i witrynami osobistymi, a także duże przedsiębiorstwa, które uruchamiają duże kampanie marketingowe i duże aplikacje internetowe, nie różniące się tak bardzo od samego Netlify. Dlatego ekscytujące jest obserwowanie, jak rośnie liczba użytkowników, i zastanawianie się nad wszystkimi tymi przypadkami użycia i zastanawianie się, jak możemy zaspokoić wszystkich tych użytkowników. I z pewnością wykorzystujemy więcej naszych funkcji badawczych, aby oprzeć się na zrozumieniu, kim są ci użytkownicy, a nie tylko na naszym wewnętrznym doświadczeniu.

Drew: Powiedz mi, Leslie, o usłudze zrzutów ekranu, którą Netlify ma na swoim miejscu? Ponieważ uznałem to za naprawdę interesujące.

Leslie: Tak. W interfejsie użytkownika… kiedy wdrażasz witrynę na Netlify, w interfejsie użytkownika mamy mały zrzut ekranu, który pokazuje typowo, jak wygląda strona główna witryny, którą uważałeś. Właściwie to zabawne, że o tym wspomnieliśmy, ponieważ niedawno słuchałem odcinka Chrisa Coyiera na Serverless i mówił o tym, jak robią zrzuty ekranu w CodePen, co w rzeczywistości nie różni się tak bardzo od tego, jak robi to Netlify. Ale w zasadzie uruchamiamy Puppeteer, aby przechwycić zrzut ekranu strony użytkownika, a sposób, w jaki to wszystko działa, polega na skonfigurowaniu funkcji Netlify. To znowu przykład nas, gdy jemy nasz własny produkt. Zasadniczo używamy tego punktu końcowego, który jest funkcją Netlify w naszej własnej aplikacji, aby zwrócić adres URL tego obrazu zrzutu ekranu, który następnie możemy wyświetlić w aplikacji.

Drew: Więc funkcje Netlify są implementacją Netlify funkcji bezserwerowej, prawda? Gdzie w zasadzie po prostu upuszczasz plik JavaScript do wyznaczonego folderu jako części źródła, a następnie staje się on dostępny do wykonania jako funkcja w chmurze.

Leslie: Tak, dokładnie.

Drew: Super sprytny, prawda?

Leslie: Tak. To znakomicie. 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. Tak.

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?