Should You Run An Entire Web Application in AWS Lambda? 

100% agree. More content about the lith coming in the next few weeks. Thanks for the comment.

Kind words indeed, thankyou ☺️

tomorrow I definitely give you a tip, as soon as my card is approved

I'm glad you've found the content useful, thanks 🎉 any follow up questions feel free to reach out.

Thankyou 🫂♥️ I'm glad you liked it.

Glad you liked it!

Thanks 👍

Ask Ben Pyle his opinion, I'd guess he would take Rust over Go now. It's a brilliant language.

When you say this doesn't require any frameworks in the functions, are you manually implementing the routing then? So if someone calls GET \authenticated\users and POST \authenticated\terms you have manually written all the routing logic?

Hi @serverlessjames, "routing" is not necessary for my REST API example. I see an API request as a simple asynchronous function call. Lambda is a function with a parameter ("invokation" event). API Gateway forwards all necessary details including a resolved cognito user or identity to the Lambda handler (JSON). In my handler, I simply extract method (e.g. "GET"), params ("model", "id", etc.), body, and requestor from the invokation event. each "model" (=endpoint) then matches a subfolder in the lambda each subfolder has a "config.json" that defines the valid request format, and an "action.js" file with the business logic. (I also have some shared folders for shared components, for example, a dynamodb connector, a cognito connector, etc.) any request that doesn't match a model is denied, and any request not validating against a config.json returns a detailed error response. I can use the config.json for basic access control using AWS cognito groups with this pattern, I can easily define the output model based on the input model. e.g., "POST /events" can return individual results based on requestor/role, combine data from different sources, enrich results, or orchestrate side effects. it dramatically simplifies the frontend adding a new endpoint to the API is simply adding another "model" folder with action and config. I put this together when I first looked at AWS Lambda in 2016 and have been using it for production web apps for the past 7 years, works great. I also use lambda for server side rendering, with the NodeJS function using ReactJS to return rendered HTML instead of JSON, using the same pattern.

Interesting, seems a valid approach. But you have built a custom routing framework inside your function...? Albeit routing based on a custom model and function folder that comes in.

​@@serverlessjames here's my handler logic for this example: // simplify invokation event const request = map_request(event); // validate request based on config const [is_valid, validation_errors] = validate_request( request, model_configs[request.params.model], ); if (!is_valid) { return response_error( null, "request validation error", validation_errors, ); } // execute request const execution = actions[request.params.model][request.httpMethod]; const result = await execution(request); return { statusCode: 200, headers: { "Access-Control-Allow-Origin": "*", "Content-Type": "application/json", }, body: JSON.stringify(result), }; I am using ajv to validate the json models in validate_request(). const execution = actions[request.params.model][request.httpMethod]; I import all actions from all subfolders into actions upfront to simplify. I used to use the file system and import only the model for the current request but it's slightly slower and requires more configuration for build and pack. obviously I pack my functions just like I'd pack frontend React.

​@serverlessjames, here's my handler logic for this example: // simplify invokation event const request = map_request(event); // validate request based on config // uses ajv const [is_valid, validation_errors] = validate_request( request, model_configs[request.params.model], ); if (!is_valid) { return response_error( null, "request validation error", validation_errors, ); } // execute request const execution = actions[request.params.model][request.httpMethod]; let result = await execution(request); return { statusCode: 200, headers: { "Access-Control-Allow-Origin": "*", "Content-Type": "application/json", }, body: JSON.stringify(result), }; I import all actions from all subfolders into actions upfront to simplify. This line would be your "router framework" if you will: const execution = actions[request.params.model][request.httpMethod]; I used to use the file system and import only the model for the current request but it's slightly slower and requires more configuration for build and pack. Obviously, I pack my functions just like I'd pack frontend React.

This is absolutely a valid point, and ECS + Fargate is a great way to go. And it will be needed for a whole range of use cases. I know in the video I say you'll see less cold starts, but 6s is a looooooong time.

It's a great question. In my contrived example I'm assuming each request comes in sequentially. So the 2nd doesn't start until the 1st is finished. In that scenario, then the execution environment would be re-used. If all 3 requests hit the API at the same time, then yes you would still likely see 3 cold starts. But over time, you'll definitely see less cold starts than 3 separate functions.

@@serverlessjames OK, I think I understand what you're saying. So, in your example we are assuming that the time between each of the the three requests is short enough that the lambda is still "warm" and thus is reused for the next request? How long will an unused lambda stay warm? BTW, thank you for taking the time to respond!

@scrawl281 yes exactly! Which I realise is a big assumption, but it's the easiest way to demonstrate how it can be beneficial. There's no defined SLA for how long an environment stays warm unfortunately.

@@serverlessjames Perfect. That clears it up for me. Thank you!!