与2.0相比，完美，或像Django这样的Python franeworks。如果可用于小规模项目以外的任何事情
答案 0 :(得分：16)
我假设你的问题如下：
Vapor 3的架构变化对性能和大型项目意味着什么？
我会在讨论中将特定的硬编号留给其他框架。
Vapor 3是一个专为未来而设计的框架。它具有极高的性能，内存使用量轻，可扩展，并具有大量官方支持的功能集。
虽然这些不是硬数字，但我的笔记本电脑以每秒103k的明文请求量度HTTP Engine。
由于默认中间件（服务和内容系统）的开销，Vapor framework略低。它仍然真正具有80k请求/秒的明文吞吐量。
启动时Vapor 3的内存开销在我的测试中介于6.4MB和7.5MB之间。这与我测试的Go框架一致。
Vapor 3的主要架构差异在这里是关键。我们在自己的Async library上工作，受到来自Java生态系统的reactive-streams.org的启发。我们的流模型是一个拉流模型，其中数据不会强制在另一个库上，但是库在准备好时会请求更多数据。因为这适用于整个生态系统，所以无论请求的大小如何，内存使用率都会保持很低。此规则的少数例外是（多部分）表单，JSON和模板。模板化是我们将来能够应用适当反应性的唯一库。
除了Web框架中的反应性，我们还构建了自己的ORM, Fluent.
Fluent默认支持SQLite，但也有MySQL，PostgreSQL和MongoDB through MongoKitten的驱动程序。
除了这些驱动程序，我们还获得了对Redis的支持。
以上所有驱动程序都支持反应流和Codable。驱动程序是用Swift编写的，下面没有C库，并且针对减少的内存副本进行了高度优化。
由于我们构建并维护了上述整个生态系统，因此我们能够在性能和API方面实现比大多数其他框架更深层次的集成。但是，这确实会对我们工作量的大小产生重大影响。
我们决定将大部分API内部化，直到明确要求公开可访问的功能为止。这样做是为了确保我们实现的chages不会导致重大更改。
我无法做出判断。我是Vapor 3核心团队的成员。但是，我们有一个活跃的社区，能够告诉你他们到目前为止使用Vapor 3的经历。我们还处于测试阶段，因此我暂时不会发布该产品。