Smashing Podcast 第 25 集與 Anthony Campolo：什麼是 RedwoodJS？

我們正在談論 RedwoodJS。 成為全棧 Jamstack 框架究竟意味著什麼？ 我與社區冠軍 Anthony Campolo 進行了交談以了解情況。

顯示註釋

• 紅木JS
• 安東尼在推特上
• Anthony 的系列文章 A First Look at RedwoodJS

每週更新

• “以編程方式運行 Lighthouse 的介紹”
  由凱蒂鮑曼撰寫
• “使用 GreenSock 為 React 組件製作動畫”
  由 Blessing Krofegha 撰寫
• “為關注而設計”
  由維克多·約科撰寫
• “Gatsby 網站中的高級 GraphQL 使用”
  由 Aleem Isiaka 撰寫
• “比較 Next.js 中的樣式方法”
  由 Adebiyi Adedotun 撰寫

成績單

Drew McLellan：他是 Lambda School 的學生，學習全棧 Web 開發，同時也是 RedwoodJS 的貢獻者。 作為社區擁護者，他最近寫了一篇名為 A First Look at RedwoodJS 的 12 部分文章系列，有助於解釋 Redwood 的起源和動機，以及該框架引入的許多不同概念。 所以，我們知道他是 RedwoodJS 的專家，但你知道他從未見過狗嗎？ 我的好朋友，請歡迎 Anthony Campolo。

德魯：嗨，安東尼。 你好嗎？

安東尼坎波羅：你好。 我太棒了，非常感謝你有我。

Drew：我今天想和你談談，從介紹中可能很明顯，關於 RedwoodJS。 對於那些以前沒有聽說過 RedwoodJS 的人，在高層次上，它是什麼？

Anthony：我認為有幾種方法可以根據人們來自哪裡來描述它，但規範的定義是它是 Jamstack 的全棧無服務器框架。 因此，它將全棧 Web 開發與無服務器 AWS Lambda 類型的東西和 Jamstack 相結合，這在當今是一件大事。

Drew：所以，它是一個完整的堆棧框架，試圖圍繞 Jamstack 開發生態系統整合許多想法？ 那正確嗎？

Anthony：是的，它正在推動 Jamstack 應用程序的界限，所以通過將其稱為全棧，Jamstack，它是關於我們如何超越前端，擁有相同類型的部署範式，即被推送、獲取您的整個代碼已部署。 我們如何獲得這一點，以及我們的後端，並將其全部連接起來？

Drew：現在，在我們深入研究它之前，我認為聽到它來自一個經驗豐富的團隊非常有趣，不是嗎？ Redwood背後的人，他們不是春雞。 並不是說他們老了，但他們在網絡開發方面已經很成熟了，不是嗎？

安東尼：他們經驗豐富。 是的，我實際上已經花了相當多的時間來寫框架的歷史和導致它的想法，湯姆普雷斯頓 - 沃納是創造者，所以他也被稱為 Jekyll 的創造者，它是一個非常有影響力的靜態網站生成器。 他還做過配置文件語言 TOML。 他最初是 GitHub 的 CEO。 所以，他在 Jekyll 和 GitHub 頁面上的工作以及我認為真正導致了我們現在所認為的 Jamstack 的事情。 很多人會說，“哦，Jamstack 是新的。 他們一直在這樣做。” 這就是我們一直在談論它是如何擴展這些舊想法、靜態站點生成、但使用 GraphQL 和無服務器以及這些關於如何使用膠水代碼和 API 使您的應用程序工作的想法的方式。

德魯：所以，這肯定是來自那些非常融入那個社區的人？ 我的意思是，GitHub 的 CEO，你真的沒有比這更融入那種開源社區了。 所以，Redwood 是一個完整的堆棧框架，我想這意味著您已經在前端和後端運行了 Redwood 代碼。 那正確嗎？

Anthony：是的，當我向人們展示 Redwood 項目時，我想向他們解釋的第一件事是，它是一個 monorepo。 因此，您將前端和後端放在同一個存儲庫中，然後每個存儲在自己的文件夾中。 您有一個 web 文件夾，它是您的前端，它與您從 Create React 應用程序中獲得的非常相似。 然後，您有 API 文件夾，它是您的後端，您的所有功能基本上都被推入一個大型 GraphQL 處理程序，該處理程序通過 Netlify 部署到 AWS Lambda。

Drew：好的，所以從前面開始，正如你提到的，它基於 React。 是 React 加上一堆 Redwood 代碼，還是只是簡單的 React？ 那裡的餘額是多少？

安東尼：有很多事情。 從你沒有引入很多狀態管理庫的意義上說，它絕對只是 React，實際上你甚至沒有引入路由器。 他們有自己編寫的路由器，並且使用了很多 GraphQL 的東西。 因此，當人們談論 React 和 GraphQL 以及朋友們時，這就是這裡發生的事情，它為您提供了許多默認集成來讓 React 與您的 GraphQL 對話。 因為我們現在有很多關於如何使用 React 的約定，但是數據獲取仍然是一個巨大的麻煩。

Drew：所以，React 配置了許多其他工具，可以很好地與 React 配合使用，為您提供一個功能強大的生態系統來完成這種特定風格的任務。 這是一個公平的描述嗎？

安東尼：是的，不，是的，這是一個很好的表達方式。 Tom 所說的方式是，存在所有這些最好的解決方案，以及我們可以使用的非常複雜的工具和技術，但實際上很難利用它們，因為你有如此巨大的啟動成本，並且必須學習它們，必須弄清楚如何整合它們。 所以，他們把標語寫成“我們為你做你的 webpack 配置”。

Drew：我認為，當很多人嘗試使用客戶端 JavaScript 應用程序和配置 web 包、配置所有不同的東西、構建過程、構建步驟。 這可能是一個相當大的雷區，不是嗎，讓所有東西都連接在一起並正常工作？ 距離“Hello, World!”還有很長的路要走。 那麼，Redwood 為我們提供了所有這些預配置？

Anthony：是的，這在很大程度上是一種配置類型想法的約定，因為你有...... Tom 就像他用 Ruby on Rails 和 Rob 構建 GitHub 一樣，其他核心貢獻者之一，他一直是 Rails 開發人員。 他們在 Rails 方面有很多在哲學上與他們保持一致的想法，但他們希望將這些約定優於配置想法、完整的堆棧框架想法，並用我們現在擁有的所有現代技術來實現它。

Drew：所以，您提到 Redwood 為您提供了一個路由器或路由器，正如我們在池塘這邊所說的那樣，它是否帶有諸如默認組件之類的東西以及 React 中的任何此類東西，或者您只是那時自己實施所有這些？

安東尼：是的，路由器非常複雜。 它完成了你從 React 路由器獲得的大部分東西，它在如何實現這些方面有一些不同的想法，因為 Next 他們也有自己的路由器，但它仍然沒有完全弄清楚我們是如何實現的想讓我們的單頁應用路由工作。 因為 Suspense，你有很多這樣的問題，關於異步的東西會在哪裡出現？ 我們有 Redwood，這個單元的想法，這就是你的數據真正為你獲取的東西。

德魯：所以，也許我們可以深入探討一下？ 就紅木而言，細胞是什麼？

Anthony：是的，因此單元格是編寫 GraphQL 查詢的默認方式，然後讓您的頁面基本上告訴您是否正在獲取數據，是否返回錯誤，是否處於加載狀態，或者是否……還有一種狀態，我忘記了。 但是，是的，所以它會根據您是否獲取數據，為您提供基本上可以處於的不同狀態。 它是由 Apollo 在幕後設置的。 因此，如果您使用 Redwood，那麼您將使用 Apollo 作為您的 GraphQL 客戶端，但您不必考慮它。 您無需編寫任何 Apollo，甚至無需考慮它，一切都已融入其中。它讓您只需編寫 GraphQL 查詢，這正是人們想要 GraphQL 的真正夢想，前端開發人員正是這種非常簡單的查詢語言可以用。 但是，你必須弄清楚如何設置 GraphQL 服務器，你必須弄清楚所有其他的東西，以及如何將所有這些連接起來。 因此，它為您完成了所有 GraphQL 集成，因此您只需編寫 GraphQL，您甚至不必考慮我如何實現 GraphQL。

Drew：所以，我想一個框架的經典工作之一是獲取所有你可以自己編寫的樣板代碼並為你實現它，並整理幕後的方式，這樣你就不必看那個樣板了再一次，您可以只編寫適合您情況的代碼。 我想這就是細胞發生的事情吧？ 這裡沒有什麼革命性的東西，你可以設置一個 React 組件來擁有所有這些不同的狀態，你可以掛鉤 Apollo，你可以自己做這一切，但這實際上是相當多的工作，這是一種常見的模式。 因此，Redwood 已經整理成一個很好的、可重複使用的模式，您可以直接開始使用而無需考慮它。 這是一個很好的描述嗎？

安東尼：是的，他們想出了這個名字，但他們肯定承認這是他們經常看到的一種做法，而且他們看到很多人只是自己編寫代碼，他們決定他們想要一種聲明式的方式來獲取數據。 所以，這就是你有這個設置的原因，因為它讓你只有不同的狀態，你不必做 if/then 邏輯來弄清楚，如果發生這種情況，需要這樣做。 因此，它只是通過一種方法來聲明數據在加載時可能處於的所有不同狀態。

Drew：這是 React 的特性之一，不是嗎，React 不會嘗試為您的項目提供架構，它讓您決定如何構建事物。 當然，這有利也有弊。 但是，Redwood 似乎在為你強加一些這樣的結構，這樣你就不必考慮它，它可以為你安裝管道，並在 React 停止的地方為你提供幫助那種結構。

安東尼：是的，我認為我們已經看到了解決這個問題的多種不同嘗試，這真的很有趣，因為我的意思是有人一直在說，“為什麼沒有 Rails用於 React 的 JavaScript 還是 Rails？” Michael Chan 和 Adam Wathan 之間有一個很棒的 Full Stack Radio 採訪，叫做 React is Not a Rails 競爭對手。 這是不同的框架之一。

Anthony：其他的是 BlitzJS，它已經引起了相當多的關注，然後 Bison 是一種新的和即將到來的。 它們都有類似的堆棧，但它們使用不同的部分。 您將使用 React 查詢而不是 Apollo，或者您將使用 Chakra 而不是 Tailwind。 那些將所有這些碎片組合在一起的人，所有這些堆疊都是一種，他們正在與之抗爭，這都是非常友好的競爭。 實際上，我真正欣賞的一件事是，我們實際上也都在框架之間進行了協作。 那裡沒有仇恨。

Drew：所以，我們提到了 Apollo 和 GraphQL，Redwood 大量使用 GraphQL 作為框架的核心部分之一，不是嗎？ 我們可能可以將整個播客集專門用於 GraphQL，但對於那些不熟悉的人來說，GraphQL 在這裡做什麼，它在這種情況下解決了什麼問題？

安東尼：是的，這是一個很好的問題。 當我告訴人們他們應該知道什麼才能開始使用 Redwood 時，我會說你應該使用 Create React 應用程序，就像你已經製作了一個 Create React 應用程序，並且你已經將它部署到 Netlify 或Vercel，那會給你一個好的開始。 然後，至少了解一點 GraphQL，因為它非常核心。 因此，GraphQL 是您的前端與後端對話的方式。 他們說它是 API 的一種查詢語言，其想法是它旨在替代 RESTful API 方法，而不是做那種 RESTful 的事情，你發送的查詢準確地指定了你想要從那裡接收的分層數據結構數據庫。 因此，需要更多的啟動時間才能讓 GraphQL 服務器與這兩個部分通信。 然後，一旦你有了它，前端開發人員就有能力以更靈活的方式獲取數據。 您不需要後端人員需要不斷製作的所有這些不同的 API 端點。

Drew：所以，如果前端的需求發生變化，大概您可以調整您的 GraphQL 查詢，而不需要後端工作人員的幫助來為您進行更改？

安東尼：我的意思是，真正的夢想是你可以給它一個移動客戶端，它最終會變得如此靈活，你可以讓多個客戶端都與你的一個 API 對話。 您的 GraphQL API 成為您的事實來源，您的所有邏輯都集中在此處。 然後，您可以在頂部構建所有這些不同的視圖層。

Drew：所以，我們有 GraphQL，讓我們能夠查詢某種後端。 在 Redwood 中，後端是什麼？

安東尼：是的。 有幾種不同的方法來創建你的後端。 您可以通過本教程開箱即用的方法，即使用部署在 Heroku 上的 Postgres 數據庫，超級簡單，超級簡單。 然後，您的 Redwood 應用程序會與 Prisma 對話。 我不知道你是否熟悉 Prisma，但它就像一個 O/RM。 他們特別說它不是一個 O/RM，它是一個查詢構建器，它的級別要低一些。 但是，為了向人們解釋它，Prisma 是讓您與數據庫對話的東西。 它會執行您的遷移並設置您的表格。 它完成了所有的 SQL 工作，因此您不必編寫 SQL。 對我來說，這聽起來像是一個 O/RM。 儘管使用 Redwood，但您不一定需要使用 Prisma。

Anthony：我實際上構建了一個概念驗證應用程序，我們使用 FaunaDB 代替。 FaunaDB，他們有自己的 GraphQL API，所以你可以直接將 GraphQL API 發送給 Fauna，然後用這種方式進行數據庫突變。 您失去了 Prisma 的 CLI 的很多功能，但 Prisma 確實是一個方便的因素，可以真正輕鬆地使用您的關係數據庫。 但實際上，你能想到的任何東西，你都可以弄清楚如何將它與 Redwood 連接起來，這是我發現的，因為它是圍繞 GraphQL 構建的，而且重點是能夠與所有這些不同的部分進行對話。

Drew：所以，Prisma 本質上是您的代碼和您使用的任何數據存儲之間的一種抽象層，大概是 Prisma 支持的，是……還是它做的事情比這更智能？

安東尼：是的，所以你寫了一個模式，所以你創建了一個 schema.Prisma 文件，它會有模型帖子，然後它會有 id 和整數和自動增量，如標題字符串、正文字符串，在日期、時間創建. 因此，您基本上可以使用類型在數據庫中創建您想要的內容，然後它會為您處理數據庫內容，因此您不必與數據庫進行交互。

Drew：所以，你使用 Prisma 來定義我猜你正在與之交談的數據庫或數據存儲類型。 然後，在那裡你列出你不同的 mvc 模型來使用那個說法。 那麼，當您的應用程序與數據存儲通信時，它有點使用 Prisma 客戶端的實例，是嗎？ 這是怎麼回事？

安東尼：是的。 是的，就是這樣。 因此，在後端的 API 文件夾中，您有一個帶有 db.js 的 lib 文件夾，並且默認情況下設置了您的 Prisma 客戶端。 所以，這就是你開箱即用的所有東西，就像你說的，Prisma 可以與不同的數據庫一起使用。 它可以在用於開發的 SQLite 和用於生產的 Postgres 之間切換，諸如此類。 現在主要是關係型的，但路線圖上有 Mongo 和 Fauna 之類的東西。

Drew：所以，如果您可以在本地開發環境中設置和使用 SQLite，因為您正在啟動和運行，然後使用 MySQL 之類的東西進入生產環境，這將非常有用。

Anthony：這正是教程的設置方式，它向您展示的工作流程。

Drew：很有趣，不是嗎，看到一個非常現代的框架方法，然後又回到一些更傳統的數據庫，比如 MySQL。 我對 MySQL 非常熟悉。 我喜歡它的穩定性，我喜歡存儲數據的關係方式。 我認為它適用於很多事情。 當涉及到新類型的數據存儲時，您經常會看到被扔掉的嬰兒是洗澡水，因此看到 Redwood 默認支持這些良好的舊關係數據庫是非常有趣的。

安東尼：是的，不，這是一個很好的觀點，因為我說對於紅木結合在一起的所有新東西，有些東西實際上表明舊的、經過嘗試的和真實的方法實際上是最好的。 因此，它們在關係數據庫方面非常重要。 這來自於 Tom 使用 Rails 和擁有關係後端的經驗。 Active Record 是 Prisma 想要近似的 O/RM 層。

Drew：我想，我們在這裡與 Redwood 討論了無服務器架構，我們與 Chris Coyier 談了兩三集，所有關於使用 API 和雲功能的無服務器等等。 因此，退後一步，如果您要考慮基於服務器的框架，就像我們提到的 Ruby on Rails 或 PHP 世界中的 Laravel 之類的東西。 即使使用 React 前端，您的 API 請求也將運行 Rails 代碼或 Laravel 代碼加上您的用戶代碼和配置的代碼。 紅木也一樣嗎？ 是否有實際運行的 Redwood 服務器代碼，或者只是更多的工具、結構和膠水使您能夠實現自己的？

安東尼：是的，所以在後端，有一個文件專門用於獲取 SDL，所以你有你的模式定義語言，然後你有所謂的服務，就像你與你的對話的方法後端。 然後，所有這些都被拼接到一個部署到單個 Lambda 函數的 GraphQL 處理程序中。 因此，它專門針對 Lambda 進行了優化。 實際上，我們最近剛剛有人使用無服務器框架來做這件事，並且我們有一些人在 Azure 和 Google Cloud 上工作。 它不是 Google Cloud 功能，而是建立在此之上的功能。 但是，是的，所以它現在基本上針對將後端部署為 AWS Lambda 中的 GraphQL 函數進行了優化。 這是我不理解的代碼中發生的所有魔法的東西，但這是高級解釋。

Drew：所以，有一些部署工具，可以將您編寫的所有代碼壓縮成某種神奇的代碼球，可以在雲中執行並將其放到 AWS 上，或者您是否願意仍然需要自己管理該過程嗎？

Anthony：是的，如果您按照教程進行操作，這一切都是通過 Netlify 完成的。 您實際上不必自己弄亂任何類型的無服務器功能。 將您的後端連接在一起以將其推入 AWS Lambda 的東西，這一切都已處理，您無需接觸任何代碼。 這些都是開箱即用的，因為您對配置的約定，因此您不必考慮如何使其無服務器。 默認情況下它是無服務器的。 這真的是一件很難的事情。 我花了一段時間才把頭繞過去。

德魯：是的，因為這很重要，並不是因為我們現在正在跟踪幾個不同的領域。 我認為我們有三個不同的領域。 我們有我們的前端 React 應用程序，它在瀏覽器中運行，然後我們有一個基於 GraphQL 的 API，作為雲功能運行，它響應我們的查詢，然後與數據存儲交互它使用棱鏡。 那個數據存儲是什麼和在哪裡，因為你不能在 Netlify 上運行 MySQL 服務器，可以嗎？

Anthony：是的，這就是 Heroku 的用武之地。因此，在教程的最後一部分，您將前端部署到 Netlify，然後將後端部署到 Heroku Postgres，然後您只需從 Heroku 獲取配置變量，插入即可進入 Netlify。 讓您的 Netlify 前端與您的 Postgres 後端對話是一件非常非常簡單的事情。 他們想選擇對任何人來說都是最容易啟動的東西，但仍然擁有良好的穩定、經過實戰考驗的技術。 最後，您只需按照說明開箱即用，真是令人難以置信。

Drew： Jamstack 愛好者會熟悉像您提到的將數據存儲作為 API 提供的 FaunaDB 等服務，AWS 有 DynamoDB，Google 有 Cloud SQL 等等。 那麼，您提到 Redwood 正在考慮集成，或者我猜 Prisma 是這裡正在考慮與這些服務進一步集成的組件？

安東尼：是的，這是一個很好的問題。 這實際上是我在 Prisma 與 Ryan Chenkie 談論的關於幫助的事情，對於不一定與 Prisma 一起工作的事情，Redwood 的數據庫故事是什麼？ 像我對 Fauna 所做的那樣，想辦法讓 Redwood 直接使用它會更好，還是為 Prisma 實現驅動程序更有意義？ 所以，有不同的方法來處理它。 顯然，現在每個人都想使用一百萬種不同的數據庫，因此您有多大的動力將數據存儲到其中。 那裡有很多社區貢獻。

Drew：那麼，因為 Prisma 了解您的模型並且知道如何查詢它們，它是否能夠生成某種遷移或類似的東西來幫助您設置數據庫？

Anthony：這正是當你不得不取出 Prisma 並獲取數據時你失去的東西，就是你失去了所有的遷移功能。 它有一個非常先進的 CLI，可以為你做很多事情，所以你可以瀏覽整個 Redwood 教程並輸入 Prisma 命令，你不必知道它在做什麼，它就可以工作。 它是一個非常棒的工具，可以處理所有你想要確保正確並且想要確保它正確完成的數據庫類型的東西。

Drew：似乎圍繞框架擁有一個非常好的工具是一種非常現代的趨勢，不是嗎？ 不僅僅是說，“這是這個框架可以做的所有事情，但這裡可能有一些 CLI 工具可以為你做很多事情。” Redwood 是否有諸如 CLI 生成器之類的工具來幫助您快速啟動和運行？

安東尼：這可能是您從 Redwood 獲得的最大關鍵功能，是您獲得了一整套非常複雜的發電機。 對於曾經看過 DHH 提供的原始 Ruby on Rails 演示的任何人來說，他在 15 分鐘內建立了一個博客，並且他使用 Rails 完成了所有工作，人們會說，“哇，這太棒了。” 這就是紅木的效果。 他們希望你能夠快速啟動所有內容，這樣你就可以生成頁面，你可以生成佈局，你可以生成你的單元格，這就是我所說的，你可以執行一個腳手架命令來創建你的整個CRUD 接口。 我有一整節，博客系列的第四部分，只是解釋了腳手架給你的所有代碼。 它給了你很多代碼。 有一個關閉發電機，甚至還有一個 Tailwind 發電機可以為您配置順風。

德魯：太神奇了。 我記得看過 DHH 的 Rails 演示。 我的意思是，這可能是 15 年前他第一次做那個腳手架並向你展示的時候，你得到了一個相當基本但功能強大的控制面板，基本上可以讓你創建新項目、編輯它們、刪除它們等等. 這在項目中可能是無價的，特別是在一種動態環境中工作，好吧，也許您將來會實施更好的工具來編輯該內容，但這意味著能夠快速啟動某些東西，您可以獲得測試數據，或者您甚至可以將其交給內容團隊，他們可以在您在前端工作時開始工作，所以這非常有用。

Drew：如果您只想部署它並在生產環境中使用它，大概可以將它與前端代碼一起部署，但您需要某種方法來保護這方面，即應用程序中的那些根。

安東尼：是的，有幾種不同的身份驗證選項。 您可以使用 Netlify 身份。 如果你進入教程，這是默認設置，然後你也可以使用 Auth0，然後是我不熟悉的一個叫做 Magic.Link，將來可能會添加幾個額外的。 但是，是的，所以那裡已經有幾個內置的解決方案，這是你做的最後一件事，所以這是我整個 12 部分博客系列的最後一部分是 Auth 的。 在我使用 Redwood 之前，我認為我從未想過 Auth。 這很難，他們肯定做得很好。

德魯：那是在路由級別還是路由級別集成，抱歉，你如何保護東西？

安東尼：是的，所以他們有自己的路由器的一部分，他們也有……你可以做私有路由，所以他們有一個私有路由組件。 然後，您的實際登錄表單，這就是您從 Netlify 身份獲得的信息，因此您不必實際創建表單並使用它進行狀態管理，這就是很多問題發揮作用的地方。 去掉真正關鍵的部分，然後你就可以實現基於角色的訪問。 我們在過去幾週添加了基於角色的訪問控制，這是 David T 完成的。所以，有很多工作正在發生以創建其他方法來做到這一點，但他們現在得到的已經是......它有效，它'會讓你發揮作用。

Drew：人們總是說安全算法散列密碼學，你永遠不應該編寫自己的，因為它永遠不會像外面的東西那麼好。 我越來越多地認為，更高級別的身份驗證也是如此。 如今，身份驗證是一個非常複雜的領域，人們不僅希望使用唯一憑據登錄您的網​​站，而且他們可能希望使用 Google 進行身份驗證，或者他們可能希望使用 Apple 設備進行身份驗證，或者他們可能想要兩因素身份驗證，或者他們可能希望將其與他們從企業使用的單點登錄服務集成。 如果您嘗試自己實現所有這些事情，那麼所有這些事情都會非常令人頭疼，並且有很多機會出現錯誤並暴露應用程序中的安全漏洞，因此在我看來，使用身份驗證服務在這一點上幾乎是輕而易舉的事。 因此，只需幾行代碼就可以投入一些東西並啟動並運行，這聽起來像是一種非常有效的工作方式並保證事情的安全。

Drew：聽起來前端和服務器方面的部署，無服務器功能的東西，很自然地適合部署到 Netlify。 你和紅木有關係嗎？ 我的意思是，我們提到 Tom Preston-Werner 是這個框架的主要支持者之一，他也是 Netlify 的董事會成員。 如果您選擇紅木作為項目的基礎，您認為那裡的耦合可能會太緊嗎？

安東尼：是的，這是湯姆明確意識到的。 他投資了很多公司。 他投資了 Prisma 和 Fauna。 他只想製造他想使用的工具。 這不是因為我們想把你鎖在這個東西上，而是 Netlify 構建的他認為是最好的選擇，所以這就是他們圍繞它構建的原因。 但是，他們不希望它被鎖定到任何一個部署目標，這就是為什麼我們在無服務器框架之類的事情上進行了工作，並且有些人談到了 Begin。 我們想要務實，我們希望它適用於任何人的用例。 因此，我們為您完成了 90% 的工作，然後您只需連接最後幾件事，即可使其與您選擇的任何服務器一起工作。

Drew：我猜 Netlify 也在使用 AWS Lambda 作為服務器功能，所以實際上部署部分由 Redwood 負責，實際上您可以自己將其部署到 Lambda。 發布您的前端只是文件，不是嗎，它是基於 CDN 的其餘部分？ 所以，那裡有很大的靈活性，而不會太拘束。

Anthony：是的，實際上有一個術語是 Tom 談到的 Redwood 背後的核心哲學思想，即我們想要獲得一個通用部署機器。 這是一種想法，你可以只部署東西而你根本不需要考慮它。 他多年來一直在談論這個想法，而這就是 Jekyll 甚至在過去的時候所說的。 當你現在聽到這個時，你會說，“哦，你的意思是像 Netlify？” 對於大多數從事前端工作的人來說，這基本上就是 Netlify。 他們甚至不再考慮部署，甚至都沒有想到。

Drew：這是我在 Git Repo 中的應用程序，這個目錄是前端，這個目錄是後端，這是我的數據庫，這可能是你需要的盡可能多的配置，然後是任何服務來獲取它並構建它並託管它。

Anthony：是的，我還應該指出一件事，我們最近剛剛設置了 Vercel Redwood 默認部署，所以當你在服務器端應用程序上進行部署時，你可以說，“哦，我有 Gatsby 應用程序，”並且它確切地知道如何構建 Gatsby 應用程序和 NextApp。 我們現在有 Vercel 的。 所以，如果你更感興趣的話，還有非常非常好的非 Netlify 選項。

Drew：那麼，如果我想在本週開始構建一個應用程序並將其投入生產，Redwood 準備好了嗎？ 成熟了嗎？

Anthony：是的，我們現在有大約 6 個正在生產的應用程序。 第一個名為 Predict COVID，於 3 月問世，它就像一個實時數據可視化應用程序。 然後，我們得到了由 Rob 完成的 repeater.dev，這就像 Jamstack 的 cron 工作。 然後是 Tape.sh，我認為 Duofrag 是另一個。 所以，至少有幾個。 如果你去很棒的 Redwood repo，你可以看到所有這些的列表。 如果你去社區論壇，你也可以找到關於這些的文章，因為人們已經將它們投入生產，並且有點說它是如何進行的。 到目前為止，他們都取得了成功，沒有人說，“我再也不會使用這個了。”

德魯：但是，它是非常新的。 我想這是無法避免的，但就成熟度而言，Redwood 是相當新的，它得到了很好的追隨者。

安東尼：嗯，這很有趣，它是，它不是。 它是在三月份宣布的。 那時，湯姆和彼得已經研究了大約一年。 So, they'd already put a ton of upfront work into this, so it wasn't like I'm going to announce this project with a Read Me and then start building it. By the time they announced it, it wasn't… It's not a 1.0 now, but it's pretty dang close in terms of what people would expect out of a 1.0. But, Tom is very against what we call type driven development so he always errs on the say it's not ready. So, we say it's not ready for production even though it's in production.

Drew: I think one thing that people sometimes get burned on using frameworks is that they'll build a project around the framework and then that framework will very quickly go to another major version that had backwards incompatibilities, and they're then left with a big project to update everything onto the new version of the framework. Is that something that's likely to happen with Redwood? I mean, none of us has got a crystal ball, but just with the technologies that are involved and the way it's structured, do you think that's a big danger or a little danger?

Anthony: Yeah, it's a super valid concern and definitely something the team has thought about. The CLI has an upgrade command, so you can basically every time there's a version bump, you just do a command and it bumps you up the version. I've been dealing with this a little bit just because of the series I wrote, I started it when it was on version 11 or 0.11, it's like 0.17 or something now. So, I've been slowly iterating on it as it's gone but nothing breaks. It's all, you get slowly things, or like “Oh, this is kind of a nice little touch you've got here,” but it's pretty much set in stone architecturally. Redwood as it's structured, the front or the back end is not going to change at all. It was very well thought out in terms of what they want architecturally. That's why they built it, so they could get something that's structured like this thing.

Drew: I guess with modern web development, there is a certain point where you're just never going to get away from being reliant on dependencies updating themselves and changing. I mean, even using React, React goes through as many different changes as anything else.

Anthony: That's exactly why Tom inventing semantic versioning.

Drew: I guess from the other side of that coin, if Redwood did happen to go away, which is always something we consider when picking a framework, if development stopped somehow, I guess the impact on a particular app might not be too great because it is just so heavily built on existing other projects around. Is that-

Anthony: Well, some would say that a Redwood tree can survive a lot, it survives for a very long time. That may have been why it's called that, is that you can just make a site and deploy it and it's not going to break, it's just going to work. So yeah, maintainability, sustainability, all that kind of stuff, that's huge. Being built by people who tried to scale Rails apps, I imagine they've thought a lot about that. But in terms of the going away part, that's always going to be a danger with any open source project, so I think what you have to look for is how enthusiastic is the community to continue it without the team if that ever happens. I don't think you even need to worry about that because Tom's a billionaire and he has a venture funding thing that is funding some of the development. It is an open source project that is well funded actually. It has four full time members, Tom, Rob, David, and Peter. You just go to the forums, you can see the activity that's going on, so I wouldn't worry about that too much-

德魯：當然。

Anthony: Beyond normal open source worries that come along with that stuff.

Drew: What is the community like? You mentioned the community, are there lots of people using it and contributing to the code base or is it mainly the core team who are doing the development?

Anthony: Yeah, it's very much structured to be a community thing. They want to get as much buy in from the community as possible, and this comes from the lineage like you said. There's few people with more open source cred than Tom, so he's done a really great job of bringing people into the fold. I think just my story in general is a big win for the community because I came in, I'm a boot camp student, I'm learning all this stuff as I go. I'm not pushing code to the repo, I'm making doc fixes and writing blog articles and stuff, but they still invited me to the core contributors meeting because they saw what I was doing and they thought it was adding value. Yeah, there's really a lot of things about how they approach community building that I have a lot of respect for, and that is why I've been so invested in it and putting so much of myself into it.

Drew: Some frameworks have got this sort of natural bent for certain types of projects. 例如。 The Python framework, Django came out of online news publishing, and so it's a really good fit if you want to rapidly publish content like you would in a news organization. Does Redwood lean in any particular direction when it comes to the type of projects? Is it suited for content publishing or building web applications or-

Anthony: It's made to be fairly agnostic to that. It wants to be a tool that you use for a lot of stuff. First, before it was called Redwood, it was called Hammer, the idea being that you do a lot of stuff with a hammer. But, there definitely is a kind of sweet spot, which I think is the multi client type applications. So, if you know that you're starting with a web front end but you're pretty sure you're going to end up with a mobile client as well, then it's a really good fit for that because it starts you off in a way that you're going to be able to extend into having multiple clients with GraphQL, which we kind of talked about a little bit. So, I'd say that'd probably be the first thing that I would say is its sweet spot. But, it's meant to work for as many things as possible.

Drew: Does Redwood have a published roadmap of where it's going? What can we expect to be coming in the near future?

Anthony: Glad you asked. We just put out a roadmap to 1.0 less than a month ago, it was probably like two or three weeks ago. It kind of itemizes things that we're working on, things we think we're kind of close on, things we think we still have a long ways to go on. That kind of helps the community see where can I help contribute. That's one of the things we're really great about is showing here are the things that still need to be worked on. They're aiming for 1.0 by the end of the year. We'll see where we get with that, but that's the trajectory we're currently on.

Drew: One of the beauties of a Jamstack and a serverless approach I always think is that it's this idea of lots of pieces loosely joined that has served us so well in computer science up until this point. It should be really easy to scale up a Jamstack and serverless project because you can add multiple front ends or you could put more resources behind running your functions, and you can scale up a big engineering team by having people work on different small pieces. Is there a danger that adopting a framework around all of that, that you might be taking a distributed architecture and creating a tighter binding than you might otherwise have? Could Redwood become the monolith that acts as a bottleneck in your engineering efforts?

Anthony: Yeah, this is something I think about a lot because as I learned web development, I was taking… I'm in a boot camp that supposedly is full stack development, but you learn each piece in isolation. We're essentially learning the PERN stack, but you learn React, and then we learned Express. We never talked about how it actually works together. So, I do think that there is definitely a danger of not being able to comprehend in your project because of how it's all wired up. So, what I really liked about Redwood is that it just made sense. It was a mental model of how to think about my entire app and all the pieces and how they fit together in a way that really made sense to me. But, what I was surprised to find doing the Fauna project is that it's much more modular than you would think based on… You talk about it, and like you said, it sounds like it's a monolith thing, but you can rip pieces out and replace them with other pieces and they can still work. So, it's made to be a fully integrated solution, but not a solution that is tightly coupled just because this is a good way to integrate all these technologies doesn't mean you need to tightly couple them to integrate them well.

Drew: Yeah, that sounds a very promising way of structuring things, and it's going to be really exciting to see what happens with Redwood as it gets to version 1.0. Is there anything else we should know about it that we haven't talked about?

Anthony: No. I mean, I would say if you're interested, just check out the tutorial on YouTube, the RedwoodJS tutorial. They have what they call tutorial driven development, which is kind of a play on Read Me driven development, which is another thing Tom coined, that you should start with a Read Me, and then create your code to make sense with what your Read Me was. This is the idea of you create a tutorial and then you write your framework to make the tutorial work. So, that's why it's a really easy way to get spun up with it because it was made to make sense of going through the process of learning it. They've really thought about how to actually get onboarded into a massive framework with all these different pieces and all this different new tech. They progressively reveal it to you as you go. The series that I wrote is very heavily influenced by it. I essentially built the same project, but I write my own stuff as I go, and reference the docs. So, if you're interested in just learning Redwood, start with the actual tutorial and then check out my series.

Drew: So, I've been learning all about Redwood, what have you been learning about?

Anthony: Yeah, so I've been learning about CMSs, and I was actually really curious to get your thoughts on this because I imagine you've been around the block, you know a lot of CMSs. Obviously, you know you've got your WordPress's, your Drupal, but what's really interesting with something like Redwood is since you have this GraphQL stuff baked in, it has the CMS, it's just such a natural fit. So, I'm trying to figure out, what are interesting headless CMSs to check out? Which ones have GraphQL integration? Which ones have different sweet spots? If I wanted to take a CMS to build an app with RedwoodJS, what would you recommend?

Drew: That is a good question, and I'm not sure I have an immediate answer. I have looked at lots of different CMSs, not particularly with a view to GraphQL. I've not worked with GraphQL myself yet, and so that was not-

Anthony: Oh man, you've got to join the club, dude.

Drew: Yeah, no, I'm definitely getting onboard. But yes, I have a requirement at work that may be coming up to know a bit more about GraphQL, so it's certainly one of the things that I need to be learning.

Anthony: I actually learned GraphQL through Redwood. I didn't really know GraphQL, and I'd say you should know a little bit before going into it, and I had a very, very tiny basic knowledge. You can actually learn what a schema definition language is, and that GraphQL kind of jargon. You'll learn a lot and you'll pick it up as you go with Redwood.

Drew: Yeah, I should definitely get onboard and maybe doing some Redwood is the way to do it. Perhaps I need to pick up a project and start going with Redwood and see where it takes me.

Anthony: Yeah, at the very least I would say just check it out, just because it's interesting. I find it to be just a really fascinating thought experiment of how do we do modern web application development differently and more coherently.

Drew: If you, dear listener, would like to hear more from Anthony, you can find him on Twitter at ajcwebdev. His comprehensive series of articles about getting started with Redwood are on the Redwood community site, which we'll link to from the show notes. Of course, you can find all about Redwood and get started at RedwoodJS.com. Thanks for joining us today, Anthony. 你有什麼離別詞嗎？

安東尼：如果你對這些東西感興趣，請隨時聯繫。 我的 DM 總是打開的。 社區總體上非常開放。 我很樂意為您解釋或演練，或為您設置任何您需要知道的內容。