In the previous chapter, we saw how we can invoke Lambda functions when a client requests an HTTP source. It was not so different from a classical web application, and instead of a controller class always in memory, Lambda runtime located our code piece to execute it and removed it from memory after it finished its job. We only paid for what we used, and we did not have to maintain any infrastructure on our own.
Is it the only way to benefit from Lambdas? Definitely not.
Let's assume that our forum application got very popular and we wanted to let our users upload their profile pictures. In different parts of our forum, we will be using three different sizes of profile pictures, so whenever a user uploads a new picture, we should resize the image on a data storage. The first thing that comes to mind is to create another Lambda function to respond to the HTTP upload request and to resize images on the fly, but we can never guarantee that our resize process will last a reasonable amount of time. Also, with this architecture, we are again binding the HTTP context with our business context; it means our Lambda function will have to deal with two different contexts.
AWS brings a better solution to this problem. With API Gateway, we can expose a limited functionality of our cloud resources to end user, and we can trigger Lambda functions when some specific events occur in the cloud resources. In this chapter, we will build an asynchronous image-resizing service, and the only piece of code we will write will be to resize the image. In this chapter, we will cover the following topics:
- How to configure API Gateway to let users upload their files to S3 without code
- How to trigger Lambda functions when a new file is added to the S3 bucket
- How to configure CloudFront to serve files directly through the S3 bucket