fermyon
Support gRPC services?
Hi,
I am a maintainer at smartcore, a Machine Learning library written in Rust, we already have wasm32 among our supported targets. I am trying to provide our interface via web services and I am now considering using Spin; for this purpose I am going to need somehow to support gRPC (I am using prost, see a limited poc here). The application I have in mind won't be possible using REST but we would be glad to leverage Wasm microservices using Spin.
I was wondering if you are considering to make possible to expose gRPC endpoints using Spin as easy as it is for REST endpoints. If yes what would be needed to be added to Spin? I would be glad to collaborate in making this possible for Rust applications.
Great to find you. Very interesting project 👍🏼
Hi @Mec-iS, good to meet you and thanks for the kind words, and for the clear context.
It sounds like your main interest would be in a gRPC server (that is, a trigger). Is that right?
How much of the gRPC feature set would you need? I'm specifically thinking about gRPC watch operations, which typically require a long-lived connection with server state. Today's Spin triggers operate very much in short-lived, request-response mode, and we're not yet sure how to map that to long-lived stateful connections - it's something we intend to figure out but haven't done so yet.
(Please forgive me if I'm using the wrong terminology or concepts - I don't know much about gRPC and may be thinking about it in too REST-ish a way - I'm happy to be educated!)
We're definitely open to collaboration. Let's see if we can use this issue to rough out a set of features and then figure out how to take it from there?
yes if you want we can work this step by step and see what can be achieved. We can consider a basic example and see which limitations we run into.
gRPC (Google Remote Procedures Calling) is an alternative client-server architectural pattern to REST, a read-write stream is opened between client and server and all data exchanges are serialised using ProtoBuffer, an highly optimized format. It is massively used for high-throughput services (like in my case, potentially very large matrices), like for cloud Machine Learning services.
The whole thing works on HTTP/2 so yes every connection is long-lived. Basically the server makes available some RPC endpoints, the client call endpoints submitting some data and the server responds, basic calling is quite like REST but with a different architecture that uses continuous streams instead of request-response cycles.
In Rust there are different libraries to build this stack:
- a web layer (usually
tokiobut maybe we can make it work with a sync server) - the serialisation library for
protobuf(usuallyprost) - a library to translate protocol declaration into Rust code for services (
tonic)
I can be interested also in different client-server solutions that allow submitting and returning large arrays. I mean this is what I came out with but there may be alternative efficient ways for this use-case, feel free to suggest.
Thanks for your attention.
Hi @itowlson, I agree with @Mec-iS that this would be a great feature to add! Could I ask where this might sit in the future roadmap for Spin?
There are a couple of ways that Spin could support gRPC:
- via the normal HTTP trigger interface: this could probably work today, but the feasibility and difficulty of it will depend a lot on the guest language and gRPC library
- via a new gRPC trigger type: this would be cool but would take quite a bit of work that isn't currently planned
- (soon) via component adapters: once we land support for components (currently in progress), it should be possible to generate an "adapter" component that speaks the normal http trigger on the "outside" and a generated WIT interface on the "inside". This would still be a significant chunk of work but its something I've been thinking about for a while.
Any progress on this? Would love to use GRPC as well on spin I feel like this would be a great add on
