Importing spin sdk requires inbound-http

[nicolamos]

I need to build an application that is triggered by a timer and I used the spin-timer example as a starting point. Then I need to publish messages on a redis channel.
Importing redis from spin_sdk results in the following error.

Logging component stdio to ".spin/logs/"
Error: Failed to instantiate component 'three'

Caused by:
    0: failed to validate exported interface `fermyon:spin/inbound-http`
    1: module does not export required function `fermyon:spin/inbound-http#handle-request`

In order to test this, I just added

use spin_sdk::redis;

in lib.rs of the app-example under spin-timer.
I tried to add also an http_component (without declaring it in the manifest) and the error does not appear.

Any help is appreciated.

[itowlson]

@dicej any idea what would cause this? Only HTTP guests should need to export that interface, right?

[dicej]

The issue here is that there's currently no such thing as "optional" exports in the component model, and since we've upgraded the Spin SDK to use wit-bindgen 0.8 (which is based on the component model), any trigger using the SDK must declare either an http_component or a redis_component (or do the equivalent by hand). Note that each of those macros actually export both the inbound-http and inbound-redis interfaces in order to meet the requirements of the reactor WIT world on which the SDK is based: https://github.com/fermyon/spin/blob/main/sdk/rust/macro/src/lib.rs

I see two options for dealing with this:

1. Add a dummy http_component or redis_component declaration like @nicolamos tried, just to make Wasmtime's component runtime happy.
2. Add import fermyon:spin/redis to spin-timer.wit and use the generated bindings directly (i.e. not use the SDK). This is what we did to make fermyon:spin/config available. We could go ahead and add all the import interfaces (e.g. fermyon:spin/key-value, fermyon:spin/http, etc.) to that world if we wanted to.

More generally, we could consider breaking the Spin Rust SDK (and the corresponding reactor.wit) into an import half (i.e. the "outbound" stuff) and and export half (i.e. the "inbound" stuff), allowing trigger plugins to use just the former and not the latter.

cc @rylev in case he has any thoughts

[itowlson]

Yikes, we definitely need to crack this then!

Re splitting the SDK, is it possible as an interim measure to do this using Cargo features? So the default feature set would include the inbound stuff, but an app for a custom trigger could load only the outbound stuff?

(Or is the longer term intention that apps would use the relevant WITs directly, with no fixed set in the SDK?)

What does this mean for other language SDKs, e.g. writing custom trigger apps using the JS or Python SDKs? Impossible?

[dicej]

Re splitting the SDK, is it possible as an interim measure to do this using Cargo features? So the default feature set would include the inbound stuff, but an app for a custom trigger could load only the outbound stuff?

Sounds good to me.

(Or is the longer term intention that apps would use the relevant WITs directly, with no fixed set in the SDK?)

Personally, I'm a fan of using the wit-bindgen-generated bindings directly without using an SDK, particularly as they become friendlier and more idiomatic over time. However, I expect there will always be opportunities for an SDK to add value on top of the generated code, so I doubt it will disappear entirely.

What does this mean for other language SDKs, e.g. writing custom trigger apps using the JS or Python SDKs? Impossible?

Once WASI Preview 2 is released, we're hoping to switch the JS and Python SDKs over to componentize-js and componentize-py, respectively, which will eliminate their dependency on the Spin Rust SDK. Given the current state of things, though, I think you're right that it's impossible. I'll think some more about what can be done there.

[itowlson]

@dicej Do you know where we stand with this at the moment? With custom triggers being adopted into SpinKube, will a user be able to write a SQS or MQTT application but still use Spin SDKs for accessing Spin APIs?

[dicej]

@dicej Do you know where we stand with this at the moment? With custom triggers being adopted into SpinKube, will a user be able to write a SQS or MQTT application but still use Spin SDKs for accessing Spin APIs?

This should work fine now that we've moved the Python SDK over to componentize-py. You can specify spin-imports as the world name, in which case neither the http nor the redis exports will be expected or required.

There's also a new feature that allows you to specify a separate WIT world for each SDK package you use, so you could publish a MQTT SDK and use it in combination with the Spin SDK if desired (or just use an MQTT WIT file along with the Spin SDK).

[itowlson]

@dicej Thanks - this is great to hear. The original issue seems to refer to the Rust SDK; I tried using that in the timer sample app, and it seems happy. I'll close this - please reopen if you have any concerns about doing so!