为什么Rust不适合开发Web API

这篇文章主要讲解了“为什么Rust不适合开发WEB api”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“为什么Rust不适合开发Web API”吧！

Rust 是一门神奇的编程语言，有非常好的 CLI 工具，比如 ripgrep 和 exa。像 Cloudflare 这样的公司正在使用并 鼓励人们写  Rust 来运行微服务。Rust 编写的软件可能比 c++ 或 C 更安全、更小、更简洁。

如果我正在编写一个地理编码器、一个路由引擎、一个实时消息平台、一个数据库或一个 CLI 工具，Rust 最合适。

但去年，我试图用 Rust 写一个传统网站的纯 API 服务，Rust 就不合适了。

缺失很多小功能

Rust 有大量的 Web 服务框架、数据库连接器和解析器。但搭建身份验证服务方面只有非常低层次的组件。node.js 有  passport.js，Rails 有 devise，Django 有 开箱即用的身份验证模型，在 Rust 中，你需要学习如何将共享 Vec  转换到底层加密库才能构建这个系统。

译者注，Vec 是一个动态数组，只会自动增长而不会自动收缩。区别于 Array，Vec 具有动态的添加和删除元素的能力，并且能够以 O(1)  的效率进行随机访问。Vec 的所有内容项都是生成在堆空间上的，可以轻易的将 Vec 移出一个栈而不用担心内存拷贝影响执行效率，毕竟只是拷贝栈上的指针。

有些库试图解决这个问题，比如 libreauth，但它才刚刚开始开发。还有很多类似的 Web 框架问题。

SDK 呢?在主流编程语言中，你可以通过一个官方库来接入 Google 云服务、AWS 或 Stripe。这些官方库大都很棒。例如，aws-sdk-js  和 Stripe 库的设计和维护得非常好。

Rust 就不这样，只有少许第三方库，但以这些服务的开发速度，它们真的能够提供高质量的体验吗?

有人会说好吧，X 编程语言太好了，你可以在周末自己写一个 SDK!我必须回答，不。

Rust 的生态系统在其它领域非常丰富。用于构建 CLI、管理并发性、使用二进制数据和底层解析器的 crates 令人印象深刻，非常棒。

Rust 编译器比以前快，但仍然很慢

我一直在看 Nicholas Nethercote 的博客，描述了 Rust 团队如何优化编译器，让它更快!

但与其它编程语言相比，用它构建网站会很慢。它比编译型编程语言 Go 慢得多，也比解释型编程语言 javascript、Ruby 和 python  等慢得多。

一旦代码被编译，一切就变得非常棒了!但在我的情况下，甚至基本 API 功能都不完整，一个不复杂的系统——居然花了 10 多分钟来编译。Google  代码构建 的硬件配置很差，每次都会超时，我啥都编译不了。

只要不重建缓存依赖项，缓存就有意义。也许 减少依赖 会加快 Rust 项目编译。但就像 serde，几乎所有人都使用的 JSON 和其它序列化 /  反序列化程序占用了大量的编译时间。我们是否应该用编译速度更快但缺乏大量文档和生态系统支持的东西来取代 serde?这种取舍非常糟糕。

Rust 很复杂

Rust  让你从代码维度进行思考，这对系统编程来说非常重要。它让你思考如何共享或复制内存，思考真实但不太可能的小概率事件，并确保妥善处理它们，帮你编写各种各样的高效代码。

这些担忧都是合理的，但是对于大多数 Web 应用程序来说，它们并不是最重要的关注点，以流行的惯性思考会导致不正确的假设。

就拿 Rust 的安全性来说吧。这是它宣传语中的重要部分，这是绝对正确的：Rust  的承诺安全和底层两者兼而有之——它可以在没有垃圾收集器的情况下工作，同时防止基于内存的漏洞。当你读到“安全”的时候，想想 Rust 的竞争对手 C 吧。C  语言中的代码可以引用任意内存，很容易溢出和出错。Rust 代码可以和 C 代码一样快，但是可以保护内存访问，而不需要垃圾收集器或某种运行时检查。

但是 Rust 的内存规则并不比 node.js 或 Python 更安全，用 Rust 编写的 Web 应用程序在系统上不会比 Python 或  Ruby 应用程序安全。带有垃圾收集器的高级编程语言通常为避免这类漏洞利用和错误而付出性能损失。不能在 JavaScript 中引用未初始化的内存，因为  JavaScript 中不进行内存间的引用。

旁注：这是在描述 Node.js 和其它系统的设计目标——它们确实偶尔会有 bug。Node.js 的缓存对象，就值得读一读。

你要是 问一些人，他们会说如果使用不安全的代码，Rust 相比带有内存回收的编程语言是不安全的——包括最流行的 Web 框架  Actix(译者注，Actix 是 Rust 的 Actor 异步并发框架，基于 Tokio 和 Future，开箱具有异步非阻塞事件驱动并发能力，其实现低层级  Actor 模型来提供无锁并发模型，而且同时提供同步 Actor，具有快速、可靠，易可扩展 https://actix.rs/)，因为  不安全代码允许原始指针的延迟。

如果你正在写一个视频游戏，暂停执行垃圾收集是不好的。如果你在编写微控制器代码，任何内存“开销”或浪费都是非常糟糕的。但是大多数 Web  应用程序可以节省一点内存开销来换取生产性能。

Rust  的其它属性面对的争议几乎一样。它的并发特性是太神奇了，如果你在做一些复杂的事情，需要快速响应，这当然很棒。但如果情况不是这样呢?至少可以说，Rust  的异步生态系统面临着很大挑战：各种不相关的领域中有着不同的异步实现，比如 tokio。

相比较之下，Python 的 Tornado 和 Twisted 异步实现的很奇怪，Node.js 异步实现的很好，但语法都很丑陋。

我确信，Rust 的异步将会稳定和统一，未来会更容易操作，但我现在就要用啊。

Rust 生态系统不是以 Web 为中心的

很多人正在学 Rust，用 Rust 编写 CLI 应用程序或底层代码，并且玩得非常开心。使用 Rust  编写普通 Web 应用程序的人明显少很多。

这是技术选择中的重要部分：是否有人在使用该工具?他们大致在同一个领域吗?不幸的是，Rust 生态系统中许多令人难以置信的令人兴奋的工作与 Web  应用服务器无关。的确存在一些很有前途的 Web 框架——甚至更高层次的框架，但毫无疑问，它们市场很小。即使是主要的 Web 框架 Actix  也只有几个顶尖贡献者。

如果 Rust 以目前的速度增长，那么社区中的 Web 部分将达到一个临界值，但我认为没有足够多的人使用 Rust  作为网站的实用工具。与其它社区相比，有很多公司致力于使用现有的工具来构建 Web 应用程序，这些工具不是最前沿的，但足够将成熟技术与新技术区分开来。

Juniper 的 N+1 次查询

这一部分不仅仅是 Rust，它还涉及 GraphQL 生态系统，Rust 参与这个生态系统就是一个例子。

N+1 问题 是每个构建 Web  应用程序的人都应该知道的。要点是：你有一页照片(一次查询)，你要显示每张照片的作者，会有多少次查询：1，合并照片和作者，或者在检索照片后对每张照片进行查询以获取作者?或者两次，第二次查询  ids 中的 user.id，一次获取所有作者，然后重新设置他们的照片属性。

N+1 查询通常优先使用数据库解决：比如将 N+1 查询改为单个查询，会带来明显的性能优化。我们有很多方法来尝试和解决这些问题：你可以编写  sql，并尝试使用 CTE 和 JOIN 在单个查询中完成大量工作，就像我们在 Observable 中所做的那样，或者使用像 ActiveRecord 这样的  ORM 层将 N+1 查询转换为可预测查询的快速方法。

Juniper 是一个用于 Rust 应用程序的 GraphQL 服务。GraphQL  基本上都是由前端应用程序定义查询，而不是后端。给它一系列可以查询的东西，然后应用程序(React 或其它)将任意查询发送到后端。

这会让后端变得复杂。任何 SQL 级别的优化都不可能做到——你的服务器正在编写动态 SQL，优化只能依赖 GraphQL  服务，但它不会总是有效。例如：Juniper 默认情况下执行的是 N+1 查询，解决方案 dataloader  还比较粗糙且需要单独维护。因此，最终您将拥有一个非常快的应用程序层，但它所有的时间都花在了极其低效的数据库查询上。

总之，GraphQL 与 NoSQL 数据库配合使用效果非常好，它可以快速为这些类型的请求提供服务。我确信 Facebook 内部有一些特定的数据库与  GraphQL 结合在一起使用效果非常棒，但业内其他企业则非常依赖 Postgres 和同类产品。

感谢各位的阅读，以上就是“为什么Rust不适合开发Web API”的内容了，经过本文的学习后，相信大家对为什么Rust不适合开发Web API这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是编程网，小编将为大家推送更多相关知识点的文章，欢迎关注！