與 Leslie Cohn-Wein 合作的 Smashing Podcast 第 29 集：Netlify Dogfood The Jamstack 是如何實現的？

在這一集中，我們要問的是在 Netlify 對 Jamstack 進行測試是什麼感覺。 您可以將整個應用程序部署到 CDN 嗎？ Drew McLellan 與 Netlify 高級工程師 Leslie Cohn-Wein 交談以找出答案。

顯示註釋

• 萊斯利的個人網站
• 萊斯利在推特上
• 網絡化

每週更新

• 使用 react-three-fiber 深入 React 和 Three.js
  作者：財富池地
• 電子商務 UI 設計的最佳實踐
  作者：蘇珊娜·斯卡卡
• 使用 Auth0 對 React 應用程序進行身份驗證
  由 Nefe Emadamerho-Atori 撰寫
• 來自專家：COVID-19 期間的全球數字可訪問性發展
  由羅賓克里斯托弗森撰寫
• Vue 3 有什麼新功能？
  蒂米·奧莫耶尼 (Timi Omoyeni) 撰寫

成績單

Drew McLellan：她是一位屢獲殊榮的前端專家，最初來自奧斯汀，但現在住在德克薩斯州的達拉斯，並在紐約市工作過一段時間。 在代理機構工作期間，她為 Nintendo、WorldPride 和 Jerry Seinfeld 等客戶建立了網站。 她現在是 Netlify 的一名前端工程師，除其他外，她致力於構建客戶用於管理其服務和部署的應用程序。 所以，我們知道她是一位出色的前端工程師，但你知道嗎，當她住在紐約市時，她連續三年擔任辣椒烹飪助理裁判。 那是真的。 我的好朋友們，請歡迎萊斯利·科恩-韋恩。 嗨，萊斯利。 你好嗎？

Leslie Cohn-Wein：我太棒了。

德魯：我今天想和你談談 Netlify 是如何吃自己的狗糧的，當談到在 Jamstack 上構建時，使用這種迷人的表達方式。 我應該稍微說明一下，直到幾個月前，我們還在 Netlify 的同一個團隊中一起工作。 當我到達那裡時，開發過程對我來說真的很陌生，即使在做了 20 年的開發人員之後。 我認為這真的很吸引人，值得探索一下，有更廣泛的觀眾。 我可能應該指出，我們正在討論這個問題，因為它是一個真正有趣的案例研究，而且它不是 Netlify 的讚助大廣告。 每個人都應該看看 Vercel。 但我認為從討論中可以學到很多有價值的東西，特別是從 Jamstack 的角度來看。 因為 Netlify 是 Jamstack 方法的真正支持者，並且該服務是提供給客戶的，並且是圍繞構建 Jamstack 項目的想法構建的。 但是該服務本身也是使用這些原則構建的。 不是嗎？

萊斯利：是的，是的。 很多人都認為 Jamstack 架構是靜態站點，但我們真的在嘗試用 Netlify 前端構建 Jamstack 應用程序的意義。 因為它是一個 React 應用程序，是一個完整的 Jamstack 應用程序，我們在 Netlify 上部署了 Netlify，所以……是的，我們真的在嘗試它並推動可能的極限。

Drew：我認為有時有人認為 Jamstack 僅適用於靜態站點，正如你所說，如果你想將表單發送到電子郵件地址，那麼 API 方面就會出現，你可以做一些簡單的事情，但是你可以這樣構建一個完整的網絡應用程序。 但是，你這樣做不是嗎？

萊斯利：是的，絕對的。 我們的應用程序，特別是在您登錄 app.netlify.com 時所看到的內容，由……我們有一個內部 REST API 提供支持，但就像我說的，前端是純 Jamstack。 所以，我們有自己的構建步驟，我們觀察應用程序在應用程序中的構建，然後在我們自己的系統上進行部署。

Drew：所以，當涉及到後端進程時，總會有某種級別的後端進程，你知道，持久化數據，或者在 Netlify 的案例中，從部署開始，或者你有什麼，那個後端只是某種被構建為一系列 API，然後可以被前端使用？

Leslie：是的，所以有幾種不同的模型可以讓你完成這項工作。 在大多數情況下，在我們的應用程序中，我們使用 React 的客戶端獲取，對嗎？ 因此，我們為應用程序提供某種靜態外殼，然後在請求時從內部 REST API 獲取用戶信息。 Jamstack 很有趣，因為您可以預先構建一些東西，我們盡可能地嘗試並依賴它。 然後當我們談論一些更動態的數據時，我們將使用客戶端獲取來確保我們正在提取最新的數據。

Drew：當我開始開發應用程序時，我覺得它讓我感到驚訝，前端實現了多少，特別是在與外部 API 和事物交互方面。 我知道，當 Netlify 與您的 Git 提供程序交互時，它會轉到 GitHub 並獲取存儲庫列表，這一切都發生在您的瀏覽器和 GitHub 之間。 除了可能……通過一個無服務器功能，在請求上放置一些秘密或類似的輕量級功能，大部分只是以 Jamstack-y 的方式發生。 它沒有通過 Netlify 類型的核心後端基礎設施。 所以，這很吸引人。 這真的遠遠超出了一個靜態站點，只需調用幾個 API 來做一些小事。 這才是真正的核心功能，不是嗎，正在瀏覽器中實現？

萊斯利：當然。 我認為，它確實推動了前端開發工程師的概念，對吧？ 作為一名前端工程師，這促使我變得更好，並更多地考慮這些……API 層，這不是我傳統上所接近的東西。 我在 UI、顏色和設計系統方面工作得更多，所以真的……我發現大規模開發 Jamstack 應用程序，促使我成為一名更好的開發人員。

Drew：作為一名前端開發人員並不知道從頭到尾的 CSS，儘管這是其中的一部分。 它不知道從頭到尾的 HTML，但這是其中的一部分。 它也誤入了這個傳統上由後端工程師保留的領域，這很有趣。 Netlify 是否使用新的服務器端渲染 -

萊斯利：我不知道。

Drew：所以，這一切都只是字面上完成了，正如你所說，你提供一個 shell，然後它被填充到不同的 API 端點的請求，以填充它。

萊斯利：沒錯。

Drew：你說它是一個 React 應用程序？

萊斯利：是的。 是的。 做出反應。 我們現在使用 React Redux，現在我們是 PostCSS，但我們也在試驗我們的 CSS 架構。

德魯：我們不都是嗎？ 那麼，您在 React 中構建應用程序，然後將其部署在 Netlify 上？

萊斯利：是的。 也許整個過程中我最喜歡的部分是部署預覽的魔力，我們通過 Netlify 獲得了它。 所以，發生的事情是，你會……你在 GitHub 上工作，你推你的 PR。 因此，您在 GitHub 中打開您的 PR，這將自動創建應用程序的 Deploy Preview 的構建。 因此，我們實際上使用應用程序本身的 Deploy Previews 來進行測試，以確保一切正常。 我們運行我們的測試。 這就是我們在代碼審查期間用來手動驗證的內容。 所以，我們已經從 GitHub 上設置了所有的持續部署。

Leslie：然後我們設置的其他很酷的事情之一是，我們實際上有幾個不同的 Netlify 站點，它們從我們的應用程序所在的同一個存儲庫中提取。 所以，我們有我們的應用程序，我們有一個 Storybook 的實例，它有我們的應用程序的 UI 組件。 所以，我們有我們的應用程序本身，我們有 Storybook UI 組件，我們基本上有一個 Netlify 站點來顯示我們的 Storybook UI。 然後我們還有第三個站點運行 webpack 包分析器。 所以，它是一個可視化的 UI，它為您提供了一個樹形圖，所有應用程序包的可視化，我們可以衡量它們的大小，它只是提醒我們仔細檢查。 隨著應用程序的每次部署結束，我們可以檢查並確保我們在那裡的包大小沒有做任何奇怪的事情。 因此，所有這三個站點都是在應用程序的一個拉取請求中生成的。 因此，您將獲得應用程序 Storybook 和該應用程序配置文件的預覽鏈接，本質上是您的部署預覽，以供我們檢查。

Drew：通過 Deploy Previews，這基本上成為了您的暫存環境，是嗎？

萊斯利：沒錯。 我們並沒有真正運行傳統的暫存環境，因為我們真的相信，當我們點擊合併按鈕並在我們的主應用程序中啟動我們的主分支的正式構建時，我們的部署預覽基本上會上線。 所以，我喜歡我們可以依賴 Deploy Previews 作為暫存環境。 我們真的相信它將與生產相匹配。 我們正在使用所有生產變量構建它，一切……環境變量，所有這些東西都在部署預覽中構建。 所以，這幾乎就像一個無憂無慮的情況。 只要您的 Deploy Preview 正常工作，您就知道該應用程序也將正常工作。

Drew：我想，作為一個組織，如果您的 Deploy Preview 與發布的內容不匹配，那麼這就是 Netlify 想要解決的服務問題。 因此，從這個角度來看，它實際上效果很好。 因此，您已經查看了部署預覽，一切看起來都很棒，PR 被合併了。 那會發生什麼？

Leslie：所以，因為 Netlify 運行我們所有的持續部署，本質上我們已經將它們全部連接起來，以便任何合併到我們的主分支中都會自動啟動應用程序的正式生產部署。 因此，通常如果您是合併了您自己的 PR 的開發人員，您會彈出實際的……您必須確保仔細檢查您的選項卡，因為如果您打開了應用程序的部署預覽並且應用程序，你必須確保......你通常想在真實的應用程序中跟隨。 所以，你必須檢查你的標籤。 但是，是的，在應用程序中，您通常會進入，您可以查看剛剛啟動的合併的構建日誌，因此這一切都是自動的。 然後，一旦這些構建日誌完成，並且站點處於活動狀態，您所要做的就是刷新瀏覽器窗口，您會看到剛剛部署的任何內容都應該在應用程序中更新。

德魯：假設你發現問題一旦上線，你會怎麼做？

萊斯利：這是一個非常好的問題。 也許在我在 Netlify 工作之前就使用 Netlify 是我最喜歡的事情之一，這對我來說有點神奇，因為 Netlify 已經融入了我們所說的回滾。 所以，基本上每次部署都在 Netlify 上……因為我們使用的是這種 Jamstack 架構，所以每次部署都是原子的。 因此，這意味著您擁有您在站點上進行的各種部署的完整歷史記錄，並且您可以立即回滾到其中的任何一個。 所以，如果我們不小心部署了一個錯誤或某些東西被破壞了，我們通常做的第一件事就是我們實際上停止了持續集成。 因此，我們將進入，它只是 Netlify UI 中的一個按鈕，您說“停止自動發布”，然後它會停止與 GitHub 的連接。 所以，如果我的隊友突然也合併了他們的 PR，我們不會重新引入這個 bug，這樣的事情不會發生。

Leslie：所以，我們停止了所有這些自動部署。 然後我所要做的就是回到我的部署列表並找到最後一個有效的部署，再點擊一個按鈕，上面寫著“發布這個”，它就會上線。 所以，這樣做是為了減輕壓力，才能真正返回，查看代碼，弄清楚實際發生了什麼。 有時這意味著在您的主分支上執行 Git 還原並將主分支恢復到需要的位置。 有時它是一個熱修復，或者你在一個分支上得到修復，你甚至不需要擔心在 Git 中恢復。 然後，當您準備好返回時，請確保一切都在您的應用程序的部署預覽中正常運行，您可以將所有這些內容重新設置回來。 所以，一旦你開始這些自動部署，你基本上就恢復了業務。

Drew：所以，我在這裡發現了一個問題。

萊斯利：哦哦。

Drew：您正在使用 Netlify 將更改部署到 Netlify 應用程序。 如果您部署的錯誤阻止您回滾怎麼辦？ 那你怎麼辦呢？

萊斯利：我做噩夢。 不。實際上，我們有幾種方法可以解決這個問題。 因此，如果我們關閉應用程序並且我們不能使用 UI 來完成這個過程，我們的部署預覽實際上是針對我們的生產 API 運行的。 所以，這意味著，即使應用程序不工作，我們仍然有這些原子部署。 因此，如果您有來自 GitHub 的鏈接，可能來自舊的或最近的 PR，並且您有該部署預覽 URL，您實際上可以訪問應用程序的部署預覽並進行所需的任何更改，然後返回並發布較舊的部署從部署預覽。 而且它仍然在影響我們的生產 API，所以它仍然會影響應用程序，然後這將使應用程序恢復正常。 這就像在那裡爆炸的大腦表情符號，但這是一種方法。 我們還可以從我們的一些後端系統發布較舊的部署。 我們可以讓我們的後端工程師為我們發布它。 或者你總是可以使用 Git 來恢復並嘗試將其推高，但這有點嚇人，因為你無法看到你在做什麼。

德魯：我想你只需要一個非常清晰的頭腦來處理這種情況。

萊斯利：是的。

德魯：但它是完全可以恢復的，聽起來是這樣。

萊斯利：是的。 好吧，一旦你發布了你的工作部署，所有的壓力都消失了。 這真的是最好的部分。 我發現這也適用於代理機構。 能夠回滾真的是一個救命稻草……它也讓你不用擔心發布新的變化。 如果您破壞了某些東西，則需要一秒鐘才能將其回滾，這非常適合快速移動並將其取出的模型。

德魯：當然。 我認為通常這種整個工作流程在您處理非常小的更改時效果最好。 我的意思是，理想情況下，您希望創建一個分支，實施一個小改動，提出一個 PR，然後儘快將其合併回來。 這顯然適用於調整和錯誤修復以及一些小事情，但它不適用於主要功能工作，因為該功能可能需要數週甚至數月才能開始準備部署。 你如何管理這樣的過程？

萊斯利：是的，這是一個很好的問題。 因此，我們最近開始更多地使用功能標誌。 在我更多地談論我們如何做到這一點之前，我將談談我們過去所做的事情。 所以，在我們使用特性標誌之前，我想每個人都對長期運行特性分支的想法有點熟悉。 我們都討厭他們，對吧？ 但我們會致力於我們較小的 PR。 在代碼審查之後，我們會將其中的每一個單獨合併到這個運行時間更長的功能分支中。 因此，您基本上將所有新功能都放在一個地方，您可以擁有一個部署預覽版，您可以使用它來測試該新功能。 有時，這種模型需要跨其他團隊進行協調部署。 所以，當我們準備說，“好的，這個功能分支，我們準備好合併它並讓它上線”時，有時這意味著，“好的，你必須確保後端已經部署了他們的更改，”所以不管我們在功能中所做的 API 工作已準備就緒。 如果我們的文檔網站上的文檔需要與該功能同時上線，那麼您必須同時協調並點擊按鈕。

Leslie：這個模型……它對我們有用，但你說得對，它可能不是最流暢的。 這實際上有點有趣，我們在 Netlify 的聯合創始人兼首席執行官 Matt Biilmann 實際上在去年的 Jamstack Conf London 的舞台上使用這個過程推出了我們的分析功能。 因此，他使用我們的鎖定部署功能基本上採用了分析新功能的部署預覽並在舞台上實時發布。 所以，這很酷。

Leslie：但是，就像你說的，這是……你的信心少了一點。 一切仍然隱藏在這個拉取請求中。 它變得有點笨拙。 必須有人批准通常很大的最終拉取請求。 這有點壓倒性。 所以，現在我們主要使用功能標誌。 我們使用了一個名為 LaunchDarkly 的服務，它讓我們基本上可以用這些標誌來包裝我們的新功能 UI，這樣我們就可以不斷地合併代碼，即使 UI 不是我們希望客戶看到的東西。 因此，您只需確保在生產環境中您的功能標誌處於關閉狀態，我們就可以部署代碼、合併它，並且沒有人……假設您是普通用戶，您不會看到新的 UI。

Drew：所以，功能標誌基本上就像代碼中的一個開關，“如果啟用此功能，請使用此新代碼，否則使用此舊代碼。”

萊斯利：沒錯。

Drew：這是否意味著你會得到一個帶有所有這些分支的混亂代碼庫？ 你怎麼處理？

Leslie：是的，我認為那是……任何使用功能標誌的人可能已經習慣了這種你什麼時候清理功能標誌的戰鬥？ 你把它們放在那裡多久？ 我們已經在一個主要功能發布後大約兩週登陸了，我們有提醒。 幸運的是，LaunchDarkly 最近實際上設置了一個會通知 Slack 的功能。 所以，你可以將它與 Slack 連接起來，它只會告訴你，“嘿，你的功能標誌已經……你已經在生產中生活了兩週。 現在是時候確保清理代碼中的標誌了。”

Leslie：所以，我們確實嘗試並很快清理它，但在這期間，很高興知道旗幟仍然在那裡。 即使您已經發布了該功能，這意味著再次單擊，您可以進入並將該標誌切換回來，如果有彈出的內容，則存在錯誤。 因此，我們希望將它們保留一段時間，就在該功能真正成熟的時候，而人們正在習慣它，以確保沒有任何重大問題。 但是我們確實嘗試回到代碼中，這有點清理，所以這不是一個理想的過程，但通常刪除標誌不會花費很長時間，你只是刪除了幾行代碼。

Drew：所以，我想實現功能標誌的最簡單方法可能只是......就像你的應用程序中的一個配置變量，它說“這個功能是打開或關閉”，但是你需要一些方法來確保它為正確的人開啟，為正確的人關閉。 我想這就是像 LaunchDarkly 這樣的服務的用武之地，因為它需要...

萊斯利：是的。 是的。 就是這樣。 因此，即使沒有 LaunchDarkly，我們也有一些方法可以基本上自己設置一個配置變量，我們可以自行管理。 我喜歡 LaunchDarkly 的一件事是有不同的環境。 因此，我們可以做的基本上是為我們的部署預覽打開一個功能標誌。 因此，任何在 Netlify 內部查看的人，應用程序的部署預覽都可以訪問新功能，可以對其進行測試，但話又說回來，一旦它投入生產，該標誌就會關閉。 所以，很少……再一次，你必須檢查你的標籤，並確保你知道你所處的部分，因為你不想讓自己感到驚訝並認為你已經推出了一些你沒有，你必須在那裡小心一點。 但是，總的來說，它工作得很好，而且 LaunchDarkly 還允許您進行這些選擇性的推出。 因此，您可以將某個功能推廣到您的代碼庫的某個百分比或特定用戶群、具有特定類型計劃的人或特定類型的用戶。 因此，它使您可以更好地控制要向誰發布。

德魯：是的。 我猜這可能非常強大，尤其是您可能希望解決問題的新特性或特性。 也許您正在增強一項功能以使其更易於理解，您也許可以與 10% 的用戶一起嘗試，看看他們是否遇到同樣的問題，然後……

萊斯利：沒錯。 這也是獲得反饋的好方法，是的。

Drew：我猜想以這種方式使用 LaunchDarkly，而不是推出自己的解決方案，是 Jamstack 方法的另一個方面，不是嗎？ 它只是使用為您提供此功能的 API，而不必擔心您自己如何實現該功能以及如何開發以及如何維護和保留它，以便您可以外包它，說：“對，我們是將使用這個 API，其他一切都得到照顧。”

萊斯利：是的。 是的，正是。

Drew：所以，這種方法使您能夠在本質上將少量新功能投入生產，但它們只是隱藏在旗幟後面。 然後當一切準備就緒時，您只需翻轉標誌，如果出現問題，您可以快速將其重新切換回來。

萊斯利：是的，沒錯。 它使我們的發布變得不那麼令人興奮。 過去是你按下這些大按鈕，所有這些代碼都被合併，你正在查看你的構建日誌，這是期待的時刻。 現在，您可以撥打 Zoom 電話，單擊一個按鈕，它就開始了。

德魯：是的。 我認為上一個功能發布，我在 Netlify 上工作，我們使用了這種方法。 整個團隊已經花費了數週的時間，我們接到了一個 Zoom 電話來協調發布，每個人都確認他們的部分已經準備好了。 然後我翻轉功能標誌並為所有用戶打開它，就是這樣。

萊斯利：完成。

德魯：幾分鐘就結束了，真是虎頭蛇尾。

萊斯利：是的，有點悲傷。

德魯：沒有出汗的手掌，什麼也沒有，這當然正是你想要的，不是嗎？ 這就是你如何知道你有一個強大的過程，如果為每個人打開一些東西並不是什麼大不了的事。

萊斯利：沒錯。 如果您必須再次回滾，就這麼簡單，只需單擊一下即可。 它減輕了一些壓力，焦慮。

Drew：所以，大概，我的意思是，並不是所有的變化都只是前端的變化。 有時會有後端更改，並且可能在大多數後端系統中它們也有自己的功能標誌。 所以，你也提到了文檔。 有沒有辦法將所有這些協調在一起？ 每個人都只是同時翻轉他們的旗幟嗎？ 或者它是如何工作的？

萊斯利：是的。 因此，這是我們目前在 Netlify 跨團隊積極開展工作的一個領域，正在努力尋找一種解決方案，使我們能夠將所有內容與 LaunchDarkly 中的一個標誌聯繫起來，我們所有的系統都在使用，我們所有的代碼庫都在使用。 所以，在一個理想的世界裡，我們可以翻轉一個標誌，然後說，“好的，這是切換新的 API 端點，這個端點也在前端使用這個新的 UI 被包裝在一個特性標誌中，以及文檔網站的這一部分，其中包含有關此新功能的新信息。” 你翻轉其中的一個標誌會影響所有這些存儲庫。 我們還沒有完全做到。 我們正在努力解決這個問題，但我很高興看到我們是否能夠讓所有這些協調和工作。

Drew： Netlify 作為一種服務非常適合以這種方式構建網站。 您和您的團隊使用產品所做的工作是否真的影響了產品開發？

萊斯利：我會說它確實如此。 每個人都說你不是你的用戶，我認為大多數時候都是如此，除非有時你是你的用戶。 這在 Netlify 很有趣，因為我認為前端團隊中的大多數人尤其是以前使用過 Netlify 作為產品的人。 當然，因為我們使用 Netlify 來部署 Netlify，我們遇到了與我認為我們的一些用戶相同的挑戰。 因此，在某些方面，如果我們遇到問題，我們會嘗試將其提交給公司的其他成員。 我們會在工程電話中提到它，或者我們會請我們的 CTO 說，“嘿，這是我們正在努力解決的問題。 我們是否可以在產品中構建一些東西，讓我們和所有正在部署與我們類似的東西的用戶更容易做到這一點？” 所以，這是一個獨特的位置，但看到產品路線圖是如何開發的很有趣。

Drew：我想可能很少有人像 Netlify 本身那樣密集地使用 Netlify。

萊斯利：是的。 是的。 我認為這是對的。 我在構建和部署 Netlify 時都會盯著它，所以我對它非常熟悉。

Drew：然後在周末你從事一個業餘項目，你發現自己又回到了 Netlify。

萊斯利：是的。 這實際上是非常正確的。 是的。 是的。 確實是的。

Drew：你有沒有任何例子說明產品方向如何受到團隊所做工作的影響？

萊斯利：是的。 因此，我們最近為我們稱為團隊概述的應用程序推出了一種新的登陸儀表板。 因此，過去當您登錄 Netlify 時，您會登陸該網站的頁面，這基本上就是您網站的一長串列表。 我們想給人們更多的任務控制區域，在那裡他們可以一目了然地看到很多重要信息，訪問對他們最有用的東西。 因此，這是我們構建的一個新功能。 在最初的迭代中，我們試圖快速推出它，我們在那個 UI 上有一張小卡片，可以鏈接到您的最新版本。 它向您展示了整個團隊的任何構建，都應該出現在該卡中。

Leslie：起初，我們實際上並沒有將這些與構建相關聯……顯示日誌本身。 因此，這只是一個您可以查看的列表。 您可以單擊構建頁面以獲得類似的視圖。 但實際上我周末在做一些事情，一個個人網站，我打開了這個團隊概述，我很生氣，因為我意識到我登錄了 Netlify，我想去看看我的項目正在發生的這個構建，我不能只點擊它就可以直接使用它。 我不得不點擊進入構建頁面，然後再次點擊。 因此，第二天上班時，我進去添加了更改並鏈接了這些構建，因為這讓我很困擾。 因此，這是通過使用該產品才意識到，改進它的機會很小的一個例子。 我們接受了。

萊斯利：但我們也有一些其他的例子。 可能影響更大一些。 一個是我們添加了這個表單檢測功能。 因此，如果您不熟悉一點背景知識，Netlify 表單是 Netlify 中的一個功能，可讓您構建前端表單。 Netlify 負責管理提交的所有後端工作。 它有點像您在前端構建的表單數據庫。 這意味著您不必編寫任何服務器端代碼或大量額外的 JavaScript 來管理表單提交。 實際上，您部署到 Netlify 的任何站點，當您的構建正在進行時，我們的構建機器人都會在部署時解析您站點的 HTML，以基本上檢測您是否有 Netlify 需要注意和管理的 Netlify 表單。 默認情況下，構建機器人正在尋找的這種表單檢測是啟用的。

Leslie：但這意味著，正如您可以想像的那樣，這會佔用您的構建時間，因為機器人必須去尋找這額外的步驟。 所以，Netlify 應用程序本身，實際上，我們沒有使用，我們現在在應用程序上沒有任何 Netlify 表單。 所以，這一步基本上會增加我們的構建時間，但不一定需要發生。 因此，Netlify 實際上構建了一個新功能，允許任何用戶禁用該表單檢測。 這意味著您可以在站點設置中關閉該設置，構建機器人意識到他們不需要尋找任何東西，因此您可以在構建中節省一點額外的處理時間。

德魯：我想這在生產力方面很好，因為事情完成得更快一點。

萊斯利：沒錯。

德魯：而且，作為一種計量服務，您可以從現有的​​津貼中獲得更多收益。

萊斯利：是的。 確切地。 因此，我們也從一些用戶和客戶那裡聽到了這一點，我們也注意到了這一點。 它是，“好吧，我們自己的產品不需要這個額外的步驟。 那麼，有沒有一種方法，我們可以為所有用戶提供一些東西，讓每個人的生活更輕鬆一些，如果每個人不使用這個功能，他們的構建速度會更快一點嗎？”

Drew：有沒有危險……我的意思是，你說你不是你的用戶，但使用 Netlify，你通常是你的用戶。 是否存在危險，隨著您使用該產品的強度，您可能會忽略那些僅非常輕鬆地使用它的用戶，並且一切都可能變得過於復雜和過於先進，並且變得非常難以獲得開始於？

萊斯利：這是一個很好的問題。 我們還在 Netlify 建立了用戶研究功能和數據科學功能，我認為，總的來說，我們對他們的信任遠遠超過我使用和部署該應用程序的軼事經驗。 但我認為所有這些數據匯集在一起，可以讓我們更好地了解誰在使用 Netlify，我們在與哪種類型的用戶交談？ 有些人有不同類型的需求。 我們的初學者團隊中有負責管理博客和個人網站的人員，我們也有大型企業，他們正在發起大型營銷活動和大型網絡應用程序，與 Netlify 本身並無太大區別。 因此，看到用戶群增長並考慮所有這些用例並弄清楚我們如何迎合所有這些用戶是令人興奮的。 當然，使用我們更多的研究功能來了解這些用戶是誰，而不僅僅是我們的內部經驗。

Drew： Leslie，告訴我 Netlify 提供的截圖服務？ 因為我發現這真的很有趣。

萊斯利：是的。 在我們的 UI 中……當您在 Netlify 上部署一個站點時，在 UI 中，我們有一個小屏幕截圖，通常會向您展示您認為該站點的主頁是什麼樣的。 我們提出這個問題實際上很有趣，因為不久前我正在聽 Chris Coyier 他在 Serverless 上的一集，他也在談論他們如何在 CodePen 中進行截圖，這實際上與 Netlify 的做法並沒有太大的不同。 但基本上我們運行 Puppeteer 來捕獲用戶站點的屏幕截圖，它的運行方式是它設置了一個 Netlify 函數。 所以，這又是一個我們對自己的產品進行測試的例​​子。 所以，基本上我們使用這個端點，即我們自己的應用程序中的一個 Netlify 函數來返回該屏幕截圖圖像的 URL，然後我們可以在應用程序中提供它。

Drew：所以 Netlify 函數是 Netlify 對無服務器函數的實現，不是嗎？ 您基本上只需將 JavaScript 文件作為源代碼的一部分放入指定的文件夾中，然後就可以將其作為雲功能執行。

萊斯利：是的，沒錯。

德魯：超級聰明，不是嗎？

萊斯利：是的。 這個棒極了。 這是其中一個真正推動我作為前端工程師真正成為這種 JavaScript 或無服務器工程師的領域之一，並在創建時多思考一下你基本上是如何編寫的，就像你自己的內部 API 端點一樣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. 是的。

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?