slow builds & deploys, dotnet AOT, testing, + lambda architecture design -- cold starts?

[maceip]

a few discussion items:

1. how can we test the dotnet functions without deploying them? Deploying is super slow (10+ minutes)
2. what is the AWS / dotnet / CDK way of incrementally deploying one lambda quickly? cdk deploy takes so long I am tempted to use something else
3. when looking at xray, with about 5 active users, 70% of the lambdas are cold starting every invocation. Why?
4. why not use dotnet AOT:

    <PublishAot>true</PublishAot>

• https://github.com/awslabs/dotnet-nativeaot-labs

5. why lambdas? e.g., every time a user sends a message it spins up OnMessage.

[santatamas]

Hi! Thanks for the questions! Lots to unpack here :)

1. You can still write unit tests for your lambda functions and run them locally. You can also use a local DynamoDB container, in case you'd like to write an integration test.
2. I'm not aware of any CDK capabilities that would support this. However, you can use the AWS CLI to manually update the lambda code package. This is an excellent article that covers this scenario (although it uses Go as an example).
3. This should not be the case. Please note that AWS X-Ray by default only samples 5% of the total amount of requests. Looking at the Lambda's cold start CloudWatch metrics would give you a much better insight.
4. Turning on AOT can cause run-time errors and today not every library is compatible with AOT compilation. The simple reason for not turning it on in this project is playing it safe. I need to test the entire application with AOT turned on, before I'd recommend using it. This is something I'll work on this year.
5. Using a serverless computational model here results in better scalability, operational simplicity and (significantly) lower cost. You could pick a different request integration (like HTTP) and serve that from a running container instance for example, however in this case Lambda is the best service for the job.

I hope this helps! Please let me know what you think and if you have any further questions!

[maceip]

thanks for your thoughtful answers here -- i'm learning more every day!

I'll need to check at the latency for OnMessage(); it just irks me to wire up a websocket to a (potentially cold) lambda function.

My only contribution at this point would be using a QueryParam authorizer for the websocket API gateway. My reason for implementing this was pure js websocket code can't easily add a cookie with the id_token, but it's easy to add it as a query param:

`wss://api/prod?id_token=${session.id_token}`