Merge pull request #145 from michelleN/v3.5

add v3.5 blog post

Author: michelleN

content/blog/announcing-spin-3-5.md

@@ -0,0 +1,162 @@
+title = "Announcing Spin v3.5"
+date = "2025-11-10T01:27:05.449167Z"
+template = "blog_post"
+tags = []
+
+[extra]
+type = "post"
+author = "Michelle Dhanani"
+
+---
+
+The CNCF Spin project recently released [Spin v3.5.0](https://github.com/spinframework/spin/releases/tag/v3.5.0) which includes support for a release candidate of the upcoming WASIp3 release, along with several developer experience enhancements! In this blog post, we’ll dive into a few exciting features of this release and highlight an example of what is enabled with WASIp3 in Spin.
+
+If you want to skip ahead to the official Release Notes, you can find them [here](https://github.com/spinframework/spin/releases/tag/v3.5.0).
+
+## Experimental WASIp3 Support
+
+### WASIp3 and Why It Is Special
+
+Read all about WASIp3 in Joel Dice’s blog post [here](https://www.fermyon.com/blog/looking-ahead-to-wasip3). To recap, it’s the next release of WASI, a set of standard APIs for portable application development with WebAssembly, and currently has one release candidate. This release of WASI comes with first class support for concurrency and async and significantly simplified APIs or WebAssembly Interface Types (WIT) definitions. These additions bring full and fine-grained composability of components written in different languages and with different concurrency models, enabling scenarios such as a Python and a Rust component seamlessly doing concurrent HTTP requests, each using their respective idiomatic concurrency models.
+
+### WASIp3 and the Spin Experience
+
+WASIp3 isn’t fully stable yet; it’s going through a Release Candidate (RC) stage, and there are likely to be some minor changes before the [final release](https://wasi.dev/roadmap). To ensure a consistent experience for developers, Spin requires you to opt in to using this unstable RC in the HTTP trigger section of your spin.toml file:
+
+```toml
+[[trigger.http]]
+executor = { type = "wasip3-unstable" }
+```
+
+#### A Shiny New Rust SDK
+
+The latest release of the Spin Rust SDK introduces:
+
+- An `#[http_service]` macro - defines the entry point to your component. Functions annotated with this macro must be marked `async`.
+- An `http-wasip3` module – offers the core SDK experience for working with WASIp3 in Spin.
+
+To use these, make sure to enable the `wasip3-unstable` feature for your `spin-sdk` dependency in your application's `Cargo.toml`.
+
+```toml
+[package]
+name = "concurrent-outbound-http-calls"
+rust-version = "1.90" # required for components using WASIp3 APIs
+[...]
+
+[dependencies]
+spin-sdk = { version = "5.1.1", features = ["wasip3-unstable"] }
+```
+
+One thing you’ll notice the moment you try out the new SDK is that you’re using familiar Rust types from the `http` and `hyper` ecosystem, rather than Spin- or WASI-specific types. This was not an accident as one of the main goals in designing the new Rust SDK was to enhance interoperability with the Rust HTTP ecosystem. During implementation, we developed conversions between native Rust HTTP types and those generated by WASIp3, allowing developers to write HTTP code that feels more idiomatic and natural in Rust. We [contributed these conversions upstream](https://github.com/bytecodealliance/wasi-rs/pull/126) to the Bytecode Alliance’s `wasi-rs` project, with the hope that they’ll benefit the broader WASI ecosystem as well.
+
+<figure class="image">
+  <img src="/static/image/blog/announcing-spin-3-5-gh-comment.png" alt="Bytecode Alliance member github comment on wasi-rs contribution">
+</figure>
+
+But that’s not where the interoperability story ends. Because of the design of the SDK in conjunction with the async support provided by WASIp3, it is now more seamless to bring your own web frameworks to use in Spin components. See for instance the Axum example [here](https://github.com/spinframework/spin-rust-sdk/tree/main/examples/wasip3-http-axum-router). Historically, this was possible to do but required management of more lower level types. See the Axum example with WASIp2 [here](https://github.com/fermyon/wasi-hyperium/blob/main/examples/axum-server/src/lib.rs) for comparison. We’d love to hear more feedback on this experience through [GitHub issues](https://github.com/spinframework/spin-rust-sdk/issues), on [Slack](https://cloud-native.slack.com/archives/C089NJ9G1V0), or during [project meetings](https://github.com/spinframework/spin#getting-involved-and-contributing).
+
+#### More on Language Support
+
+WASIp3 support recently landed in [componentize-py](https://github.com/bytecodealliance/componentize-py/pull/173), which the [Spin Python SDK](https://github.com/spinframework/spin-python-sdk) is based on. A new release of the SDK will soon follow. This work is based on the new [wit-dylib library](https://crates.io/crates/wit-dylib), which is designed to make support of WASIp3 in dynamically typed languages easy. 
+
+Building on the same foundations, we can also look forward to WASIp3 support in JavaScript in the coming months.
+
+In the meantime, these languages continue to be supported using WASIp2 just as before.
+
+### Getting Started
+
+Get started with WASIp3 using a Spin template.
+
+Install the new template: 
+`$ spin templates install --upgrade --git https://github.com/spinframework/spin`
+
+Use the new template to scaffold a WASIp3 Spin application:
+`$ spin new hello-p3 -t http-rust-wasip3-unstable`
+
+You should now see a `hello-p3` directory containing a basic p3 application using the new Rust SDK and the `wasip3-unstable` executor type.
+
+### Deep Dive Into Example
+
+The Rust SDK repo provides examples of things you can now do with p3 support. Let’s dive into one of them. With WASIp3 support in Spin, you can make concurrent outbound HTTP requests from within a component. See full example [here](https://github.com/spinframework/spin-rust-sdk/tree/main/examples/wasip3-concurrent-outbound-http-calls).
+
+The first step of using the SDK is opting into the `wasip3-unstable` feature as is done on the last line of the `Cargo.toml` file above. Also note Rust 1.90 and the `wasm32-wasip2` target are required to build WASIp3 components. (WASIp2 and p3 have the same binary representation, with p3 adding additional features. The `wasm32-wasip2` target causes the Rust compiler to emit the right binary format, with the SDK adding the additional p3 features.)
+
+The following `src/lib.rs` file contains the crux of the component.
+
+```rust
+[...]
+
+#[http_service]
+async fn handle_concurrent_outbound_http_calls(_req: spin_sdk::http_wasip3::Request) -> anyhow::Result<impl IntoResponse> {
+
+    let spin = pin!(get_content_length("https://spinframework.dev"));
+    let book = pin!(get_content_length("https://component-model.bytecodealliance.org/"));
+
+    let (first, len) = match futures::future::select(spin, book).await {
+        Either::Left(len) => ("Spin docs", len),
+        Either::Right(len) => ("Component model book", len),
+    };
+
+    let response = format!("{first} site was first response with content-length {:?}\n", len.0?);
+
+    Ok(response)
+}
+```
+
+Here we are creating two async tasks (Futures) that will each fetch the content-length from different URLs. `futures::future::select(spin, book).await` runs both tasks concurrently and waits until one of them completes. It then matches and returns the site that returned first and the resulting content length.
+
+```rust
+async fn get_content_length(url: &str) -> anyhow::Result<Option<u64>> {
+    let request = Request::get(url).body(EmptyBody::new())?;
+    let response = send(request).await?;
+    let cl_header = response.headers().get("content-length");
+    let cl = cl_header.and_then(|hval| hval.to_str().ok()).and_then(|hval| hval.parse().ok());
+    Ok(cl)
+}
+```
+
+`get_content_length` is an async function that sends an HTTP GET request to the given URL and extracts the Content-Length header (if any) from the response.
+
+### What’s Next with WASIp3
+
+The WASI community is gearing up to [finalize WASIp3](https://wasi.dev/roadmap). This process includes completing two implementations of the release candidate in two independent runtimes and a vote. Voting is expected to happen within the next few months. Once a final release is available, we can expect a Spin release shortly after.
+
+That doesn't mean that you'll have to wait quite as long with using WASIp3, though. In Spin 3.5, p3 support is still experimental, but [as we did with WASIp2](https://www.fermyon.com/blog/introducing-spin-v2#bringing-production-use-to-the-standardization-process), we'll ship ungated support for p3 meant for production use in an upcoming release, before the release is fully finalized. With that release, you'll be able to use WASIp3 for real workloads and be confident that it will continue working. At the same time, any feedback you can provide based on this use will help us and the wider community make the final p3 release even better.
+
+## More Developer Experience Enhancements
+
+Beyond experimental support for WASIp3, the Spin 3.5 release contains the following additional features.
+
+### Static HTTP Responses
+
+You can now easily define static HTTP responses right from within the HTTP trigger section of the spin.toml file rather than a component. The response may contain status code, headers, and body. This is especially great for handling fallbacks and redirects. See example [here](https://spinframework.dev/v3/http-trigger#static-responses-with-the-http-trigger).
+
+```toml
+# Example use case: fallback 404 handling
+[[trigger.http]]
+route = "/..."
+static_response = { status_code = 404, body = "not found" }
+
+# Example use case: redirect
+[[trigger.http]]
+route = "/bob"
+static_response = { status_code = 302, headers = { location = "/users/bob" } 
+```
+
+### Reference Dependencies by Component ID
+
+Previously, we could specify component dependencies from a registry, a local component on the file system, or from a URL. You can now specify a component from within you application a dependency using the Component ID. See documentation [here](https://spinframework.dev/v3/writing-apps#dependencies-from-a-component-in-the-application).
+
+### OpenAI Support
+
+Spin provides a Large Language Model interface for interacting with LLMs for inferencing and embedding. This release adds support for integrating with the OpenAI API as one of the LLM backend options through runtime configuration. See more [here](https://spinframework.dev/v3/dynamic-configuration#open_ai-api).
+
+## Thank You
+
+A huge thank you to contributors new and old for helping bring this release together. Thank you to our growing community and to the CNCF for their support and to the Bytecode Alliance for making such great strides on WASI.
+
+## Stay In Touch
+
+We look forward to seeing you all at KubeCon Atlanta. Stop by the Project Pavilion for demos and to chat with contributors. We’d love to meet you. Please join us for weekly [project meetings](https://github.com/spinframework/spin#getting-involved-and-contributing), chat in the [Spin CNCF Slack channel](https://cloud-native.slack.com/archives/C089NJ9G1V0) and follow on X (formerly Twitter) [@spinframework](https://twitter.com/spinframework)!
+
+To get started with Spin and explore the latest features, follow the [Spin quickstart](https://spinframework.dev/v3/quickstart) which provides step-by-step instructions for installing Spin, creating your first application, and running it locally. Also head over to the [Spin Hub](https://spinframework.dev/hub) for inspiration on what you can build!