The Easiest Way to Create Serverless APIs in .NET 

@Nick Chapsas congratulations, you even have s(p/c)ammers impersonation you! You've truly made it.

nice. i still need to use contain apps, i forgot about all the KEDA goodness

hey i was testing this and i just found out a little bit of a block, im kinda new to conatiners and i was reasearching a bit, and the container app sounded a nice thing, i saw i needed to use a repository and those cost money, so whats the advantage of using something like the container app with a free tier and a container registry that costs money I mean over the azurefunctions or the lamda functions or am i missing a lot since i dont know much about containers.

@@KhauTek good question. I'm not an expert, but I suspect it depends on your use case. Surely, Functions are using the registry under the hood as well, and per-invocation they might be pricey at high volume. The Basic tier of the registry is $5/mo, and a typical Azure sign up will net you $200 in credits, so you could go for a long while with that. But I might be missing some important facts - does the free tier of Container Apps include the registry? Can you substitute an alternative registry from elsewhere?

Yes, unfortunately been burned here already. Its just not usable for public facing things without a lot of micro-optimizations and many code/nuget restrictions to get the cold start time down, even with ReadyToRun. Unfortunately including the AWS SDK already balloons the cold start time to a pretty high baseline. General rule of thumb is "magic", DI, reflection and libraries are going to push your cold start time up. Lots of shared code will also push it up.

Did you try AOT?

I've been using ASPNET dotnet APIs in AWS Lambda for over a year now. The cold starts average to 1.4 seconds when runing 1536MB. That's acceptable for my API. These are cold-starts mind you. So once there are a handful of lambdas running, they are a non-issue. YMMV depending on what your customer needs dictate.

You better respond to my comment Nick!

I have not

I'm intentionally using the old one 😂

@@nickchapsas okay got it :)

I saw your comment and tried the new one, and then I went back to the old one 4 min later 😂

@@richardarielcruzcespedes9455 i've had it for 5 minutes and still using it :D

@@richardarielcruzcespedes9455 why so?

Because it wouldn't make sense and thank god they did them. Controllers are just one of the paradigms and its also an MVC one. It wouldn't make sense to have an IActionResult when there isn't the concet of a traditional Controller Action.

​@@nickchapsasapologies, but I still feel it would make sense, especially given your video showing conversion of a controller to these new annotations. There's a one-to-one correspondence for the AWS annotations which made that an easy process. Why not let an MVC specific extension to these source generators do that conversion for me? There's also already official library support for mapping the MVC request pipeline and IActionResult execution onto lambda execution contexts.

You should have a separate service for SignalR Hub. In Azure it could be Azure SignalR Service. Your server-less function should communicate with this hub instead of owning it .

@@slepcu i see and that server-less function have to run 24/7. And we cannot use IHubContext. so every other server-less function that want to access hub will have to make separate HubConnection and then destroy it. Frequently creating and destroying, Is this good approach ? or there is a better way around this

In AWS you need to use the API Websocket Gateway. Currently, this does not directly support SignalR. You can hack it to work, but its easier not to and just use the AWS Lambda/API Websocket Gateway stuff. WORD OF WARNING: If you are using SignalR, this implies its a public facing API. dotnet is NOT ready for building public facing APIs with Lambda, the cold starts are too severe. Choose something with a good cold start time, there are plenty good options. Don't make the mistake of getting close to launch and realize you have a major problem that's going to require rewrites.

+1 byniu

Doesn't that run an actual long running host behind the scenes for the function? This is quite different. AWS does this with the equivelent of the in-process Azure Function approach. AWS Lambda does also allow you to run your actual ASP.NET APIs with the same approach but this is quite different and I've shown that in a different video. Also as far as I remember, isolated worked process still uses the HttpTrigger attributes with the HttpRequestData request object and the FunctionContext. Can you map route parameters, query string patameters and request objects/bodies in the same way?

@@nickchapsas - in general dont understand why HTTPTriggers is bad? Aren't we try to use using Functions to work as an API, so why is http trigger is bad? - As for isolated process, it's considered to be a future and if we will look at the azure functions road map from microsoft we will see that inprocess will be deprecated. Isn't the idea of isolated a better approach so we could separate our functions code from the host itself? 1. Route parameters they can be binded in the function declaration and is easy to do something like this public async Task UpdateUserProfile_v1([HttpTrigger(AuthorizationLevel.Anonymous, "put", Route = "v1/users/{id}")] HttpRequestData req, string id) 2. Getting request body, request validation, get request data from headers, etc it's a oneliner of infrastructure code as an extension method to HttpRequestData and is not bothering at all and is written one time at the beginning of the project. Also you have full control of middlewares where you can do whatever you want. 3. For isolated functions the approach is to return HttpResponseData instead of IActionResult.

They are not built and discarded on every request. They are built before they are deployed. Then you first call them they are "started" from a cold state which can take some time because they need to be loaded and run. After that they are kept in a "warm" state where you can call them and they will return pretty fast because they are effectively running. After not being called for some period of time (around 15-30 minutes) they will be "unloaded" and you'll have a cold start again but only on the first call.

The start/stop behavior of lambdas isn't all documented because it is considered an "implementation detail" subject to change, but we can observe some behavior and get some insight. When the first request comes into lambda, it is "cold", the request runs and now an instance of your lambda is "hot". The instance will remain "hot" until it is idle for an undefined amount of time (15-20min in practice). AWS also will randomly kill hot lambdas, probably while shuffling around resources (not something you control). If you are under load, you will also experience multiple cold starts as AWS scales your lambda up. 10 concurrent incoming requests = 10 cold starts etc.