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 配合使用，为您提供一个功能强大的生态系统来完成这种特定风格的任务。 这是一个公平的描述吗？

安东尼：是的，不，是的，这是一个很好的表达方式。 汤姆的说法是，存在所有这些最好的解决方案，以及我们可以使用的非常复杂的工具和技术，但实际上很难真正利用它们，因为你有如此巨大的启动成本，并且必须学习它们，必须弄清楚如何整合它们。 所以，他们把标语写成“我们为你做你的 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. 就是它-

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 总是打开的。 社区总体上非常开放。 我很乐意为您解释或演练，或让您准备好一切您需要知道的事情。