Going Serverless with Amazon Web Services (AWS) — The Modern Approach
This is the second blog of a series of two blogs, Going Serverless with Amazon Web Services (AWS)
2. The Modern Approach 🚴
In the first blog of this series, Going Serverless with Amazon Web Services (AWS) — The Traditional Approach, I have discussed and demonstrated the process of deploying a very basic serverless application manually through AWS console. If you have gone through that blog or, if you have done this once to deploy your own serverless application, you might already know the pain of doing that in the traditional track.
Let me quickly recap, what we have been doing so far.
We were in the process of building a backend for a simple contact us for a static web site.
The painful Story
We first tried a simple lambda function written in the AWS console which was triggered by an API gateway event. Later we wanted to use some 3rd party NodeJS libraries in my function and we had to write our lambda function in my local computer and upload it as a zip, through the AWS console.
By following the best practices, we even created a AWS IAM role for my lambda function, which enables only necessary permissions to the function.
We could create a API Gateway endpoint from the lambda console itself, but had to revisit APIG console to apply few teaks.
Already sounds painful right? 🤕
This is just the beginning of the story.
Bonus Pain 1 : Changing the existing code
Let’s assume that we want to change the code of my function to include few more validations.
Doing this update is extremely easy within the AWS console! 😉
Once you upload the function, Lambda console unzips it, and show us an editable code in the dashboard. We just have to edit our code and click big orange Save button. 🤠
Bonus Pain 2 : Adding new 3rd party libraries/ dependencies
Assume, we want to add a new 3rd party library to add more functionalities to our lambda function. (We wanted to add validate js in our sample use-case)
Bummer! You can’t do that in Lambda console. 😦
Now I am falling back to the code in my local computer. I have to install my node module manually and repack the code with dependencies.
Ooops!! Since I have previously edited this code in AWS console, now I have an outdated version locally. Have to go back to the Lambda console to copy or download the latest code. 😣
Bonus Pain 3 : Associating lambda with few more AWS resources
Up to now, our lambda wanted to talk just with DynamoDB. Now we want our lambda to talk with S3 as well(assume we added a file upload feature to contact us form). Now the process is as follows,
- Navigating to S3 console and create a bucket
- Reading S3 javascript SDK docs since we don’t know it’s API.
- Adding necessary patches to the existing code to handle file upload.
- Uploading the code through AWS lambda console and clicking big orange Save button.
Alright! 😫 . Now my lambda can upload to S3!!
But when I test my setup, I get a big error when trying to upload my content to S3.
Reason?
I followed best practices in my old programming books and gave only necessary permissions to Lambda initially. Now my lambda can’t talk with S3.
So I have to edit the IAM role assigned to lambda by adding new permissions to talk with S3.
In this blog, let me show you a more convenient way of developing a serverless application without going through such painful process. I would like to introduce this process as the Modern Approach for Serverless development.
🚴 Modern Approach — Sigma
Sigma is a modern and feature-rich browser based IDE developed by a team of engineers from Sri Lanka, who have gone through the above painful process for years while developing enterprise integration solutions. I would like to introduce Sigma as the modern approach for serverless development, since it solves most of the pain points that developers have to face while developing serverless applications.
Just go through the following steps for implementing the same use-case that we came across in Going Serverless with Amazon Web Services (AWS) — The Traditional Approach and experience the streamlined process for forging SLApps(Server-less Apps) yourself.
Step 1 — Creating a New Project
Create a project by giving a name, description and the AWS location to deploy the resources.
Once you create a new project, Sigma will show you the main editor view.
When you load the editor view for the first time, you will notice few things which you won’t see in other editors.
- A List of AWS resources with a numerical badge in front.
- Red colored warning in the Lambda function handler
A List of AWS resources with a numerical badge infront.
This is the list of AWS resources that are currently supported by Sigma. However, this doesn’t mean you can’t use other AWS resources in Sigma code. These are just the super powered resources which are currently supported and we are working hard to grow this list.
What’s so special about these resource?
You can drag and drop these resources to your editor! Yes you read it right.
Drag and Drop!! Drag and Drop!! Drag and Drop!!
Numerical badge indicates the number of unique resources of the same type which are already being used in the current project. Once you create a resource in your project, this count will increase and also those resources will be visible in a sub list, where you can directly use the same resource(without re-configuring) whenever you need it again.
Oh! very bad that I have mistyped the name of Sri Lanka.
I can correct this typo in two ways.
- Click on the blue DynamoDB icon on left corner and do the corrections in the UI.
2. Correct in the code itself, as we usually do. Changes in the code get automatically reflected in the UI!!
Step 2 — Creating the DynamoDB table
For our use case that we have explained in detail in the first blog of this series, Going Serverless with Amazon Web Services (AWS) — The Traditional Approach, we wanted to create a new DynamoDB table with name contact_us with email as the partition key and date as the sort key.
Since, we want to save date with every contact_us entry, let me declare that variable in my code first.
You noticed that right 😎. We have intelligent code suggestions built into the Sigma IDE!
Let me go ahead and create my new DynamoDB table.
Done!!! We have created a table and even we have generated the code to do a put operation on the same table. We are not going to disturb your coding rhythm by forcing you to navigate away from your code as you had to do in traditional approach. We have streamlined the process of creating and using resources!
You noticed that again right 😎. Intelligent code suggestion works even inside the resource popups!!
Red colored warning in the Lambda function handler
Still we have the so called red colored warning in the Lambda function handler.
As we know, in order to execute a lambda function, we have to trigger it with an event. With this red warning, sigma is reminding us that, our lambda still doesn’t have an event attached.
Let’s go ahead and solve this issue too. In our use case, We are going to trigger this lambda using a API Gateway event(a POST request).
Step 3 — Creating an API Gateway endpoint and adding that as a trigger
Doing this is very much similar to what we did with DynamoDB. Just keep dragging and dropping!
With few mouse clicks and key strokes, I just completed the following list of tasks.
- Created an API with name contact us end point.
- Added a resource to that endpoint (/contact) which accepts a POST request.
- Enabled CORS on that endpoint. (Remeber, we had to navigate back to the API Gatway console in traditional approach, just to do this)
- Deployed my API with the stage name prod.
- Added my newly created API as a trigger to the lambda function.
With this step, I just completed the first version of my contact us form backend!!
Wait…. We just came across the keyword version. Let me introduce you the next big feature of Sigma.
Version controlling is built into Sigma IDE. Sigma is tightly integrated with Github which is the most popular web-based hosting service for version control using git. You can directly commit your project to github, simply by spending few mouse clicks.
Step 4 — Committing the first version to github
We have all the tools necessary to manipulate our project, consolidated to a single toolbar in Sigma.
Let’s go ahead and click on Save button to commit our project to Github.
Until now, we were building our serverless application in our browser by virtually creating resources(DynamoDB tables, API endpoints, Lambda functions). Now it is time to deploy our project in AWS.
Step 4 — Deploying the project in AWS
In order to deploy the project to AWS, we just have to click on the deploy button in toolbar.
Sigma will then show you a list of changes, which are yet to be executed on your AWS account.
You can even view the detailed log, while deployment is being executed.
Once deployment is completed, Sigma will show you a summary of the process.
Sigma’s deployment summary even includes the URL of the deployed API gateway endpoint!!
So we are done with the fist version of our serverless application. Our app is now live on cloud!!
Let me show you few more interesting things about Sigma.
Automatically importing/ injecting AWS libraries.
Let’s have a close look at our code.
Okay wait…. We never typed the top two lines of code.
Who did that? 😳
Who added the imports for AWS library and created a DynamoDB document client for me?
Sigma does all of that for you!! Whenever you drag and drop a resource to code editor, Sigma automatically import required AWS libraries and create instances of respective resources.
Adding 3rd party libraries
According to my use-case explained in Going Serverless with Amazon Web Services (AWS) — The Traditional Approach, we wanted to validate the incoming request before persisting with the help of a 3rd party library called validate js.
You can easily add dependencies to Sigma project with a matter of few clicks.
That’s it. Now you can use the newly added dependency in any JS file of your project!!!
That is just a brief introduction to the modern approach for serverless development.
Let’s turn back and see what are the pain points that we have actually solved in modern approach.
Changing the existing lambda code
Unlike in traditional approach, where you had to edit the local code and re upload the code bundle to AWS, with modern approach, you just do every thing in your browser, and re deploy whenever you need with a single mouse click.
Adding 3rd party dependencies
Just, Click ⇒ Search ⇒ Click to add new dependencies to your project. No more, download ⇒ unzipping ⇒ npm installs ⇒ re zipping ⇒ uploading ⇒ click on Save to add libraries.
Associating with more AWS resources
Remember how we had to update Lambda role, when we wanted to connect with new AWS resources. The modern approach automates that for you! . Sigma guarantees to attach just the necessary permissions to your lambda. Sigma knows best practices and it follows them for you 😊.
No more hours of your valuable time, spending on AWS docs
Sigma generates API calls automatically for you. Sigma even import dependencies for you! Just fill some fields in the UI and forget the rest. Just worry about your application logic!
So this is the promise I made at the end of the post about traditional approach.
Forget both resource provisioning and code and just focus on the application logic.
Learn more about Sigma
Call To Action
- Clap. Appreciate and let others find this article.
- Comment. Share your views on this article.
- Follow me. Chathura Widanage to receive updates on articles like this.
- Keep in touch. LinkedIn, Twitter
