How does SST run Go lambdas locally? Can the mecha...
# sst
d
How does SST run Go lambdas locally? Can the mechanism expand to include custom lambda runtimes?
Haha, there’s so many channels related to questions. Was hard to pick one, but hope this post here is relevant enough
f
Hey @Dennis Dang, SST starts up a local Runtime Server, and the Go lambda function calls the Runtime Api to get the event
Yeah, it should work for custom runtime.
What use case do u have in mind?
d
There’s another lib in Rust that we’d like to use and still enable the nice live lambda dev feature. Availability in lambdas is essentially our first (and welcomed) constraint.
Is the integration work doable? If your team can't do the integration since it’s a linear effort per number of languages, a general guide/spec to do so would be immensely helpful.
f
Ah got it! There are 3 areas of work to implement a new language: 1. in
sst deploy
we need to build the Rust functions; 2. in
sst start
we need to run the Rust functions on request; 3. in
sst start
we need to watch for changes and rebuild the Rust functions quickly I don’t know Rust, but if you could help me on #1, that’d be great. #2 and #3 should be fairly straight forward. For #1, here’s the code for building the Lambda functions - https://github.com/serverless-stack/serverless-stack/blob/master/packages/resources/src/Function.ts#L215-L241 It’s pretty short. Python is built inside Docker; Node and Go are not. We just need to add another case here to handle Rust. Let me know if you want to take a crack at it and submit a PR.
d
Can I create a gh issue to track work and discussions? Some points to discuss: 1. Supported runtime variable - Rust require the use of the custom AL2 runtime. It’s a constant value available like the other ones but if i add this builder, it doesn’t necessarily mean the rustBuilder will work for other languages. 2. WIP
f
For sure! Let’s create an issue for this. I’m thinking we define a new runtime name ie.
rust1.x
or something, and you create the function like this:
Copy code
new sst.Function(this, "MyRustFunction", {
  srcPath: "path/to/Cargo.toml",
  handler: "path/to/lambda.rs",
  runtime: "rust1.x",
});
And internally we will use
provided.al2
runtime to create the lambda function. What do you think?
d
Perfect I was thinking around that line too. The rust builder api should operate similarly to the Go one.
For my Go lambda, I've used a whole directory with a
main.go
entry point for a lambda (package main). Does the Go builder support passing a handler with a different name. i.e.
some_handler.go
with
package main
. I ask because building the Rust lambda probably brings with it the same constraints. Can't nicely pick a fn export like Node can.
f
Yeah, I think it does. If handler is just
src
, it assumes the file is
src/main.go
. But u can specify a different file
src/some_handler.go
with
package main
.
I’m not doing anything for this, i think it’s the default behavior for
go build
command
d
Hey Frank, I found a workaround so we no longer need the Rust implementation! Info is still good to know. Perhaps I'll still do one for Rust or other.
f
I see. If you guys need Rust runtime again, let me know. It is something on the roadmap.