Support for incoming gRPC

[fibonacci1729]

Recently it has been demonstrated that client side gRPC works with Spin (via wasi-grpc). With the recent PR to enable incoming HTTP/2 it should be possible to similarly enable incoming requests for gRPC services.

[itowlson]

@fibonacci1729 Do you envisage this as a Spin runtime thing, or a SDK/library thing like the wasi-grpc library? I had a noodle on getting a gRPC server running as a Rust guest and it seemed to work okay doing it entirely in the guest. (Although I only did a simple case so far.) Should I explore productising that, or did you have an idea for something more infrastructural?

[fibonacci1729]

Sorry I should have specified! I think the best case is that gRPC services just work with the recent enablement of incoming http/2. But my guess would be some minimal shim would be required to bridge sdk/wasi types to tonic.

Does is just work out of the box? If so, that's great and I think this issue could be closed with an example demonstrating unary and streaming services.

Edit: i should have finished reading before responding 😂

Although I only did a simple case so far.) Should I explore productising that

This would be great!

[itowlson]

Well, "just work" might be stretching it. I couldn't get it working with Rust SDK HTTP types, because wasi-hyperium exports its own WASI types and they don't unify. But I don't think that's a showstopper, because we can wrap the WASI HTTP stuff in a macro or whatever: in principle there may not be any real need for gRPC guest devs to see the HTTP-level request-reponse at all. But if we do want to use SDK types then yeah we may need to shim but I feel like that's still likely in the guest. I'll have an explore anyway - thanks for the guidance!

[lann]

For incoming grpc I wouldn't expect the guest to see HTTP types.

[itowlson]

@lann Let me clarify "the guest" here (because I used it imprecisely earlier). Are you saying:

• The guest Wasm component should not see the wasi:http interface (there should be a spin/wasi:grpc interface instead); or
• The guest source code should not interact with the HTTP request and response objects (e.g. hidden behind macros or libraries or whatever)

(I was writing in the second sense; obviously the first sense would require host work or a shim.)

[fibonacci1729]

I was thinking in terms of your 2nd case but hadn't been considering a macro to hide the http details (but I think that makes sense!)

[lann]

Yeah the latter. Specifically if we were using the same strategy as wasi-grpc we wouldn't use the SDK's http facilities at all (unless you wanted to make a non-grpc outbound http request). Instead the entrypoint would call wasi-hyperium's handle_service_call, roughly like this (replacing the axum bits with tonic bits).

[itowlson]

I pushed a Rust thing at https://github.com/fermyon/wasi-grpc-server-rust. Preliminary for feedback. @fibonacci1729 I considered adding it as a new crate in your existing repo but it looked like I'd need to move stuff around for that - thoughts?

[fibonacci1729]

Nice work!

Feel free to reorg wasi-grpc!

[itowlson]

Given the proposal to implement this in guest libraries rather than in Spin, I'm not sure of the best way to track next steps. I've done a Rust library. We could open issues for Go / JS / Python in their SDK repos? Even though it's not really SDK work? Or something else?

cc @adamreese @karthik2804