How to convert any rust project to be compatible with spin deploy?

[codeitlikemiley]

If I were to convert any rust app to use spin i would be at least required to

1. declare cdylib to produce a Wasm module

2. spin-sdk to be able to use the macro below

3. use the #[http_component] macro

4. wasm32-wasi target is required

5. must have a spin.toml

Below are some of the steps i believe would be done...

add the following in my Cargo.toml

[package]
name = "your-app"
version = "0.1.0"
edition = "2021"

[lib]
# Required to have a `cdylib` (dynamic library) to produce a Wasm module.
crate-type = [ "cdylib" ]

[dependencies]
# Useful crate to handle errors.
anyhow = "1"
# The Spin SDK.
spin-sdk = { git = "https://github.com/fermyon/spin" }

create a spin.toml

spin_manifest_version = 2

[application]
name = "app"
version = "0.1.0"
authors = ["Uriah <codeitlikemiley@gmail.com>"]
description = ""

add a rust template using:

spin add -t http-rust

prompt you with the following:

Enter a name for your new component: api
Description:
HTTP path: /api

the spin.toml gets updated to

spin_manifest_version = 2

[application]
name = "app"
version = "0.1.0"
authors = ["Uriah <codeitlikemiley@gmail.com>"]
description = ""

[[trigger.http]]
route = "/api"
component = "api"

[component.api]
source = "ruber/target/wasm32-wasi/release/api.wasm"
allowed_outbound_hosts = []
[component.ruber.build]
command = "cargo build --target wasm32-wasi --release"
workdir = "api"
watch = ["src/**/*.rs", "Cargo.toml"]

lib.rs having now used the spin_sdk and #http_component macro

use spin_sdk::http::{IntoResponse, Request, Response};
use spin_sdk::http_component;

/// A simple Spin HTTP component.
#[http_component]
fn handle_ruber(req: Request) -> anyhow::Result<impl IntoResponse> {
    println!("Handling request to {:?}", req.header("spin-full-url"));
    Ok(Response::builder()
        .status(200)
        .header("content-type", "text/plain")
        .body("Hello, Fermyon")
        .build())
}

So to conclude this, this is whats need to be done from scratch if we you wanna use spin

but like i am asking this doesnt convert any existing project to be compatible with deploy

as an example a leptos app can be build to wasm

but still i know there is a package built as wrapper on top of it

leptos-spin that now would allow you to use spin deploy

While on other example I saw Dioxus dont have any wrapper and uses wasm-bindgen

which spark my attention to , that might be able to give me more clarity on my problem.

[package]
name = "fermyon-spin-dioxus-csr"
authors = ["ZombieKing <zombiekingcrypto@proton.me>"]
description = "Fermyon Spin + Dioxus - Client Side Rendering (CSR) template with Tailwind"
version = "0.1.0"
edition = "2021"
repository = "https://github.com/SatoshiWagmito/spin-dioxus-csr"
license = "MIT"
license-file = "LICENSE"

[lib]
crate-type = ["cdylib"]

[dependencies]
console_error_panic_hook = "*"
anyhow = "1"
spin-sdk = "2.2.0"
wasm-bindgen = "0.2.92"
web-sys = "0.3.69"
serde = "*"
manganis = "0.2.2"

[dependencies.dioxus]
version = "0.5.0"
features = ["web"]

[workspace]

see here on this Cargo.tom being

the stuff i mentioned required above is also being required here

1. spin.toml
2. crate-type set to cdylib
3. use spin-sdk
4. target wasm32-wasi
   on the 5 stuff mentioned above we dont have

BUT

on their example code on their lib.rs i dont see

any import to spin-sdk and usage of the macro #[http_component]

the that was added now to my mental clarity is adding wasm-bindgen

see their lib.rs

also their spin.toml is quite interesting

spin.toml

spin_manifest_version = 2

[application]
name = "fermyon-spin-dioxus-csr"
version = "0.1.0"
authors = ["ZombieKing <zombiekingcrypto@proton.me>"]
description = "Fermyon Spin + Dioxus - Client Side Rendering (CSR) template with Tailwind"

[[trigger.http]]
route = "/..."
component = "spin-dioxus-csr" # same as the name of the project name on Cargo.toml

[component.spin-dioxus-csr]
source = { url = "https://github.com/fermyon/spin-fileserver/releases/download/v0.2.1/spin_static_fs.wasm", digest = "sha256:5f05b15f0f7cd353d390bc5ebffec7fe25c6a6d7a05b9366c86dcb1a346e9f0f" }
files = [{ source = "pkg", destination = "/" }]
# set the fallback path so maybe Spin works well with Dioxus like it does with the Leptos Router
environment = { FALLBACK_PATH = "index.html" }

[component.spin-dioxus-csr.build]
command = "wasm-pack build --release --target web && cp static/index.html pkg && npx tailwindcss -i static/input.css -o pkg/tailwind.css"
watch = ["src/**/*.rs", "Cargo.toml"]

here they havent used any LOCAL BUILD that has .wasm

e.g. below

source = "app_name/target/wasm32-wasi/release/app_name.wasm"

They used a certain build from this repo:
https://github.com/fermyon/spin-fileserver/

the build link ishttps://github.com/fermyon/spin-fileserver/releases/download/v0.2.1/spin_static_fs.wasm

which after some time learned this was generated using a command

spin new -t static-fileserver

I have tested spin deploy on this project and it deploy on fermyon cloud and show a static page

well by the looks of that I think that even if we are not using spin-sdk on the project we can still deploy it on fermyon cloud
maybe because of the spin-fileserver

I also find now another interesting example that uses spin-fileserver

https://github.com/fermyon/spin-fileserver/tree/main/examples/rust

see the Cargo.toml

[package]
name = "spin-fileserver-example"
version = "0.1.0"
edition = "2021"

[lib]
crate-type = ["cdylib"]

[package.metadata.component]
package = "component:spin-fileserver-example"
adapter = "../../adapters/fd1e948d/wasi_snapshot_preview1.reactor.wasm"

[dependencies]
cargo-component-bindings = "0.4.0"
wit-bindgen = "0.13.0"
spin-sdk = { git = "https://github.com/fermyon/spin" }
futures = "0.3.28"

[workspace]

This is quite interesting as they are using
wit-bindgen and cargo-component-bindings

and a new compose.yaml

search-paths:
  - ../../target/wasm32-wasi/release

instantiations:
  $input:
    arguments:
      wasi:http/incoming-handler@0.2.0-rc-2023-10-18: spin_static_fs

and this block of code

mod bindings {
    wit_bindgen::generate!({
        path: "../wit",
        world: "delegate",
        with: {
            "wasi:http/types@0.2.0-rc-2023-10-18": spin_sdk::wit::wasi::http::types,
            "wasi:io/streams@0.2.0-rc-2023-10-18": spin_sdk::wit::wasi::io::streams,
            "wasi:io/poll@0.2.0-rc-2023-10-18": spin_sdk::wit::wasi::io,
        }
    });
}

Im wondering what does it do

i read the wit-bindgen
https://github.com/bytecodealliance/wit-bindgen

that using that , allows use to use any *.wit file

e.g.

// wit/host.wit

package example:host;

world host {
  import print: func(msg: string);

  export run: func();
}

I have dugged so much info, but the end conclusion i have is

One there is no way to deploy a rust project if it is not compiled to wasm and dont have any spin.toml and spin-sdk usage
the exeption would be using the file-server that is already a wasm and uses spin under the hood...

so the example on dioxus is not quite complete , and missing usage of spin-sdk , since what just happened is it compiles the code to as an asset that is serve by the file-server....

What I am searching actually is , or have been lurking on my head to ask is

e.g. I have a rust image e.g. a grpc server or actix web ... that i have build on docker

is there a way using spin cli to deploy as such?

If there is please let me know

[itowlson]

Thanks for digging so deeply into the Spin and Wasm rabbit hole! There are a lot of overlapping threads here and I'm not quite sure how to address all of them, but I'll do my best!

Spin is a server-side Web assembly runtime. That is, an application (or component) to run in Spin must indeed be compiled to Wasm. You can't use it to deploy arbitrary containers, whether the application in those containers is Rust-based or not.

The file server is an example of a Spin WebAssembly component. It illustrates that you don't necessarily need to compile your own code to Wasm. For example, you can use the fileserver to serve a site generated using a SSG such as Zola (https://github.com/karthik2804/spin-zola), or to serve Leptos or Dioxus CSR application, because there is no server-side logic in any of those except for serving the static assets (browser Wasm, JavaScript, CSS, etc.). (Yes, the CSR examples involve building your own code to Wasm... but it is client-side Wasm, which from Spin's point of view is a static asset. It doesn't run in Spin: it just gets handed off to the browser.) Another example might be the Bartholomew CMS: you can use the Bartholomew Wasm file (linked from https://github.com/fermyon/bartholomew/releases/tag/v0.10.0) to serve templated Markdown files without ever writing a line of Rust code.

If you do build server code to Wasm to run in Spin, then you need the resulting Wasm to conform to the Spin and WASI interfaces. The SDK (and the Rust wasm32-wasi target) do this automatically for you. wit-bindgen is required only if you want to do it yourself. This can be useful if you want to use Wasm component composition (https://component-model.bytecodealliance.org/creating-and-consuming/composing.html), which I think is that the fileserver example compose.yaml you found is doing. (wasm-bindgen is subtly different: it's used for client-side Wasm operating in a JavaScript runtime, not for the server side. Which is why you see it in the Dioxus CSR example.)

The spin.toml file lists the components that make up the Spin application - the Wasm files, the static assets, and the configuration - because 1. an application may have multiple components handling different routes and 2. many components require capabilities such as network access, file access, storage access, etc.

So, the key things for your topics and questions are, I think:

• Spin runs Wasm on the server
• That can be a pre-built Wasm component, or custom server-side logic you compile yourself
• But it must conform to a Spin-defined interface (normally via the SDK)
• As far as Spin is concerned, client-side Wasm is just opaque bytes to be sent to the browser

I hope that gives a bit more of a picture. Happy to clarify further.