前段时间，笔者写了一个构建 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 系列类似，我们需要做到前后端分离。
- 后端：主要提供 GraphQL 服务，使用到的 crate 包括：actix-web、async-graphql、jsonwebtoken、rbatis、serde、ring、base64 等。
- 前端（handlebars-rust）：主要提供 WEB 应用服务，使用到 crate 包括：actix-web、rhai、surf、graphql_client、handlebars-rust、cookie 等。
- 前端（WebAssembly ）：主要提供 WEB 应用服务，笔者实际项目中，和伙伴们还处于尝试初期。后面写到这部分时，我们再确定使用的技术栈。如果您对于 wasm 的使用已经熟悉，欢迎您的指导。
Rust 环境的配置，cargo 工具的使用，以及 Rust 程序设计语言和 GraphQL 的介绍和优势，在此不再赘述。您可以参阅如下资料学习 Rust 程序设计语言，以及 Rust 生态中的 GraphQL 实现。
- 请参阅 Windows、Linux，以及 MacOS 下安装和配置 Rust 环境，以及配置 Rust 工具链的国内源、配置 Cargo 国内镜像源。
- actix-web，Rust 社区中最活跃、成熟的 WEB 框架。
- 通过例子学 Rust，推荐。
- Rust Cookbook 中文版，推荐。
- Cargo 中文文档，推荐。
- async-graphql 中文文档
- Rust 程序设计语言
以下建议了解，技术选型很丰富，我们不必拘泥。
- 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"
注1：
resolver = "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 个成员 backend、frontend-handlebars，以及 frontend-wasm 即我们需要创建 3 个工程（请注意您处于 actix-web-async-graphql 目录中）：前端和后端 —— 均为二进制程序，所以传递 --bin 参数，或省略参数。
cargo new backend --bin
cargo new frontend-handlebars --bin
cargo new frontend-wasm --bin
注3：如果你不想要产生 git 信息，或者你有自己的 git 配置，请在 cargo 命令后再加上
--vcs none参数。
创建后，工程结构如下图所示——
我们可以看到，因为还未编译，没有 Cargo.lock 文件；main.rs 文件也是 Cargo 产生的默认代码。
现在，这个全新的工程，已经创建完成了。
工具类 crate 安装
工程创建完成后，我们即可以进入开发环节了。开发中，一些工具类 crate 可以起到“善其事”的作用，我们需要先进行安装。
- cargo-edit，包含
cargo add、cargo rm，以及cargo upgrade，可以让我们方便地管理 crate。 - cargo-watch，监视项目的源代码，以了解其更改，并在源代码发生更改时，运行 Cargo 命令。
好的，我们安装这 2 个 crate。
代码语言：javascript复制cargo install cargo-edit
cargo install cargo-watch
安装依赖较多，如果时间较长，请配置 Rust 工具链的国内源。
添加依赖 crate
接着，我们需要添加开发所需依赖项。依赖项的添加，我们不用一次性全部添加，我们根据开发需要，一步步添加。首先，从后端工程开始。
后端工程中，我们提供 GraphQL 服务，需要依赖的基本 crate 有 actix-web、async-graphql、rbatis。我们使用 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 = ["chrono"] }
rbatis = { version = "1.8.83", default-features = false, features = ["mysql", "postgres"] }
...
至此，我们构建基于 Rust 技术栈的 Graphql 服务的后端基础工程已经搭建完成。下一篇文章中，我们开始构建一个最基本的 GraphQL 服务器。
如果您发现错别字，请您给予指正
谢谢您的阅读。
