You will be able to shortly, yes. I've got an open PR in the Lambda tooling to enable it. I've done some tests with a local build of the libraries though, and it's looking fast 🔥
Yes, absolutely. The format of the input event will match the API Gateway HTTP API request. If you follow the instructions on Bryan's blog to build to function, and then these instructions for native AOT you'll be in the right place. nodogmablog.bryanhogan.net/2022/08/simple-lambda-function-with-a-function-url/
@@serverlessjames Thank you! It would be awesome to get EF Core compatible/with trimmed friendly code for AOT. Hoping it will be possible in .Net 8. Any idea if there is a AOT friendly ORM for .Net out there.. That would be awsome!
This is a great idea for another video 🎉 I do have a video on my channel on Unit Testing with Lambda. My normal debugging approach is to run my unit tests in debug mode and step through my function code that way.
@@serverlessjames I just installed the templates, tried to run this through debug and I get "System.UriFormatException: 'Invalid URI: The hostname could not be parsed.'" Any ideas on how to get this to debug locally?
Compared to the .NET 6 managed runtime the P50 cold start execution is 70% (778ms to 372ms) faster and the P99 86% (1470ms to 581ms) faster. Once warm the difference is about 10%. Compared to .NET 6 native AOT then yeah the numbers are pretty similar.
Awesome video. Have you seen an error like this when deploying? dotnet\sdk\7.0.100\Sdks\Microsoft.DotNet.ILCompiler\build\Microsoft.NETCore.Native.Publish.targets(58,5): error : Cross-OS native compilation is not supported.
Yep, what OS are you compiling on? It might also be worth looking at a later video that covers the SAM tooling which simplifies a lot of this work. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-n21p5Ezlx28.html
@@serverlessjames Ah cheers James I actually watch that video aswell and decided to give the SAM cli a try. Funnily enough after installing that the dotnet tools started working. On windows. Do you work directly for AWS. I have a couple of clients one of which at the moment are having a major reshuffle and rebuild of their system. We had a beautifully orchestrated micro-service system that was just getting hit hard between cold start and connecting to DocDB. As POC built a few bits in rust on Grav but there predominantly .NET so I was quite excited when Native AOT templates were announced.
@@ianknowles yeah, it could have been an outdated version of the tooling or something like that ☺️ Yes, I do work for AWS. what kind of cold starts are you seeing?
@@serverlessjames Possibly outdated but I did run the tools installer as prompted then templates shown up in VS. As for the cold starts 1.3-2.0 seconds on lambda execution .NET 6 (ready-to-run) with the usual AWS Core, Dynamo, EvBr and S3 clients. DocDB first connection taking a similiar amount of time to connect with the mongodb client. But when your 4 levels of invocation deep those delays compound heavily. A lot of the first requests were taking upto 30s and timing out (sub second on subsequent requests). So we opted to role 8 UX related lambdas into one monolyth so they could share connection. May have to move to something like ELK as we need full text search and regex on mongo style filter is underwhelming if your across more than 10k documents but if you have any ideas on how to remedy then all ears. PS I suspect your reasonably local south of manchester?