aws-lambda-go

FWIW, Lambda takes the opposite of your assertion: there are function entrypoints and the HTTP or gRPC or Stdin is an implementation detail; one can see that in practice via the golang lambda "bootstrap" shim <https://pkg.go.dev/github.com/aws/aws-lambda-go@v1.49.0/lamb...> which is invoked by the Runtime Interface Emulator <https://github.com/aws/aws-lambda-runtime-interface-emulator...> I don't have the links to Azure's or GCP's function emulation framework, but my recollection is that they behave similarly, for similar reasons

Is that build tag necessary? I should check out what it does, because I've been deploying Go functions to custom runtimes without it. Does it skip some kind of "determine if Go-specific RPC or custom runtime" check? EDIT: I found it. Thanks for the tip! https://github.com/aws/aws-lambda-go/blob/1f782848d89c02bf80...

Judging from five minutes of browsing the go runtime sources, they poll some lambda API: https://github.com/aws/aws-lambda-go/blob/159d1c69878562cd54... The response is apparently posted to another API endpoint. Googling for the environment variable actually specifying the API endpoint, I found https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom... which seems to spell out some of the details. Of course that just moves the question to "where does the runtime API get the event from?" but at that point they could be doing all kinds of things, I guess. Now I'm curious to see what happens if you ask for more events before returning a response for the first event you got. Can you actually process events in parallel?

I don’t see anything in the example to indicate that the closure pattern for Swift Lambda handlers actually allows true async. func lambdaHandler(event: Event, context: Context) { // your lambda handler logic... } What’s wrong with this approach, which is how lambda handlers are written in every other language with the exception of JavaScript - let’s not pretend that JavaScript is a good language design reference. Look at this Go example In comparison... simple, readable, intuitive: package main import ( "fmt" "context" "github.com/aws/aws-lambda-go/lambda" ) type MyEvent struct { Name string `json:"name"` } func HandleRequest(ctx context.Context, name MyEvent) (string, error) { return fmt.Sprintf("Hello %s!", name.Name ), nil } func main() { lambda.Start(HandleRequest) }

I'm not sure, I copied that from the aws/aws-lambda-go repo https://github.com/aws/aws-lambda-go

Implementing a Go lambda is already more complicated than writing a function. It requires binding to a TCP port and receiving gob encoded values. AWS released a library that abstracts that into // main.go package main import ( "github.com/aws/aws-lambda-go/lambda" ) func hello() (string, error) { return "Hello ƛ!", nil } func main() {

It looks like the compiled binary just gets exec'd by the Lambda function and listens on a TCP port (specified by the environment variable _LAMBDA_SERVER_PORT) which accepts RPC calls to execute the handler using net/rpc. The code: https://github.com/aws/aws-lambda-go/blob/master/lambda/entr...

Looks like the "Go support" is just running a precompiled binary that starts a TCP listener (https://github.com/aws/aws-lambda-go/blob/master/lambda/entr...), so might not be that hard to port...