Question about Rust http::Request and HTTP trigger roadmap

[captaincoordinates]

First of all, sorry if this information is provided by the documentation. I haven't found an answer to my question and I haven't seen a roadmap.

I'd like to know if future versions of Spin are expected to focus on HTTP trigger functionality and, for example, provide a higher-level API in the Rust spin_sdk::http::Request struct. According to the docs and this comment query string parameters are provided as a &str, which means I'm responsible for parsing logic in my implementation. This is manageable, and I'm happy to pay this price for being able to use Spin, but this kind of processing is obviously a good opportunity for the framework to abstract away some complexity that's likely required by most implementations.

I haven't been able to find another framework that can support HTTP APIs and run in WebAssembly, so I'm excited about Spin, but I'd love to have a bit more information about what the future holds for the HTTP trigger before committing the time to really get to know it. With the current API - which is lower-level than many of the HTTP API alternatives that don't compile to WebAssembly - it's a tough decision how much developer resource can be justified by the anticipated performance and scaling benefits.

I'm aware that Spin is an Open Source project, and that I can potentially help to drive the product in this direction with PRs. Here I'm hoping to better understand the current roadmap to see if this an area in which I'd like to focus my availability.

[itowlson]

This is a great question. As a hosting framework, Spin should ideally not be too prescriptive about how to do things or access things: users must have access to the bottom level (wasi-http) to build their own choice of abstraction layer on top. But the SDK does provide higher level features too, such as routing or JSON body support. So it wouldn't be inconsistent to offer structured access to the query string, e.g. as a slice of key-value pairs. But we'd still want to keep the baseline representation, so that people who want to use (say) serde_query could use that instead.

The long-game hope/bet is that WASI Preview 2 (which is what defines Spin's base HTTP types) will become sufficiently widely accepted that the higher-level frameworks and libraries you describe will just transparently work with the WASI incoming-request type in future, so you won't be limited to what's in the Spin SDK (or what you build on top of it), in a similar way to how you can just use Rust file libraries, rather than being stuck with a Spin File SDK. But that's not where we are today.

So this ends up being kind of an evasive answer. We're certainly open to higher-level APIs in the Spin SDK, and delighted to take PRs that improve usability. Things that are strongly opinionated should typically be outside the SDK, layered above it in their own packages, similar to spin-contrib-http (https://github.com/ThorstenHans/spin-contrib-http, although a lot of that is pretty low level too!) or leptos-spin (https://github.com/fermyon/leptos-spin). But for things that are common and non-prescriptive, like extractors, builders, and parsers: yes, we would love to hear more or to accept PRs.

I hope that makes sense, and I know it's a long answer! Always happy to discuss further and to see how we can improve for our users!

[captaincoordinates]

Thanks for your input, this adds some context that I was missing. I'm currently trying to get my head into the WASI space and understand what's possible or practical. I'll check out spin-contrib-http and see how the approach might influence something like query string parsing.