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?

[asotoglez]

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).

[bnol]

Hi. Any updates on this?

[alexcroox]

Has anyone found a workaround yet? I'm still spawning a server manually locally at the moment but would love to use serverless-offline instead

[DavidVaness]

currently facing the same problems - would be interested in a workaround as well

[QAnders]

currently facing the same problems - would be interested in a workaround as well

#1382 (comment)
That's the work-around we are using, locally, running as stage offline we spin up a "Serverless Offline API" to be able to test. You can use the same Authorizer for it and it behaves the same (same event structure)

[DavidVaness]

okay, this is basically the same as this no?

{
  handler: `${resolvePath(__dirname)}/handler.default`,
   url:true,
  ...(isOffline && { events: [
    {
      http: { path: 'render', method: 'post' },
    },
  ]},
};

[vanderAries]

Hello, any updates in serverless-offilne about official Function URLs support?

[serg06]

AWS has just released Lambda Response Streaming which only works with Lambda Function URLs, so this feature would be very useful!

[MarioSimou]

I have built this plugin as a termporal solution. It works okay for my case. I am running a secondary server that exposes the url functions as HTTP endpoints

[guhyeon]

Hi~ Any updates?

[alexcroox]

@grakic did you make further progress on supporting Lambda Function URLs?

[asychev]

+1

[mridang]

I have built this plugin as a termporal solution. It works okay for my case. I am running a secondary server that exposes the url functions as HTTP endpoints

At this point, I think it is fair to say that the paths of this project and your have diverged. If something as important as this isnt moving ahead, an alternative project is on the way. I'll make some upstream commits your project. Good job. 🙏🙌

[asychev]

Are there any plans or ETA?

[DavidVaness]

Are there any plans or ETA?

Just use my workaround from above, works flawless