Support for Lambda Function URLs?

[bnol]

Feature Request

Lambda Function URLs have been officially released!

https://aws.amazon.com/blogs/aws/announcing-aws-lambda-function-urls-built-in-https-endpoints-for-single-function-microservices/
https://docs.aws.amazon.com/lambda/latest/dg/lambda-urls.html

Any plan to support this?

Thanks

[ixartz]

I'm also waiting for Lambda Function URLs support in serverless-offline. The official Serverless Framework supported as well: https://www.serverless.com/blog/aws-lambda-function-urls-with-serverless-framework

[akinboboye]

I will start taking a look at this from this weekend.

[bnol]

hi @akinboboye , could you share the progress?

[hilaryosborne]

any progress on this? otherwise, would it be worth putting together a PR? looking at the AWS documentation a function URL is invoked with the same request and response objects as api gateway. would it be a matter of reusing some of the existing logic to mock http gateway endpoints?

[abdennour]

I will start taking a look at this from this weekend.

Did you start taking a look @akinboboye ?

[alexcroox]

I am also looking for this feature, is there a work around for now? For example having a function that still uses events: - http: just for local/offline usage.

[skyler-sidner-improving]

Bumping this, because my team would benefit tremendously from the addition of URL support.

[EliBates]

Would love to have this feature as well. Any updates or workarounds?

[alesoto13]

any updates?

[dnalborczyk]

My plan is to add support for this in the next coming months - if no one beats me to it.

just skimmed over the docs and it appears that AWS is creating a URL for each function url with any path invoking the function handler. I would imagine that means we would need to create a service with a port for each function url. if someone would define more than 1 function url we would need to assign multiple ports. alternatively, or in addition, we could use one specific port, with the function name defining the path by convention.

functions:
  foo:
    handler: handler.foo
    url: true

  bar:
    handler: handler.bar
    url: true

could create

localhost:3003
localhost:3004

and/or

localhost:3003/foo
localhost:3003/bar

[j0k3r]

could create

localhost:3003 localhost:3004

and/or

localhost:3003/foo localhost:3003/bar

Or maybe using an option to determine which method the developer wants.

[QAnders]

Any updates on this?
We are using a bunch of micro-services and the Lambda Function URL, while great as a function has put some hurdles for us developing and testing...

We have moved to use Localstack to be able to run local tests but it's a hassle to develop still... We are now doing kind of an "ugly-fix" for it where we, developing as offline stage add a API GW (Serverless Offline), but in Localstack (local) and the AWS env's we add a Function URL, like:

custom:
  addHttpOffline: # Only used for local testing (offline) as Lambda URL is not (yet) supported by Serverless Offline
    integrationInternal:
      prod: ""
      qa: ""
      test: ""
      local: ""
      offline:
        - httpApi:
            method: '*'
            path: '/integration/internal/{proxy+}'

functions:
  integrationInternal:
    handler: src/integration/handler.internal
    description: Internal integration endpoints.
    url:
      authorizer: aws_iam
    events: ${self:custom.addHttpOffline.integrationInternal.${opt:stage, self:provider.stage}}

This way we can spin up Serverless Offline in development and still have a HTTP endpoint but it doesn't really feel that clean...

[QAnders]

could create

localhost:3003 localhost:3004

and/or

localhost:3003/foo localhost:3003/bar

I'd prefer the second approach and run it on the same port as Serverless Offline. We often have a combination of API GW (external access) and Function URL for internal access and it would be more convenient with one port and an URI prefix for Function URL's, like (where fucould be a editable parmeter):

localhost:3001/  //<-- API GW
localhost:3001/fu/function1/  //<-- Function URL for "function1"
localhost:3001/fu/function2/  //<-- Function URL for "function2"

Sure, it's more to keep track of as a developer, but as Serverless Offline already prints out the URL's at startup I think it would work nicely, and I'd be happy with it!
In any case, deployed in AWS you still have to keep track of the individual Function URL's through some variable (e.g. SSM).