Building a Serverless Web Application
Over this year, when not working during my day job or running around after the kids, I’ve been spending some time building a serverless web application.
You’re probably wondering why of earth would someone want to do that in their spare time? And what is a serverless web application anyway?
The first answer is I like building stuff that people may find useful and it’s a great way to keep up to date on the latest technology out there.
And the second answer is I had heard the term “serverless” on a blog a couple years ago and really didn’t know what it was. Through my studies of AWS I started to learn more about serverless, what is was and why it was so cool, so why not try it out?
What is serverless and why is it so cool?
Serverless still contains servers, don’t worry about that. It’s just that you largely don’t have to worry about the servers anymore. In an AWS world this means no more managing EC2 instances, settings up VPCs and Subnets etc. You just write code and deploy as an AWS Lambda function and that’s it, your code runs!
Sounds great! So, why so cool?
- No servers to worry about and manage. Write code and upload to AWS Lambda to handle compute.
- It scales up and down as required.
- You only pay for what you use.
So basically, when a user clicks a link on your webpage it will then post to your API Gateway service which then triggers an AWS Lambda. The best thing is that you’ll just pay for the time the Lambda function takes to run its code (rounded up to the nearest 100 milliseconds). No more setting up and adjusting EC2 instances which you’ll still be paying for overnight and weekends even if they’re not really being used.
How does serverless work?
First have a look at the website I built at https://www.bookinbot.com which is a rather simple website to allow people to sign up and then share resources with their friends and family. It’s a start but there is still some work to do on the functionality.
It’s actually not as simple as just setting up an AWS Lambda function and you’re in business. There is a bit more involved. Below is the architecture I chose and various AWS services to put the website together and then some more detail on the steps required.
Architecture Diagram:
Steps and detail for a typical user request
1# When your browser hits a URL it needs to resolve it to an IP address. This is what it does first by using the AWS Route 53 service.
2# AWS CloudFront provides a CDN (Content Delivery Network) to provide quicker response times as it positions your content closer to your end users.
3# The actual website is just HTML and JavaScript hosted in an S3 bucket which is set to host a static website.
4# Once the JavaScript is returned back to the browser it can then obtain a session token from Cognito if signed in or apply for one on sign up.
5# Good, so you’re getting HTML and JavaScript back into your browser, your page is displaying and stuff is happening. But what if you want to view some data or update it? You need to call an API. The AWS API Gateway service makes this easy and it integrates well with AWS Lambda.
6# From API Gateway you can trigger your backend code as an event in a Lambda function. This is the brains of the operation and decides, given a request, what to do with it. Generally that means talking to a database.
7# I chose AWS DynamoDB which is NoSQL based (and also massively scalable) as my database which also provides a nice and convenient way to store data for retrieval later on.
All of the above allows you to piece together a fully functional website from serverless AWS services.
What did I learn? Here are 5 top things to take away:
1) Web Development with Bootstrap and Angular
I had to learn a lot more about web development. Fortunately there are HTML and JavaScript frameworks like Bootstrap and Angular which makes this all a lot easier. Bootstrap (https://getbootstrap.com/) has a whole bunch of predefined components that you can put together to create a mobile friendly website (see below). Angular (https://angular.io/) lets you simplify and structure your JavaScript code so various components can interact with each other.
2) Backend Code with AWS Lambda
Every time a request is made the code in your Lambda function, if it hasn’t been run for a while, may have to do a number of things to warm up. This is know as a “cold start” and the time it takes depends on the programming language you use and the complexity of the code among other things (see more here https://hackernoon.com/cold-starts-in-aws-lambda-f9e3432adbf0). I wrote the code and logic to run in Lambda in the Node JS runtime and have found the cold starts to be pretty good. Generally if I come back and hit the website after a day or so servicing a request takes less than a second.
I’m keen to try something similar with C# or other languages (apparently and unfortunately Java is the slowest) at some stage to see if the performance is much different but will leave that for another project!
3) User Management with AWS Cognito
If you’re going to build a web application then you generally need people to sign up and sign in. You need some type of user management. AWS provides a good solution called Cognito. This allowed me to add a library to my front end JavaScript code to sign up and sign in users. All this time the user information is safely stored and managed inside the AWS Cognito service. Below shows some of that user management within AWS Cognito.
4) Data Storage with AWS DynamoDB
What happens when you create a new resource, want to share it with another user and then book in time on that resource. You have to store that data somewhere. I’ve come from a SQL database background and AWS are pushing pretty hard to use the DynamoDB NoSQL solution. Plus, it’s as cheap as chips, so I gave it a go.
Once you get use to the idea of not having SQL joins, generating your own unique identifiers and sometimes duplication of data where is makes sense it’s not too bad. There is definitely a learning curve but seems to work ok once you get your head around it. Below are the three tables I used for the web application for bookings, resource management and then sharing between the two.
5) Bring it all together with the Serverless Framework
Significant time was spent just getting different AWS services talking to each other. The Serverless Framework (https://serverless.com/) really helps with gluing together API Gateway, Lambda and the DynamoDB and also allowed me to test this all locally before uploading to AWS. AWS Cloud Formation was also useful for setting up other infrastructure components in a repeatable way.
Please have a play with the website https://www.bookinbot.com to get a feel for the experience and performance and let me know how it goes. If you’re interested in some of the code please have a look here https://github.com/stefanevansnz/bookinbot.
Many thanks for reading and if you’re also interested in this sort of stuff please get in touch.
Stefan.