基于 actix-web + async-graphql + rbatis + postgresql / mysql 构建异步 Rust GraphQL 服务(1) - 起步及 crate 选择

前段时间,笔者写了一个构建 Rust 异步 GraphQL 服务的系列博文,构建 Rust 异步 GraphQL 服务:基于 tide + async-graphql + mongodb,采用的 Rust web 框架是 Tide

感兴趣的朋友阅读以后,对 actix-web 更感兴趣。有几十位朋友建议笔者写个 actix-web + async-graphql 构建 GraphQL 服务的系列。看样子 Rust 的国内社区,虽然使用 Rust 的公司可能很少,但至少感兴趣的程序员基本面不小了。

因此本系列文章,笔者以 actix-web + async-graphql + rbatis + postgresql / mysql 技术栈为骨架,简单进行 GraphQL 服务构建的实践。actix-web 是极为优秀的 Rust web 框架,笔者在 2018-2019 年间,GraphQL 服务后端,也一直使用的是 actix-web + juniper + postgresql 的组合。

但目前工作场景,还是 mysql 居多,所以本系列实践,我们采用 mysql 数据库。但这次实践采用了 orm 框架 rbatis,所以对于 postgresql 的支持,会很方便。在系列文章最后,我们增加很少量的代码,即可支持 postgresql。并且,我们将一并实现 GraphQL 服务的多数据源支持。

tide + async-graphql + mongodb 系列类似,我们需要做到前后端分离。

  1. 后端:主要提供 GraphQL 服务,使用到的 crate 包括:actix-webasync-graphql、jsonwebtoken、rbatis、serde、ring、base64 等。
  2. 前端(handlebars-rust):主要提供 WEB 应用服务,使用到 crate 包括:actix-webrhai、surf、graphql_client、handlebars-rust、cookie 等。
  3. 前端(WebAssembly ):主要提供 WEB 应用服务,笔者实际项目中,和伙伴们还处于尝试初期。后面写到这部分时,我们再确定使用的技术栈。如果您对于 wasm 的使用已经熟悉,欢迎您的指导。

Rust 环境的配置,cargo 工具的使用,以及 Rust 程序设计语言和 GraphQL 的介绍和优势,在此不在赘述。您可以参阅如下资料学习 Rust 程序设计语言,以及 Rust 生态中的 GraphQL 实现。

以下建议了解,技术选型很丰富,我们不必拘泥。

  • Tide,Rust 官方团队开发的 HTTP 服务器框架。推荐作为了解,本系列文章中我们选择 actix-web。
  • Juniper 中文文档,推荐作为了解,本系列文章中我们选择 async-graphql。

其它概念性、对比类的内容,请您自行搜索。

工程的创建

文章的开始提到,我们要做到前后端分离。因此,前、后端需要各自创建一个工程。同时,我们要使用 cargo 对工程进行管理和组织。

  • 首先,创新本次工程根目录和 cargo 清单文件
mkdir actix-web-async-graphql
cd ./actix-web-async-graphql

touch Cargo.toml 

Cargo.toml 文件中,填入以下内容:

[workspace]
members = [
  "./backend",
  "./frontend-handlebars",
  "./frontend-wasm",
]

resolver = "2"

[profile.dev]
split-debuginfo = "unpacked"

注1resolver = "2" 是 Rust 1.51.0 中 cargo 工具新支持的设定项,主要用于解决依赖项管理的难题。目前,Cargo 的默认行为是:在依赖关系图中,当单个包被多次引用时,合并该包的特性。而启用 resolver 后,则可避免合并包,启用所有特性。但这种新的解析特性,可能会导致一些 crate 编译不止一次。具体参阅 Rust 1.51.0 已正式发布,及其新特性详述,或者 Rust 2021 版本特性预览,以及工作计划 中的 Cargo resolver 小节。

注2[profile.dev] 是 Rust 1.51.0 中的关于“拆分调试信息”的设定,这个主要是 macOS 上的改进。

文件中,workspace 是 cargo 中的工作区。cargo 中,工作区共享公共依赖项解析(即具有共享 Cargo.lock),输出目录和各种设置,如配置文件等的一个或多个包的集合。

虚拟工作区是 Cargo.toml 清单中,根目录的工作空间,不需要定义包,只列出工作区成员即可。

上述配置中,包含 3 个成员 backendfrontend-handlebars,以及 frontend-wasm 即我们需要创建 3 个工程(请注意您处于 actix-web-async-graphql 目录中):前端和后端 —— 均为二进制程序,所以传递 --bin 参数,或省略参数。

cargo new backend --bin
cargo new frontend-handlebars --bin
cargo new frontend-wasm --bin

注4:如果你不想要产生 git 信息,或者你有自己的 git 配置,请在 cargo 命令后再加上 --vcs none 参数。

创建后,工程结构如下图所示——

工程结构

我们可以看到,因为还未编译,没有 Cargo.lock 文件;main.rs 文件也是 Cargo 产生的默认代码。

现在,这个全新的工程,已经创建完成了。

工具类 crate 安装

工程创建完成后,我们即可以进入开发环节了。开发中,一些工具类 crate 可以起到“善其事”的作用,我们需要先进行安装。

  • cargo-edit,包含 cargo addcargo rm,以及 cargo upgrade,可以让我们方便地管理 crate。
  • cargo-watch,监视项目的源代码,以了解其更改,并在源代码发生更改时,运行 Cargo 命令。

好的,我们安装这 2 个 crate。

cargo install cargo-edit
cargo install cargo-watch

安装依赖较多,如果时间较长,请配置 Rust 工具链的国内源

添加依赖 crate

接着,我们需要添加开发所需依赖项。依赖项的添加,我们不用一次性全部添加,我们根据开发需要,一步步添加。首先,从后端工程开始。

后端工程中,我们提供 GraphQL 服务,需要依赖的基本 crate 有 tide、async-std、async-graphql、mongodb,以及 bson。我们使用 cargo add 命令来安装,其将安装最新版本。

cd backend
cargo add actix-web async-graphql rbatis

安装依赖较多,如果时间较长,请配置 Cargo 国内镜像源

执行上述命令后,actix-web-async-graphql/backend/Cargo.toml 内容如下所示——

...
[dependencies]
actix-web = "3.3.2"

async-graphql = "2.8.2"
rbatis = "1.8.83"
...

Rust 生态和社区中,发展是非常迅猛的。虽然 Rust 的稳定性、安全性非常高,但活跃的社区导致 crate 的迭代版本很快。所以我们使用的都是最新版本的 crate,跟上 Rust 生态的最新潮流。

依赖项支持特性(features)

本文开始,我们已经提到:本系列,我们将以 mysql、postgresql 作为数据库进行实践。rbatis 默认为特性为 all-database,支持包括 sqlite、sqlserver 等,我们不需要,所以限定特性为 mysql、postgresql 即可。

另外,async-graphql 从 2.6.3 开始,默认不激活所有特性,所以我们本次实践,也需要做一些设定。

最终,actix-web-async-graphql/backend/Cargo.toml 内容如下所示——

...
[dependencies]
[dependencies]
actix-web = "3.3.2"

async-graphql = { version = "2.8.2", features = ["bson", "chrono"] }
rbatis = { version = "1.8.83", default-features = false, features = ["mysql", "postgres"] }
...

至此,我们构建基于 Rust 技术栈的 Graphql 服务的后端基础工程已经搭建完成。下一篇文章中,我们开始构建一个最基本的 GraphQL 服务器。

谢谢您的阅读。