Understanding AWS Serverless.
What?
It’s a platform offering a range of products for cloud computing services allowing you to use their infrastructure for scaling and growing your business. Below I will explain the principal products for constructing an AWS Serverless application.
Why?
Three main reasons:
- Market leader
- Pricing
- Most serveless services
Serveless.
Running applications and services WITHOUT thinking about servers.
You DON´T need to worry about:
- How much CPU and RAM you need or
- Updating OS to prevent security issues or
- If servers are online even if they’re not required…etc.
Serverless runs on demand, you only pay for what you use and also runs on managed AWS infrastructure so your code runs in an up-to-date secure environment and also it scales automatically. Lastly, serverless is the best option for SPA + API apps.
Aws lambda.
An AWS service allows you to host your code and run it upon certain events.
The event source is responsible for triggering our lambda and an event source could be another service, API Gateway(HTTP Request), or S3(file storage) that triggers your lambda function. This lambda function can interact with other AWS services and return a response.
As we saw in the above diagram, the event source (API Gateway) triggers the lambda function which executes any calculation. As a result, this triggers another service (DynamoDB).
Let´s see a dummy example in NodeJS:
Aws API Gateway.
An AWS service where you define the API endpoints & HTTP methods allowing you to secure the API access at any scale. It comes with multiple features and options:
- Resources are just like paths. E.g /API-test.
- Stages are snapshots of your API. E.g dev, prod.
- Authorizers allow you to add authentication (Below with Cognito).
- Models are optional, allows you to define the shape of data you work within your API.
- Documentation, nice tool if you plan to expose your API to other developers.
- Binary Support it´s important if you plan to send files along with your request.
- Dashboard gives you an overview of how your API performs, monitoring.
Aws Cognito.
An AWS service providing authentication.
The two main components of AWS Cognito are user and identity pools:
— Users pools are user directories that provide sign-up and sign-in options for your web and mobile app users. The whole process of creating a user pool is well documented here.
— Identity pools allow you connect the third party providers like Facebook or Google to Cognito and create temporary credentials. These credentials give users the right permissions to perform certain actions, depending on which credentials you provided.
Now you’ve created the user pool with the desired options, such as; sending a confirmation email or SMS and customising workflows with triggers (lambdas) before or after the user is created.
Let´s assume the user has signed up for the application and confirm his identity. Once the user has signed in, the user pool Cognito service will send three tokens to be precise.
- Identity token is where you go to the backend to authenticate a request, as we use the API Gateway, we need an authoriser (lambda function) to validate this ID token. This expires one hour after the user authenticates.
- Access Token the purpose of this token is to authorise operations like an update or delete user attributes. As with the ID token, this expires one hour after.
- Refresh Token is required to get a new ID Token or Access Token. These live no longer for security reasons.
Aws S3.
A file storage service for you to store files of any kind.
In S3 you organise files in buckets as a kind of a folder (you could say) but you can have a structure inside these buckets of course. You mainly use these to hold your static application files.
It comes with a couple of features:
- like how frequently the user’s access,
- Versioning you have a history of versions, you can do the restore of the previous version by copying the object in the same Bucket. That object becomes the current version whilst keeping the others. If you delete the current version, take the one before that.
- One of the most important features access control to manage user permissions to read/write on the bucket.
Here At GuideSmiths we use the serveless framework which is very handy to work with for deploying AWS serverless architecture. Regarding permissions, we use IAM role that we define in the serverless framework. Here´s an example:
I hope it helps :)
