srijs
commented
5 years ago Quick feedback on this as well, I generally like the idea, but relying on Vec<u8> to this extend may be a bit restrictive and might hinder attempts at reducing or re-using allocations.
(How much these types of optimizations are really desirable or necessary, I will leave that up to you. Personally when I need that kind of sustained high-throughput performance I tend to opt for something different than serverless, but I could also imagine folks wanting their lambdas to be as efficient as possible.)
I really like what hyper has been doing in this regard, where the Payload trait allows implementers to bring their own buffer types as long as they implement the Buf trait (if you want to avoid a dependency on bytes this could perhaps be replaced by AsRef<[u8]>).
For instance, the proposed trait could be transformed into:
pub trait Handler<Error>
where Error: Display + ErrorExt + Send + Sync
{
type Output: Buf; // alternatively type Output: AsRef<[u8]>
fn run(&mut self, event: &[u8], ctx: Context) -> Result<Self::Output, Error>;
}This allows for a couple of things:
- For input data, the runtime-core package can maintain ownership of the input event buffer, and is not forced to allocate a
Vec<u8>in order to pass it to the runtime package. Since it's usinghyperunder the hood, this could mean just creating a reference to the bytes insidehyper::Chunkrather than copying them. - For output data, the runtime is free to choose a buffer type that works best, potentially allowing for zero-copy serialization.
sapessi
softprops
At the moment the AWS Lambda rust runtime is composed of two crates: The Runtime Client and the Runtime. The runtime client implements a client SDK to the Lambda runtime APIs, taking care of all the communication to the runtime endpoint to receive new events, send responses and errors. The runtime implements the “main loop” of a function's lifecycle: call
/nextto receive the next event, invoke the handler, and then post responses or errors to the relevant endpoints. The runtime client SDK only deals with byte slices and does not understand types; the runtime crate, on the other hand, expects the event and response types to be serializable/deserializable with Serde.We have received requests to handle multiple event types in the same Lambda function (#29) as well as abstracted implementations that abstract the event into a well-known type in rust, such as the HTTP crate (#18). To make it easier to extend the runtime and support future use-cases, we propose to split the Rust Lambda runtime into three separate crates:
/nextendpoint and posting responses. Expects a handler that only deals with byte slices.The runtime-core crate will declare this handler type:
The typed runtime will declare the same handler type as now and wrap the run method to perform the serialization/deserialization before passing data to the core crate.