Just for reference, here is an example of what a Rust fn looks like on Zeit Now:
It looks like we could use the into_response() on the Reply returned by a filter to get the compatible http response. Now getting the request I'm not sure on just yet.
Ideally, tower::Service could be used as the point of abstraction (it is designed for this). Hyper plans on adding support for Service as well.
@carllerche Gotcha! I will look into that.
Hi, I'm a co-maintainer of the Lambda Runtime for Rust! There's no real blocker for us to support things like Warp鈥擨 just haven't invested enough _time_ to support that feature. We currently expose types pulled from hyperium/http, but there's no reason our lambda! can't be a Warp service.
(@sapessi or @softprops might also be able to comment)
The idea behind using http is that the http crate is a standard set of types uses across rust crates with the intention that anything that uses the standard http types would work with the lambda http crate for free.
I feel like making the types more specific to a given framework really breaks that flexibility and limits its use to say that particular framework.
Lambda being lambda encourages leveraging of the platform you're running it on to remove the need for a server framework: api gateway is tcp listener, routing, auth, ect. The abstraction lambda is pushing is that a function is really "just a function", not necessarily a full on server application. Not using what the platform provides decreases the value that you get out of using it.
My concern with pushing for a server framework inside a function is pushing the the idea that, not only that you can but you should. I don't agree with the "should" portion unless you have very special needs. I don't believe lambda for rust should prevent the "could" case though. That's where the lambda http crate comes in. Assuming various frameworks that support the http crate types, it should be enable the "can".
If possible something like a separate crate for warp or tower or whatever comes next would be useful for special needs would be best.
This isn't really about pushing a server framework into a serverless function. Warp is a very special case that allows us to parse a request and prep a response in a composable, reusable fashion. In fact, I suspect Filters can be used alone and then hooked into a serverless context quite easily.
In other words, we don't really need the _server_ part of warp, just the filters with a common/compatible abstraction.
I think a separate crate could be adapted for that need. Api gateway provides pre-parsed requests in the form of events, the lambda http crate just deserializes them into the standard http types.
@softprops Are you talking about AWS lambda or Zeit? I don't know enough to see the difference yet.
Im talking about AWS lambda. I'm not super familiar with Zeit. My impression is that its akin to serverless framework, its a tool for fast deployment oriented workflows and uses lambda as a deployment target
Okay, I was thinking about Zeit then. Given their example, I would assume it's the raw request and not an event.
It seems like a good idea for lambda to stick with just http.
There's plans (though been stalled while working on Tower pieces) to allow turning a Filter into a Service, and then you can just run the Filter on any server (almost, currently warp requires hyper's body type to be able to provide the websockets support, but details schmeetails).
@softprops What are your thoughts on using the Service trait here: https://github.com/tower-rs/tower/blob/92f4a0cb729a82df01086fa3c8e0e4dd80d36947/tower-service/src/lib.rs#L180-L217
It seems closely related to your model and is built to be decoupled from any specific framework.
sry I'm losing context in the questions.
I think that you could definitely run something like warp or tower inside lambda since they both accept http type, I cant see a reason why you couldn't just wrap the req/resp lambda provides in a tower/warp container thats exposed to users.
I kind of see those living in the space of adapter crates, potential for warp filters and tower services. I'm a strong believer with lambda that smaller runtime makes for noticeably faster deployments and makes it easier for lambda internals to download from s3 when a lambda worker needs to spin up a new task. I think for users benefit the less is better until you need it is a good approach. I'm also a strong believer that making it special needs possible is also important. I did the leg work on the initial approach towards exposing http types as first class citizens with the though that more and more of the community would be using them as a standard interface. Anything on top of that should really be a user choice based on need but shouldn't be included if you dont need it. Lambda functions, for from my experience at least, as worked best when you travel light. The provider is where the middleware and scaling comes from, not necessarily the application.
This doesn't really add a lot to the conversation but I would just like to note that it is possible to run Warp on AWS Lambda by (ab)using Warp's test module. Like this. It's definitely a horrible way to go about doing it but it (kinda) works.
Question:
Now that there is warp::service(filter) that returns a FilteredService which implements hyper::service::Service. And hyper::service::Service is tower_service::Service being re-exported in hyper.
And awslabs/aws-lambda-rust-runtime lambda-http crate now have handler(handler: H) function that accepts implementation of Handler trait.
Is it possible to implement the Handler trait for FilteredService<F> and use in the lambda-http's handler() function? Or, more specifically, is it possible to make warp work with lambda-http?
If, yes what is the approach? Does it require changes in warp or lambda-http?
If, no why? And do you think it is not possible at all in its current state?
An implementation of lambda_http::Handler for warp::service(filter) - https://github.com/aslamplr/warp_lambda/blob/3aa5bab204fb3a851164fc0fb465999e43fec102/warp_lambda/src/lib.rs
How it is used - https://github.com/aslamplr/warp_lambda/blob/3aa5bab204fb3a851164fc0fb465999e43fec102/src/main.rs
I just started work on this, excited to share!
An implementation of
lambda_http::Handlerforwarp::service(filter)- https://github.com/aslamplr/warp_lambda/blob/3aa5bab204fb3a851164fc0fb465999e43fec102/warp_lambda/src/lib.rsHow it is used - https://github.com/aslamplr/warp_lambda/blob/3aa5bab204fb3a851164fc0fb465999e43fec102/src/main.rs
I just started work on this, excited to share!
Excited to share the repo - https://github.com/aslamplr/warp_lambda
Looking forward to getting the latest awslabs/aws-lambda-rust-runtime stabilized and released to get this crate released to crates.io.
Most helpful comment
Excited to share the repo - https://github.com/aslamplr/warp_lambda
Looking forward to getting the latest awslabs/aws-lambda-rust-runtime stabilized and released to get this crate released to crates.io.