Cloudflare Workers & WASM

Relevant source files

The following files were used as context for generating this wiki page:

• examples/cf-worker/README.md
• examples/cf-worker/Cargo.toml
• examples/cf-worker/wrangler.toml
• README.md
• Cargo.toml
• CHANGELOG.md

resend-rust supports WebAssembly (WASM) targets, enabling the SDK to run within edge computing environments like Cloudflare Workers. This support allows developers to integrate Resend's email and automation services directly into low-latency serverless functions. Support for WASM was officially introduced in version v0.12.0 of the crate.

Sources: examples/cf-worker/README.md:11, CHANGELOG.md:586

Architecture and Dependencies

The WASM implementation integrates with the worker crate to handle the Cloudflare Workers runtime. It utilizes the wasm_js backend for random number generation, which is a requirement for certain internal SDK operations when running in a JavaScript environment.

The diagram shows the relationship between the Rust SDK, the Worker runtime, and the JavaScript environment's random number generator.
Sources: examples/cf-worker/Cargo.toml:16-25, examples/cf-worker/README.md:5-8

Key Dependencies for WASM

To function within a Cloudflare Worker, specific dependencies must be configured in Cargo.toml.

Dependency	Version	Features	Purpose
worker	0.5.0	http, axum	Cloudflare Workers SDK for Rust
getrandom	0.3	wasm_js	Provides entropy via JavaScript crypto.getRandomValues
resend-rs	0.12.0	N/A	Core SDK with WASM compatibility
axum	0.8	default-features = false	Routing within the worker (optional)

Sources: examples/cf-worker/Cargo.toml:16-25, Cargo.toml:144

Build Configuration

Deploying the SDK to Cloudflare requires specific build flags and metadata. The project uses worker-build to compile the Rust code into a WASM module compatible with the wrangler deployment tool.

RUSTFLAGS Configuration

Because WASM targets do not have standard OS entropy sources, you must explicitly enable the JavaScript-interop backend for the getrandom crate. Failure to provide these flags results in runtime panics during client initialization.

RUSTFLAGS='--cfg getrandom_backend="wasm_js"' worker-build

Sources: examples/cf-worker/README.md:5-8

Wrangler Metadata

The wrangler.toml file defines the build command and the entry point for the compiled WASM module.

name = "cf-worker-test"
main = "build/worker/shim.mjs"
compatibility_date = "2025-01-22"

[build]
command = "cargo install -q worker-build && worker-build --release"

Sources: examples/cf-worker/wrangler.toml:1-6

Integration and Usage

In a WASM environment, the Resend client defaults to using reqwest's WASM-compatible HTTP backend. The client remains asynchronous, as blocking operations are not permitted in the Cloudflare Workers main thread.

The sequence diagram illustrates the flow of an email request originating from a Worker handler.
Sources: README.md:50-53, src/lib.rs:8-15

Runtime Restrictions

• Feature Conflicts: The blocking feature cannot be used in WASM targets as it relies on reqwest/blocking, which is incompatible with the browser-like fetch API used in WASM.
• Rate Limiting: The SDK's internal rate limiting (defaulting to 9 requests per 1.1s) functions within the Worker, provided the client instance is persisted or cloned within the handler scope.
• TLS: native-tls is generally replaced by the runtime's own TLS implementation during the fetch call in a WASM context.

Sources: README.md:25-45, src/config.rs:135-145, Cargo.toml:133-145

Summary

The Cloudflare Workers and WASM support allows resend-rust to operate at the edge. By configuring the wasm_js backend for getrandom and utilizing worker-build, developers can execute email operations within serverless environments. The SDK maintains its core asynchronous API and internal rate-limiting features, ensuring consistent behavior across standard server and WASM edge runtimes.

Sources: examples/cf-worker/README.md:1-13, CHANGELOG.md:586