Hello! 欢迎来到小浪资源网!



Wasm 组件模型和惯用的代码生成


arcjet:使用webassembly组件模型和惯用代码生成构建安全sdk

ArcJet将WebAssembly与我们的安全即代码SDK相结合,允许开发者直接在代码中实现常见的安全功能,例如PII检测和机器人检测。大部分逻辑都嵌入到wasm中,提供接近原生性能的安全沙箱,符合我们“本地优先安全”的理念。

跨平台运行相同代码的能力非常重要,因为我们构建了从JavaScript其他技术的支持。但这需要一个重要的抽象层来进行跨语言转换(我们的Wasm是从rust编译的)。

WebAssembly组件模型是实现这一目标的强大工具,但其有效性取决于其周围的实现和工具。对于组件模型,这在主机(执行WebAssembly组件模型的环境)和客户(以任何语言编写并编译到组件模型的WebAssembly模块;在我们的例子中为Rust)的代码生成中最为明显。

组件模型定义了主机和客户之间通信的语言,主要由类型、函数、导入和导出组成。它试图定义一种通用的语言,但某些类型,例如变体、元组和资源,可能在某些编程语言中不存在。

当工具尝试为某种语言生成代码时,开发者通常需要进行创造性的映射,将组件模型类型映射到目标语言。例如,我们使用JCO生成JS绑定,并使用 {tag: string, value: String} 形式的JavaScript对象实现变体。甚至对于 result<_> 类型也有特殊情况,其中错误变体将转换为错误并抛出。

本文探讨了Wasm组件模型如何实现跨语言集成、主机和客户代码生成的复杂性,以及我们为用Go等语言实现惯用代码所做的权衡。

Go的主机代码生成

在ArcJet,我们必须构建一个工具来为主机生成用go语言编写的代码。虽然我们的SDK尝试在本地分析所有内容,但这并非总是可行,因此我们有使用Go编写的API,它通过附加元数据来增强本地决策。

Go的设计具有非常简洁的语法和类型系统。直到最近,它甚至还没有泛型,并且仍然存在很大的局限性。这使得从组件模型到Go的代码生成变得复杂。

例如,我们可以将 result<_> 生成如下:

type result[v any] struct {     value v     err error }

但这限制了错误位置可以提供的类型。因此,我们需要将其编码为:

type result[v any, e any] struct {     value v     err e }

这可以工作,但与其他惯用的Go代码一起使用会变得很麻烦,后者通常使用 val, err := dosomething() 约定来指示与我们上面定义的 result 类型相同的语义。

此外,构造这个 result 很麻烦:result[int, string]{value: 1, err: “”}。我们可能希望匹配惯用模式,而不是提供 result 类型,以便Go用户能够更自然地使用我们生成的绑定。

惯用映射与直接映射

代码生成可以使语言更自然,也可以更直接地映射到组件模型类型。这两个选项都不适合所有用例,因此由工具开发者决定哪个更有意义。

对于ArcJet工具,我们为 option 和 result<_> 类型选择了惯用的Go方法,它们分别映射到 val, ok := dosomething() 和 val, err := dosomething()。对于变体,我们为每个变体创建需要实现的接口,例如:

type botconfig interface {     isbotconfig() }  func (allowedbotconfig) isbotconfig() {}  func (deniedbotconfig) isbotconfig() {}

这在类型安全性和不必要的包装之间取得了良好的平衡。当然,也有一些需要包装的情况,但这些可以作为边缘情况处理。

开发者可能会遇到非惯用模式,导致代码冗长且难以维护。使用既定约定使代码更熟悉,但这确实需要一些额外的努力来实现。

我们决定采用惯用方式来最大限度地减少摩擦,让我们的团队更轻松,这样我们就知道在代码库中移动时会发生什么。

调用约定

工具开发者需要做出的一个重要决定是绑定的调用约定。这包括如何/何时编译导入、是否在设置或实例化期间编译Wasm模块以及清理。

在ArcJet代码库中,我们选择工厂/实例模式来优化性能。编译WebAssembly模块的成本很高,因此我们在 newbotfactory() 构造函数中执行一次。随后的 instantiate() 调用既快速又便宜,从而在生产工作负载中实现高吞吐量。

// …代码片段…

这种工厂和实例构建模式需要更多代码,但选择它是为了在ArcJet服务的热路径中实现尽可能多的性能。通过预先加载编译成本,我们确保在ArcJet服务的热路径中(延迟最重要)请求处理尽可能高效。这种权衡确实增加了初始化代码的复杂性,但它的回报是每个请求的开销大大降低。

权衡

无论使用原生FFI还是组件模型,任何时候我们需要集成两种或多种语言,都需要做出权衡。

本文讨论了我们在ArcJet中遇到的一些挑战以及我们做出决定的原因。如果我们都基于同一组原语(例如组件模型和WIT)构建,那么我们都可以利用同一组高质量原语,例如 wit-bindgen 或 wit-component,并构建适合每个用例的工具。这就是为什么制定标准对每个人都有帮助。

WebAssembly组件模型为跨语言集成提供了强大的抽象,但将其类型转换为Go等语言会带来微妙的设计挑战。通过选择惯用模式并有选择地优化性能(例如使用工厂/实例模式),我们可以在保持效率的同时提供自然的开发者体验。

随着组件模型工具的发展,我们可以期待更精细的代码生成方法来进一步简化这些集成。

Wasm 组件模型和惯用的代码生成

相关阅读