I am suspect of this approach, but I remain open minded

It probably is useful for people with worse IAC setups

It is also the simplest way to invoke your Lambda functions during research and development without leaving the Lambda console or integrating additional services

Yeah, I bet that never gets abused in a production scenario 😆

This is basically just an invisible Proxy Lambda w/ HTTP API

ANY *

but I'll be honest I still really like that for simpler cases. Only downsides near as I can tell is just public by default

Its not just an invisible proxy… its a free invisible proxy As someone who puts all our apis behind Fastly anyway, this is great for us. (replace fastly with any other cdn)

That's true. That's basically our thought process, for services we're mostly just exposing as-is internally or behind a shared gateway/front this is pretty nice

is it any faster than putting it front of apig?

As in faster to stand up or is the question about Fastly -> Lambda?

I was wondering about latency

The more I read the docs, the more I think https://serverless-stack.slack.com/archives/C01HYQRUGG6/p1649284153117589?thread_ts=1649281783.216619&cid=C01HYQRUGG6 is pretty accurate in that there's an API Gateway there, you're just not managing it or seeing. The magic url seems to literally be

https://<api-g-id>.lamda-url.aws.stuff

yeah I figured that was the easiest way for them to implement it internally, makes sense

So I'd guess perf is comparable to ApiG v2 proxy, but I have no hard data to back that up

It seems like the evolution of a publicly exposed endpoints would go Function URLs -> APIGW2 -> APIGW1, depending on the features you need

Yup, it makes a lot of sense. Gets them parity with other providers who already provide direct http, codifies a common use case, and still has a natural path back to full ApiG if yah need it

Although, I guess it doesn't necessarily need to be public. IAM is an option for Function URLs

I'm wondering if it makes sense to have an sst.FastlyApi concept where it provisions a fastly cdn and creates routes to your function urls

@thdxr This is exactly what we do internally. We have our own fastly setup scripts that read the output of the APIG url and use it as origin for fastly. We will definitely be testing latency of the new function url, but I doubt its any different since im sure AWS just using http api behind the scenes (which is what we already use as fastly origin)

I'm curious what the latency improvements you see over using fastly vs without it right now

I can report back but its not an easy comparison. We do http3/0+RTT over fastly. Thats a massive latency improvement right there. SSL back to origin (and no 0+RTT) is super slow relatively

ah I see

This actually answers a lot https://www.serverless.com/blog/aws-lambda-function-urls-with-serverless-framework

I'm honestly suprised there's a difference, but that's neat!

how accurate is that lol, seems like that's within an error margin

The bump from 29s timeout to 15 minutes is pretty awesome

Def margin of error, and I wonder if they're tweaking the work they did for HTTP v2 to remove unused bits from the pipeline even further

The timeout being increased is interesting, I wonder why that doesn’t apply to the HTTP API.