Swift on the Server, Hummingbird
41:08 Share

本周，我们讨论使用 Hummingbird 的服务器端 Swift。我们还讨论了 Vapor 以比较这两种体验。(00:00) - 介绍 (08:44) - Clean My Mac (28:20) - 咖啡时间 (34:17) - Cocoatype.com (34:57) - 支持播客 https://www.compileswift.com/podcast/s06e12/https://vapor.codes/https://hummingbird.codes/Clean My Mac 感谢我们每月的支持者

Adam Wulf bitSpectre Arclite

★ 在 Patreon 上支持此播客 ★ </context> <raw_text>0 大家好！欢迎收听 Compile Swift 播客。我们这里又有一期特别节目。今天我们将重点关注一些服务器端规则。但首先，Jeff，你好吗？是的，我的应用程序实际上比我预期的要早发布了一个新版本。我不小心点击了复选框，或者留下了复选框，该复选框会在我可用时继续发布应用程序，并且……

它发布了，而我并没有预料到它会发布。所以每个人都会在几天后收到社交媒体推送，但是，呃，

你知道，嘿，这不像任何人都会阅读发行说明一样。对。对。对。你有没有那种时刻，你会想，哦，等等，糟糕，我，我发布了后端的所有内容吗？你知道，我有没有把它……谢天谢地，不需要后端，但是，是的，我实际上正在和我的一个朋友一起吃午饭，他说，哦，嘿，我看到新的更新发布了。我说，哦，你，你，我认为你在我的测试版中。你一定是在测试版构建中。他说，不，不，

那不是我的意思。哦，是的，果然。我们在应用商店里查看，是的，不，它在应用商店里。所以，哎呀。呃，但是，嘿，你知道吗？这并不是世界末日。嗯，

我没有进行我想要做的最后一分钟测试。没有准备好发行说明。没有，你知道，推送社交媒体内容。但是，你知道，人们会在它应该发布的那天收到它，也就是我录制节目的明天。而且，你知道，我可以随时跟进我之后没有发现的任何错误。我只是想说，这不是理想的方式，但情况本来可能更糟。

嗯，这很有趣，因为，你知道，你不能抱怨这些事情，因为如果你过去抱怨过，对，完全正确，苹果公司的人会说，看，你们这些家伙，当应用审核时间太长时，你们会抱怨，所以我们加快了速度。现在你又抱怨我们效率高。你想要哪个？不，这个……

应用审核，这正是我提前提交的原因，就像我希望应用审核完成一样。我希望它准备好发布。然后我花时间在应用审核之后准备好所有东西。整个问题只是苹果在那里有一个复选框，说一旦准备好，

让我点击它，或者一旦准备好，就自己发布它，而我显然将其设置为自动发布，这不是我想要的，但是，嘿，我只需要下次更好地检查一下，完全理解，因为据我所知，我已经很久了，我从未进行过自动发布

我只是太害怕它会在尴尬的时刻发生。我认为发生的事情是之前之前的版本可能是一个大型错误修复版本，我希望它尽快发布，然后我没有设置……

复选框，我认为就是这样，是的，因为在此之前的 24.5 版本修复了 Apple Watch 同步和 Apple Wallet 导出无法与特定一组条形码一起使用的问题，所以我当时想，哦，糟糕，你知道

Apple Wallet 就像一件大事，然后我将发布它，然后每个人都会说，嗯，它不适用于此条形码。所以我想尽快发布修复程序。所以我将其提交给 Apple，进行了快速审核，并选中了复选框，一旦完成就立即发布，因为，你知道，如果我提交了这个，然后我去睡觉，那是深夜，我不希望人们不得不额外等待八个小时或其他时间。所以，是的，那个版本在可用时就发布了。是的。

不幸的是，它记住了你的偏好。而这次我并不想要那样。看，这很有趣，因为你这么说的时候，我就在问自己，你知道，我对它记住是否感到高兴？老实说，我不知道。我想这是那些时候之一，就像，不，我认为我宁愿它默认为最安全的选项。

但是我敢打赌，那里有很多人都喜欢，只是发布这个东西。好吧。好的，让我们开始吧。所以我们正在讨论一个主题。我们之前在播客中多次讨论过这个主题。我想给……对不起？你在播客中讨论过它。

我想做到包容。我在考虑你的感受，你知道的。完美。第一次，对吧？就像，真的吗？现在是你选择这么做的时刻吗？真的吗？是的。

是的，所以我们之前邀请过 Yanis 来节目。我们将从 Hummingbird 项目中在节目说明中添加指向此内容的链接。是的，我们正在讨论服务器端的 Swift。在本集中，我们将主要关注 Hummingbird。但是，我相信你们很多人都会大喊，这是什么？Vapor 怎么样？那又怎么样？是的，很多这些内容之前都讨论过。当然，还有很多选择，但是……

我们有理由关注这个。主要是因为 Jeff 一直在使用它。所以让我们深入探讨一下。但就像我说的，我们会像往常一样在节目说明中添加指向所有内容的链接。但是，这一集也讨论了 Yannis 关于 Swift 服务器组的内容。该项目背后有很多推动力量。

但是让我们深入探讨一下。你知道，我从一开始就开始了，Jeff。所以你实际上是在生产中使用它，对吧？我认为这对大家来说非常重要，因为我们作为开发人员都会这样做。我们会玩一些东西，对吧？但是当你这样说时，你就会上升到另一个层次，好吧，它现在正在生产中。所以你想谈谈这个吗？

是的，我现在实际上在生产中运行几个不同的服务。我混合使用了 Vapor 服务和 Hummingbird。稍后我们将讨论这两个项目之间的区别。但是，是的，我目前最常用的一个是 Hummingbird。这是我最近做的一个。它被我的最新应用程序 Bark.com 使用。

因此，它比任何 Vapor 服务本身都得到了更多的使用。但是，是的，我已经运行这两个项目一段时间了。我认为我对它们的工作方式、完成方式以及各自的优缺点有一些看法。是的。

嗯，我认为，你知道，第一个自然的问题，而且这个问题总是出现，公平地说，这也是我经常问自己的问题，那就是为什么根本要在服务器上使用 Swift？我认为这个问题很难回答，因为它属于那个类别，就像为什么根本要在服务器上使用任何东西一样，对吧？用语言 X 替换它，我不是指那个社交媒体网站，对吧？

你知道，是的，你在网上有数百万个选项。就我个人而言，我没有用 Swift 发布任何东西，不是因为有什么反对它的原因，而是，你知道，我只是习惯了所有其他 Web 语言，首先就有一个 Web 背景。所以让我们深入探讨并讨论一下，你知道，那个主要问题，为什么根本要在服务器上使用 Swift？

我的意思是，我认为我会首先给出最简单的答案，那就是个人喜好。我是唯一一个必须处理这个问题的人，因此我说了算。因此，我选择这个特定选项而不是我拥有的任何其他选项。所以我要跳进去，因为，你知道，这是很多人，你知道，我们都知道这一点，互联网人士，对吧？哦，你应该使用 X。你为什么使用 Y？

我认为你已经指出了几乎所有事情的关键论点。如果你是在维护它的人，你是构建它的人，并且你是了解 Swift 的人（在这种情况下），

无论你选择什么，都没有错误的答案。我只是想跳进去并指出这一点，因为我相信它会出现的，对吧？互联网上有一些人。但我认为这是对许多事情的完美答案，至于为什么根本要使用这个。所以感谢你们提出这一点，各位。你用你舒服的东西。就这么简单。不要听别人的。

大家好！我想告诉你们 MacPort 的 CleanMyMac。我已经使用它很多年了。这么多年，我都记不清了。但是，如果你是一个 Mac 用户，并且你没有这个工具，相信我，你需要它。所以让我告诉你你可以用它做什么。

现在，当我打开应用程序时，不仅 UI 非常漂亮，而且我运行 SmartCare，我只需要打开应用程序，点击 SmartCare，然后点击扫描按钮。现在，当我这样做时……

将会发生什么，它将分析我的系统，它将检查并查找垃圾文件，它将检查以确保我的 Mac 上没有任何恶意软件之类的东西，它将运行一些性能检查，它将检查应用程序更新，然后它还将让我查看我所说的机器上的杂乱文件，我的文件，我放在那里的东西

我可不是在开玩笑。每次我运行它，我至少每周运行一次，它都会找到至少几 GB 的垃圾文件需要清理。

我只需要告诉它，继续运行，它就会清理垃圾文件。前几天我运行它时，它找到了 6 GB 的文件。相信我，我非常细致地将垃圾文件从我的机器上清除。它只会找到这些散布在不同文件夹中的东西。

然后它会运行性能检查，就像我说的那样。它会查看并查看它认为需要做的事情。它会让我知道任何应用程序更新。我可以让它为我更新它们。最重要的是，还有其他选项卡。有一个清理选项卡。它会进入那里。你可以告诉它为你执行各种清理操作。同样，它将运行分析。

作为开发人员，我们都知道 Xcode 占用了多少空间，但是你会惊讶于随着时间的推移积累的文件和缓存的数量，你根本不会想到。而且，你知道，它们不会很好地自行清理。同样，它，

它会进入那里并为我节省几 GB 的空间。这绝对令人难以置信。性能选项卡很棒。它会为我运行诸如刷新 DNS 之类的事情，它会运行维护脚本。它会检查磁盘权限是否存在问题，以及所有这些事情，以充分发挥你的机器的性能。如果所有这些听起来对你来说都不错，如果你是 Mac 用户，就像我说的那样，我认为这是我的第一个安装程序之一。

你可以访问 peterwhedham.com/cmm，这将带你到正确的位置，你可以在那里试用 CleanMyMac。你将获得七天的免费试用。就像我说的那样，每次他们发布新版本时，我都会立即升级。所以再次访问 peterwhedham.com/cmm 并立即开始使用 CleanMyMac。

是的。所以我将给出一些个人偏好的原因。但是，再次声明，我并没有在这里宣传 Swift 是进行 Web 后端服务的最佳方法，因为答案是没有最佳方法。这一切都取决于优缺点以及所有这些。

最终，你必须使用你或你的团队或你的公司感到舒适的东西，以及你为此所做的事情与使用不同语言相比的权衡。

所以我将告诉你我喜欢服务器端 Swift 的原因。但是，再次声明，有很多不同的项目，你可以做很多不同的事情。最终，这将取决于你自己的计算，即你实际使用什么。

我喜欢服务器端 Swift 与其他一些更流行的服务器端后端语言相比的一件事是编译器的存在。我们有很多 Web 工具是解释型工具，无论是 JavaScript 还是 Python，

也有一些语言是预先编译的。所以你有了 Rust，这显然是当今最热门的新事物。而 Golang 稍微多一点，它不像 Rust 那样新兴，但它肯定也在那里。另一个非常类似的项目。拥有编译器可以提高性能。

因为所有内容都是提前编译的。它不是被解释的。它允许你捕获代码库中较早的一些内容。因此，你实际上不必运行所有代码。你不需要编写大量测试只是为了确保像，哦，这个变量实际上不存在这样的简单事情。你可以免费获得很多这样的东西。还有安全性。是的。所以我喜欢……

编译语言的优点。而且，就像我说的那样，你还可以使用许多编译语言。这只是我喜欢 Swift 的一件事。显然，有了它，你可以获得 Swift 编译器的所有好处，以及 Swift 6 中的所有类型安全性和所有新的

并发安全功能，诸如此类，Swift 编译器可以帮助你完成客户端代码的所有事情，它也可以帮助你完成服务器端代码。编译器，这就是我最喜欢的东西。

我知道很多人会考虑到的另一件事，而且我还没有发现它像你预先想象的那样有用，但这仍然值得一提，那就是跨代码库共享代码的有限潜力。我在我的工具中发现了一些可能性。你可以创建只是常规原始 Swift 包的 Swift 包，并在两个服务之间共享它们。我会说，有了它，

你可以获得你可以实际共享代码的滑动标尺。所以模型，如果你只有一个具有可编码一致性的结构体，那么它很容易共享。你只需要一个完整的库，其中所有内容都符合可编码。它在服务器和客户端上的工作方式完全相同。直接在这两个地方使用该代码。你的业务逻辑。所以在 MVC 世界中，这将是你的控制器，或者在 MVVM 世界中，这将是你的视图模型。

这些取决于你如何紧密地与系统耦合，但是那里有一些。我有一个 SVG，嗯，我的服务器有一个图像渲染部分，它在服务器和客户端上运行，并且我让它基本上运行到一个中间服务器。

例如，这就是图像中表示的内容。从那里，我将它分成服务器和客户端。但这确实让我

走了一段相当长的路。我可以在这两个库之间共享这一点。然后显然是图像渲染的最终结果。那是你的视图。这就是正在显示的内容。不会发生这种情况。在 SwiftUI 和服务器端的 Swift 之间，代码的共享并不多。视图方面。所以是的，就像我说的那样，模型，超级简单的业务逻辑。然后是视图，这不会发生。这对于许多这类情况都是正确的，

共享代码。例如，如果你在共享 Rust 项目的代码，我觉得很多类似的事情都会发生。一个对比将是 JavaScript。你拥有服务器端渲染与客户端渲染。你可以实际共享很多这些代码，具体取决于你使用的框架。例如，如果你使用的是 React，我知道你可以完全在两者之间共享 Vue 代码。但是很多项目将更类似于 Swift 的做法，其中

是的，它是后端类型的东西，很容易在这两者之间共享。是的，我的意思是，你在 Swift 环境中，对吧？因此，自然地，你将使用我们习惯在 Swift 中使用的许多技术、技能和不同的架构方式，它将应用在这里，对吧？所以就像你说的那样，我认为公平地说，有些事情……

并不能像其他语言那样很好地转换为服务器端。但我认为这是设计使然。对我来说，当我想到服务器端的 Swift 时，我的大脑会首先想到 API。

是的，所以我认为你在这里指出了某些东西，那就是，如果你不在 Swift 生态系统中，那么在服务器上使用 Swift 是否有意义？我会说有一些好处，它们与你从 Swift 编译器整体获得的好处相同。但最终，我不知道我会……

如果我不在其他任何地方使用 Swift，我不会选择服务器端的 Swift 作为我的默认选项，它更像是，嘿，我熟悉这种语言，我知道这种语言的来龙去脉，我知道一些怪癖和奇特之处，所以我比 Rust 更舒服，我对 Rust 几乎一无所知，我不会仅仅为了在我的服务器上使用它而学习整个语言，而且

我认为，如果我不是一个已经熟悉 Swift 的人，我不知道我是否会对服务器端的 Swift 做同样的事情。我不会仅仅为了服务器类型的东西而学习 Swift。我同意这一点。我还想补充一点，因为我们经常被问到这个问题。如果你是一个这样的人，嘿，我对 Swift 一无所知，我想学习 Swift。我不会从服务器端的 Swift 开始。

作为进入学习 Swift 的途径。我建议你先从构建客户端应用程序开始，学习这些技术。我这么说是有原因的，是的，无论你做什么，

你都在学习 Swift。毫无疑问。但我认为你可以从客户端学习一些规则和某些做事方式。但我不知道，你可能不同意。

你确实在服务器端的 Swift 中获得了一个你在应用程序中没有的好处，那就是你可以在没有 Mac 的情况下开始学习服务器端的 Swift。这确实是能够构建例如 iOS 或 Mac 应用程序的一个限制。

话虽如此，我仍然建议，即使这是你试图学习的一部分，我仍然建议从命令行工具开始，一些简单的东西。你知道，我正在生成一堆文本，或者我正在发出 API 请求。我正在用它做其他事情。我会从那里开始，而不是直接跳到服务器端的 Swift。

即使你想要开始构建 Swift 并学习 Swift 而无需 Mac，你也可以进入……

在 Linux 上使用 Swift 进行许多其他很酷的事情，然后在你更熟悉这门语言之后，再在服务器上构建它。然后，是的，如果你最终显然想要进入 iOS 应用程序或 Mac 应用程序，你将需要一台 Mac 才能在其上进行开发。但我认为，是的，有一些方法可以在 Linux 上开始使用 Swift，而不仅仅是直接运行 Web 服务器。是的。

对。好的，公平的观点。是的。好的。是的，各位，我不是说要跑出去买一台 Mac。只是那样开始学习 Swift。实际上，当我们开始设置这个东西时，我们会更多地谈到这一点。但是既然你已经提到了，需要注意的一件关键事情是……

是的，对吧？你可以在 Linux 上运行它，对吧？事实上，可以说是服务器端最好的方法之一。你知道，那里总有一些人惊讶地发现 Swift 不仅仅是……

一种基于 Apple 操作系统的语言，是的，你可以在 Windows 上运行它，当然你也可以在 Linux 上运行它，我同意你的说法，例如，Swift 脚本，嘿，这是从终端进入它的好方法，对吧，你绝对不需要 Mac 来做到这一点，是的

所以，是的，Peter，你想谈谈服务器端 Swift 项目有哪些选择吗？我知道那里有两个大型项目。你已经提到了它们。你想谈谈它们之间的区别吗？是的，当然。所以我认为，你知道，肯定最著名的两个是 Vapor 和 Hummingbird。

我试图回忆一下，我不认为我做过关于 Vapor 的节目，但我们肯定之前与一些 Swift 服务器组一起讨论过 Hummingbird。Vapor 是存在时间，我将说这两个项目中时间最长的一个，我稍后会解释原因。

因此，这两个项目都有良好的社区。可以说，Vapor 拥有更大的社区，对于这些事情来说，这始终很重要，因为它存在的时间更长，而且它肯定是最著名的，尽管我认为这种情况正在改变。它绝对是一种非常有主见、非常结构化的做事方式。我会说，对于 Vapor，

你的方法将按照他们想要的方式进行。就是这样。

我不是说这是一件坏事，但你肯定必须遵守规则。它肯定为你提供了更多可以构建的结构。我认为这是很好的说法，那就是它非常有主见，就像你说的那样，但是强烈的观点意味着约束，约束在某种意义上使构建变得容易。所以，是的，既是优势也是劣势，因为它更有主见。

是的，绝对的。Vapor，我会说，更容易上手。就像我说的那样，它拥有，显然，因为它存在的时间更长，所以那里有大量的文档。我认为，几乎任何

你认为你可能想要构建的应用程序样式，我敢打赌那里都有一个代码示例。据我所知，Vapor 是一个，取决于你想要如何操作，你可以直接在本地运行它。我们将讨论安装过程。但是你可以在你的机器或服务器上安装它，

当然还有其他选项，你知道，如果我没记错的话，有一些预构建的 Docker 镜像，你可以直接启动并运行，嘿，就这样，对吧？所以你也有这些选项，以及不同的，你知道，自定义方式。但是你会发现很多关于这方面的信息。现在，谈谈 Hummingbird，Hummingbird 现在是 2.0 版本了。它是 Hummingbird……

据我记得与 Giannis 的谈话，你知道，Hummingbird 非常受 Vapor 的启发。事实上，我知道根据他的说法，这两个团队紧密合作，对吧？这不像他们在竞争。他们互相借鉴和学习。所以，你知道，无论你选择哪个，你肯定都会进入一个生态系统。就像很多事情一样，我会快速提到这一点，在 Swift 方面，

这里没有竞争。双方都愿意看到这两个项目都成功，因为它们彼此受益，对吧？但是 Hummingbird 拥有，在我看来，非常好的文档，对入门有很好的解释和演练。现在，我会说你绝对应该……

至少对 Swift 有基本的了解。我的意思是，你不需要任何花哨的东西，对吧？但是你会很快看到这两个项目中有很多代码。慢慢来。但是 Hummingbird 有一个很棒的教程系列。有一些例子。他们确实，你知道，经典的待办事项示例，嘿，至少你正在做一个我们都熟悉的应用程序，对吧？它就像 hello world 的升级版。Hummingbird，

Hummingbird 2.0 版本支持并实际上大量借鉴了 Swift 并发。例如 Swift 6，并发是当今的热门词。是的，我知道它已经存在一段时间了，但他们肯定从中汲取了很多灵感。

所以你也可以获得 Swift 最新版本的所有好功能。但这主要就是它们的区别。现在，在我看来，这两个项目都非常好。

就像我说的那样，我们将讨论，我们已经讨论过 Hummingbird，因为这是我们关注的重点。但是你将在这两个项目中获得良好的体验。但是 Jeff，你还有什么想补充的吗？没有，就像你说的那样，它们在作为 Swift Web 服务器方面都非常出色。这真的有点……

这确实取决于你喜欢 Vapor 那种更注重结构的范例，还是更喜欢 Hummingbird 那种自建架构风格的设计。这两个项目都有自己的粉丝群体。所以它们都运行良好。这两个工具基于类似的框架，这也是它们很棒的另一个原因。

有很多库，很多库都能同时使用这两个框架。它们都可以通过相同的ORM Fluent与这些数据库进行通信，并且它们与这些数据库通信的方式非常相似。它们都有自己的HTML模板库。Vapor有自己更Swifty类型的库。Hummingbird有一个基于更开放标准的库，叫做Mustache。它们都有自己的身份验证库。

您可以使用这两个框架的各种库，这些库通常是为Swift构建的。我知道有一些像MongoDB这样的库，您可以直接与这两个框架一起使用，它对两者都没有偏好。所以，这两个社区合作得很好。我认为这对两者来说都是一件好事。我很高兴看到有两个充满活力的生态系统在那里构建

服务器端Swift的工具，好了，这就是我每天都离不开的东西，那就是我的咖啡。任何认识我的人，或者任何听过我的播客或其他任何东西的人都知道，我绝对离不开我的咖啡，而且我喜欢好咖啡。

所以，事情是这样的。我会送你一包免费的咖啡，方法是访问peterwhitam.com/coffee。那里有一家很棒的公司，遵循公平贸易原则，帮助许多各种规模的独立烘焙商，而且操作很简单。你要做的就是访问peterwhitam.com/coffee。你在那里注册。你会收到一包免费的咖啡，是的，作为回报，并且

他们通过送我一些咖啡来感谢我。但这不是我这么做的原因。我这么做是因为我发现了很多好咖啡，如果没有这项服务，我永远不会遇到、听说过或体验过这些咖啡。Trade Coffee真是太棒了。你知道，有很多地方，我们都认识它们，供应咖啡，好咖啡。

你可以去商店买咖啡，但是没有什么比发现新的独立烘焙商并支持他们，发现新的咖啡口味，新的研磨方式更好的了，你可以设置它。它非常智能。你告诉它你喜欢哪种咖啡。随着时间的推移，它会越来越好，因为它会根据你的选择进行训练，并为你提供你想要的咖啡，并推荐一些非常相似的咖啡。

每次我收到一包新的咖啡，我都会试一下咖啡。我浏览服务，我说，看，我喜欢这种咖啡。我认为这种咖啡还可以。或者我说，看，这真的不适合我。每次我这样做，都会使服务的下次选择对我来说更准确一些。

所以，再次访问peterwhitam.com/coffee。今天就领取你的免费咖啡吧。如果你是一个咖啡爱好者，你一定会喜欢这项服务的。我已经使用这项服务多年了，并且强烈推荐它。

例如，Hummingbird，如果你访问网站，当然我们会在节目说明中添加链接，但是hummingbird.codes，有一个生态系统标签，他们在那里列出了很多他们拥有的官方扩展。举几个例子，对吧？其中一些应该很熟悉，但也应该让你感到舒服。所以，WebSockets，Redis，都在那里。就像你提到的，有一个Fluent ORM扩展。

它涵盖了许多数据库。我认为，在我看来，所有你可能想要使用或在生产中遇到的常见数据库都在其中。还有一些我们稍后会讨论的。但是那里有很多支持，当然还有软件包。是的，Vapor上也有。

我特别在Hummingbird上提到它，因为我认为他们在突出许多关键领域方面做得很好。对于任何有Web开发背景的人来说，你很快就会感到舒服。好的，让我们谈谈如何安装和设置这些。我们将在这里跳进去。再说一次，我们将对两者进行比较。我们不会偏袒任何一方。我们只是想让你体验一下设置这两个框架是什么感觉。所以，Jeff，开始吧。

是的，我认为这两个框架的安装过程……

非常符合它们的整体理念。所以，是的，我们将把它描述为。Vapor有一个命令行工具。它字面意思上就叫做vapor，你可以在Mac OS上安装这个工具。人们会对此很熟悉。在Linux上，它只是brew install vapor。如果你在Linux上构建，你实际上必须从源代码构建它，但这似乎很简单。你只需要检出并运行make install。就是这样，

如果你在Linux上运行，并且不想处理make install的东西，你也可以使用Docker镜像，你只需要下载这个Docker镜像。你可以在Docker开发容器内开始构建，它已经安装了vapor。这是另一个选择。它在Linux上运行，无论你是在macOS还是Linux上运行Docker主机，这都是另一个选择，让它完全独立。

从那里，你安装了你的工具，你可以运行Vapor New。这将引导你完成这个命令行向导工具。它会问你，你想给它起什么名字？你在构建什么？你需要数据库连接吗？你需要HTML模板吗？你需要所有这些东西吗？它会为你生成一个项目，安装合适的库，并给你一个项目文件夹，你可以继续使用它。

它已经内置了所有结构，它会告诉你，哦，你将在这里添加你的控制器。你将在这里做任何事情，并为你准备了一个完整的项目。另一方面，Hummingbird只是一个简单的库，你必须自己创建你自己的Swift包项目，就像你创建任何其他Swift项目一样。然后你只需要将你需要的Hummingbird库添加到现有的项目中。

或者，他们确实有一个Git项目模板，你可以下载这个项目模板并从那里开始。但是，Hummingbird非常简单，你只需要按照你想要的方式创建你的Swift包项目，然后添加你需要的库。你就可以开始使用Hummingbird项目了。是的，我的意思是，绝对像这样，你知道，Swift包管理器，希望到现在为止，呃，

我们对它都感到相当满意。显然，使用较新版本的Xcode，也更容易管理。我认为当我这样做的时候，如果我没记错的话，我下载了模板。是的。

我认为Vapor可能首先早于Xcode更好地处理Swift包管理器。此外，Vapor还有更多用于处理许多较小的特定内容的单个库。因此，在那里拥有该工具对于确保你拥有所有需要的库更有帮助。这就是为什么Vapor有这个工具，而Hummingbird更像是随心所欲，分叉它，获取它，做你的项目，项目构建。是的。

是的，这确实取决于你想要哪种方式，对吧？无论你更喜欢哪一个，作为用户开发者，你为自己做决定，或者，如果你是一个团队，你可以与你的团队讨论这些决定。当然。是的。我认为，当你到达这个安装阶段时，你可能已经对你想使用哪个框架做出了相当好的评估。但是，如果你有时间，嘿，尝试一下两者，对吧？是的。

是的，绝对的。我知道。是的，我的意思是，这取决于，再次了解它们的理念，以及了解你想要两者中的哪一个。然后，当你准备好部署这两个框架时，它们都非常相似，呃，点击构建并运行，你就会得到一个构建的可执行文件，你可以直接在服务器上运行这个可执行文件。如果你想，呃，你需要安装各种Swift支持的东西，但是，

网上有关于如何做到这一点以及如何安装Swift的答案。但我发现更有用的版本是，两者都包含你可以用来构建Docker镜像的官方Docker文件，然后将其托管在任何支持Docker的地方，现在基本上到处都是。所以我用自己的部署就是这样做的，我只是运行一个Docker构建，构建Docker所需的标志。

基于Intel的系统，基于AMD 64的系统，而不是每个人都在Mac上开发的ARM系统。但除此之外，你知道，你构建一个AMD 64镜像，你把它放在你的服务器上，你像运行任何普通的Docker镜像一样运行它。它就能工作。

我认为这很重要，因为对我来说，你知道，我的大脑会转换模式，我开始非常关注安全性。对。所以，是的，我也喜欢Docker的想法。对我来说，现在，好吧，我明白了，伙计们。

我们总是说，要理解你的代码在做什么。但对我来说，我觉得运行Docker镜像更舒服，希望比我聪明得多的人已经涵盖了安全性和良好的安全检查等方面。因为对我来说，我想继续进行应用程序的开发，而不是成为服务器管理员，对吧？我不是说你需要成为服务器管理员才能运行这两个框架。我只是说，为什么要给自己带来痛苦和麻烦呢？使用Docker镜像的另一个优点是，嘿，在你将其发布到生产环境之前，在本地运行它非常容易，并且在那时应该有一个可预测的体验，对吧？是的。

然后还有一点值得一提的是，我认为这是一个在部署领域中提出的可靠问题，Hummingbird比Vapor多拥有的一个功能实际上可能……

推动你朝一个或另一个方向发展，Hummingbird确实支持作为无服务器系统在AWS Lambda上运行。在本录音发布时，似乎并没有，甚至没有半官方的支持来使用Vapor做到这一点。呃，Hummingbird的启动速度比Hummingbird快得多，或者说，对不起，

Hummingbird的启动速度比Vapor快得多。所以我认为它更适合在无服务器系统中运行。所以，是的，他们确实有一个官方扩展，用于在Lambda上运行Hummingbird，而Vapor上则没有。所以这是另一个部署服务的选项。是的。我认为……

我的意思是，这几乎涵盖了所有内容。我只想在这里向听众们指出一些我们没有涵盖的领域，也就是中间地带，对吧，那么，我该如何构建我的应用程序呢？我们故意决定不

在那里深入探讨，因为归根结底，答案是，好吧，它是Swift。你像使用Swift一样构建它，对吧？我们不想，比如，你知道，这就像，这就是你如何做你已经知道如何做的事情。再说一次，如果你不知道如何做，你知道，嘿，这可以成为Swift的一个很好的入门。但在两者之间，你的应用程序的所有中间件基本上都是Swift

戴上你的Swift帽子，然后开始吧，对吧？绝对的，是的。你做的很多事情都是接收和返回可编码属性。所以，如果你运行的是像API这样的东西，你将接收一个可编码模型。这是你的请求。你将吐出一个响应。它可能也是一个可编码模型。每个框架都有处理以下方面的方法：

你想返回不同的标题，或者你想根据标题返回不同的响应，返回不同的状态代码，诸如此类的事情。两者在处理这些方面都非常直接。所以两者之间没有太大的区别。

好的，我认为我们已经涵盖了这里的话题。不知道。嘿，你知道，也许将来会有更多剧集，我们会深入探讨一些特定的事情，特定方面或代码讨论。但这就是你在服务器上使用Swift启动和运行的方式。当然，我认为这值得你花时间去看看。除此之外，伙计们，我们已经涵盖了这里的内容。Jeff，最后的感想，我们可以在哪里找到你？