我又新写了一款 Swift 服务端框架，这次是基于 Vapor 4
2023-07-03 00:42
767
13
3
引言
我在四年前发过一篇博客：「回首三年Swift后端之旅，今年我用Swift写前端了」。在这篇文章中，我介绍了当时我最新写的 Swift 后端框架和前端框架。
已经有几年没有更新博客的技术栈了，今天我会在这篇文章里做一点更新。
回顾一下过去
1.0 时代
2016 年，这是一个相当蛮荒的时代。
当时 Swift 刚刚开源不久，在 Linux 上运行可谓是遍地是坑。我当时使用的框架是Perfect，这是个相当“渐进式”的框架，使用了大量 C 接口来让整个框架可以跑起来。
由于整个项目是出于探索 Swift for Linux 的意图，在网页方面我用非常原始地用 Bootstrap / JQuery 简单写了一个就匆匆上线跑着了。
当年甚至还别出心裁地做了个线上可以跑代码的平台：
2.0 时代
2017 年，我的北京元年，我来到了北京加入了百度。
我在前一份工作中接触了 Python 著名后端框架Django。我基于Django的业务抽象，在Perfect提供的能力上搭了一个有业务能力的框架出来，取名为Pjango。
之后我也在这个框架的基础上重写了网页，并一起上线了重写后的新博客。
3.0 时代
2019 年，旧世界末年（指新冠前）。
Pjango虽然拥有了一定的业务抽象，但过分参考了 Python 的设计，在诸如环境变量等等许多写法上非常不 Swifty，于是这一年我开启了新的计划：Project Virgo。
在这个计划中我重新设计了前后端，两个项目分别为：Heze（后端） 和SPiCa（前端）
这篇博客：「回首三年Swift后端之旅，今年我用Swift写前端了」就是在发布这个项目之后写的。
小知识：
这个计划的命名灵感来自于初音未来的《SPiCa》，于是我找到了一些相关的内容来组成这个项目的名称。在“关于”页面里的头像用的也就是这首歌的图。
Virgo：室女座。选择个星座是因为 SPiCa 属于这个星座。
SPiCa：室女座 α 星，角宿一，是室女座的最亮星。
Heze：室女座 ζ 星，角宿二。
这个项目极具创意：
- Heze 的数据库驱动能一行代码不写就把一条记录渲染成 JSON，并提供了自定义字段等等能力，以及巧妙地利用 GCD 实现了许多异步操作。
- SPiCa 则是作为代码生成器，网页端的 Vue 代码是由她的 Swift 代码生成的。截止到这篇文章发布位置，读者你看到的网页仍然是
SPiCa生成的。
然后呢？
Heze虽然拥有一些相对先进的能力，但是地基依然是 Perfect。而很不幸的是，这个项目已经没有人维护了。
在那个年代，Swift 在 Linux 和 macOS 上仍然由许多不同的行为。Swift 近几年 Feature 井喷，随着版本迭代，代码甚至出现了编译问题，我不得不维护了两个分支：
- Linux 分支：仍然停留在 Swift 4.2。
- macOS 分支：支持到最新 Swift / Xcode。
我曾经好几次想把 Swift 版本 bump 上去，都失败了。
随着async/await等 Feature 在 Swift 新版本上出现，我们可能需要考虑使用新的异步 API 来实现了。可能真的是时候让 Perfect 退出了。
回到现在
2022 年底，我开始了新的计划：Helios。
这个计划会重写整个服务端框架，使用最新的 Vapor 4 以及最新的 Swift 版本进行开发。完全切到异步 API 上。
Vapor 4 的数据库驱动能够使用KeyPath写出结构化的 SQL 查询语句和 Model 查询方法，还是挺炫酷的。
小剧场：
这个命名灵感来自于米哈游《崩坏3》的早期（2016 年）的开局 PV。这个 PV 现在已经没有了，但能在视频网站上搜到别人的录像。
剧情是琪亚娜从空中跳下着陆在 Helios 号运输舰上。嗯，没别的，就只是喜欢 Helios 这个名字罢了。
那么现在就来具体看一下 Helios 的设计。
路由
路由的设计基本照抄了Heze的设计，用Path: Method: Handler的层级来分发路由。
func routes(app: HeliosApp) -> [String : [HTTPMethod : HeliosHandlerBuilder]] {
return [
// Posts list
"/api/posts/list": [
.GET: PostsListApi.builder,
],
]
}
Swift
一个简单的查库 + 渲染的 API：
import Foundation
import Vapor
import Helios
class PostsListApi: HeliosHandler {
required init() { }
func handle(req: Request) async throws -> AsyncResponseEncodable {
let postsList = try await PostsInfoModel.query(on: req.db)
.sort(\PostsInfoModel.$date, .descending)
.all()
for posts in postsList {
try await posts.preRender(db: req.db)
}
return jsonResponse(data: postsList.map { $0.render() })
}
}
Swift
在 Vapor 4 的数据库驱动中，where, on, order等操作都可以用KeyPath来操作，以写出非常 Swifty 的结构化代码。
在 Vapor 4 中，为了返回符合AsyncResponseEncodable协议的对象进行渲染，需要通过额外定义遵循Content协议的结构来实现。这里引入了一些学习成本，我就直接放代码了：
struct HeliosHandlerResponse<T: Content>: Codable, Content {
let success: Bool
let msg: String
let data: T
}
extension HeliosHandler {
func jsonResponse<T: Content>(data: T) -> AsyncResponseEncodable {
let response = HeliosHandlerResponse(
success: true,
msg: "nil",
data: data)
return response
}
}
Swift
数据库
Vapor 的数据库驱动还是非常全的。
Heze的数据库驱动是我自己写的，我甚至连事务都懒得实现，但在 Vapor 里这些都是现成的。
模型的注册也是照抄了Heze的设计。
func models(app: HeliosApp) -> [HeliosAnyModelBuilder] {
return [
// ...
PostsInfoModel.builder,
// ...
]
}
Swift
模型的定义需要遵循 Vapor 的定义，因此没有太多的操作空间。
class PostsInfoModel: HeliosModel {
public static let schema = "Posts"
@ID(custom: "id")
public var id: String?
@Field(key: "PID")
public var pid: Int
@Field(key: "TITLE")
public var title: String
// ......
required public init() { }
}
Swift
有一个非常有意思的设计：我把 Vapor 的Migration结合到了HeliosModel的协议中，把这俩写在一块儿，使框架能够自动建表。方法大概长这样：
public func creator(database: Database) -> SchemaBuilder {
database.schema(Self.schema)
.field(.id, .string, .identifier(auto: false))
.field(_pid.key, .int, .required)
.field(_title.key, .string, .required)
// ......
}
Swift
最后是渲染部分。刚刚提到我们需要有遵守Content协议的结构来承接AsyncResponseEncodable协议。
extension PostsInfoModel {
public func render() -> PostsInfo {
return PostsInfo(model: self)
}
}
struct PostsInfo: Codable, Content {
let PID: Int
let TITLE: String
// ...
init(model: PostsInfoModel) {
PID = model.pid
TITLE = model.title
// ...
}
}
Swift
这个结构也直接承载和客户端交互的任务，所以这一层也不是完全多余的，可以做一些额外的工作，比如计算一些自定义字段。
插件系统
Vapor 本身提供了Middleware中间件系统，Helios在Heze的基础上，也抽象出了Filter，Timer等等插件，注册的时候大概是这样：
func filters(app: HeliosApp) -> [HeliosFilterBuilder] {
return [
AccessFilter.builder,
// ...
]
}
func timers(app: HeliosApp) -> [HeliosTimerBuilder] {
return [
ActivityPlugin.builder,
// ...
]
}
Swift
作为Filter，它的活自然是过滤 Request 和 Response，做一些添油加醋的工作。这个协议的定义大概长这样：
public protocol HeliosFilter: AsyncMiddleware {
init()
func filterRequest(request: Request) async throws -> Response?
func filterResponse(request: Request, response: Response) async throws -> Response
}
Swift
至于Timer，则是有schedule和run两个事件。以下是一个真实的 Timer 的实现：
class ActivityPlugin: HeliosTimer {
func schedule(queue: Application.Queues) {
queue.schedule(self)
.minutely()
.at(0)
}
func run(context: QueueContext) async throws {
try await ActivityCenter.shared.updateCache()
}
required init() { }
}
Swift
视图
视图的设计也参考了Heze。整个协议大概长这样：
public protocol HeliosView: HeliosHandler {
func template(req: Request) async throws -> String
func canHandle(req: Request) async throws -> Bool
func render(req: Request) async throws -> Codable?
}
Swift
从SPiCa开始，我的网页都是Single-page Application，因此对爬虫和 SEO 是极不友好的。我在 2020 年单独做了一套 SSR（服务端渲染）的页面给爬虫们玩儿。因此就会有个类似 Proxy 的设计，大概长这样：
func template(req: Request) async throws -> String {
return isSpider(req: req)
? try await spiderView.template(req: req)
: try await userView.template(req: req)
}
func canHandle(req: Request) async throws -> Bool {
return isSpider(req: req)
? try await spiderView.canHandle(req: req)
: try await userView.canHandle(req: req)
}
func render(req: Request) async throws -> Codable? {
triggerSession(req: req)
return isSpider(req: req)
? try await spiderView.render(req: req)
: try await userView.render(req: req)
}
Swift
有一点不同的是，Vapor 自带的 HTML 渲染器是 Leaf 的，所以我也一并修改了模板的占位符。
小结
我于 2022 年底启动这个计划，其实早就把Helios实现完了，但一直没有把博客迁过去。最近由于一些众所周知的原因也终于有时间来做这个事情了。至于这件事，我会在后面再写一篇文章说。
在做完这些后，我算是拥有了一个真正基于异步 API 的 Swift 服务端框架。同时，它也将会比较容易地迁到更新的 Swift 的版本上以获得新的能力。我也彻底摆脱了 Perfect 的魔咒。它无法升级 Swift 版本的痛苦伴随着我已经很久了。
目前这个项目处于闭源状态，其原因有二：
- 项目相对稚嫩，我不鼓励大家使用，以免遭受损失。
- 我也不希望大家走这个方向，有许多更好的选择。
说到底这只不过是我的一个玩具罢了。
最近我也在做我的 Home Server 计划。所有的服务将会部署在家里的机器上，并由云服务器穿回来以提供服务。
期望的是把所有资源丢到 CDN 后，本地只提供 API 服务。这样能够最大程度压缩成本。
结语 / 未来呢？
老实说我不知道。
这已经是我做 Swift 服务端的第七年了，Swift 服务端依旧冷门。但随着近几年的异步 API 开放，以及官方的 Swift NIO 的支持，事情似乎在往好的方向发展。
本次更新我下掉了许多原本博客的功能，比如邮件订阅，数据后台等等。我逐渐发现我并不需要这些东西。
我们每天的工作里有太多数据相关的事情，使得我们好像不冲着数据就不会做事了一样。
只看数据的世界太无趣了，我需要有一篇自留地，这里和任何数据无关，我想做啥就做啥。
https://blog.yuusann.com/posts/article/23001?continueFlag=80bb619576e267512bef940817a9cc9b