AWS Lambda and Angular

AWS Lambda is a tool which is part of AWS's Serverless tool set. It allows content creators to focus on the code which drives their content, and not need to worry about configuring or maintaining the servers where the code will run. This post reflects on my experience integrating AWS Lambda with an Angular app, and some of my learnings from this mini-project.

How can it work with Angular?

Angular is a front-end platform, so it doesn't need any server-side scripting on its own. However, if you want to build complex web applications and follow multitier architecture, you will eventually need something to process your business logic. This is where AWS Lambda comes in - instead of building a web server to host your presentation code, and an app server to host your business logic, you can store your static content on S3 (refer to my previous blog post on running an Angular site on AWS for more info on this), and create a Lambda function to run the business logic.

To test this out, I created a very simple Dessert Generator app by using a Lambda function (written in Python) as the back-end, and AWS API Gateway to build an API. When the user presses the button labelled "Generate a dessert for me", the Angular app calls the API, which then triggers the Lambda function. The function runs and returns the result (e.g. "mint and mango cookies"... interesting combination), which the API gets and returns to the front-end.

What's great about Serverless?

1. Since you don't need to think about setting up a server, you can focus only on the skills needed to run your application (at the time of writing, Lambda supports C#, Java, Node.js and Python). If you or your team are experts in Python, but know nothing about web server configuration, then you can get straight to running your code.
2. It's cheap. Ridiculously cheap. You are charged for requests and compute time (i.e. when your code is actually called and run), as opposed to a server which might be running 24/7.
3. You don't need to worry about scaling the back-end part of your application to meet unexpected traffic, as AWS Lambda manages this (however, you do need to think about how that might impact your costs).
4. Deployment of Lambda functions can be still managed via an automated deployment pipeline.

What do you need to consider when building Lambda functions?

1. You still need to manage the security around your functions and how they're accessed. How are you triggering/calling your Lambda functions? Are you using API's? Are your API's public or authenticated? Do you have a limit on how many times your API can be called? How much memory does your function need? What's a reasonable timeout to set? All of these are within your control and need to be considered when building your functions.
2. How will you monitor the performance of your function? AWS Lambda integrates with AWS CloudWatch, but you need to keep on top of your monitoring and set up any alarms (for example, you might want to be alerted if there's a spike in invocations in order to investigate if it's a legitimate traffic spike).
3. You cannot access the infrastructure which stores and runs your code. This could be a big jump for organisations which might have stringent rules and processes around their current infrastructure.