diff --git a/en/blog/aws_lambda_a_virtual_podcast/index.html b/en/blog/aws_lambda_a_virtual_podcast/index.html index 216df61..31ef186 100644 --- a/en/blog/aws_lambda_a_virtual_podcast/index.html +++ b/en/blog/aws_lambda_a_virtual_podcast/index.html @@ -13,9 +13,9 @@ provides an easy-to-use test/mocking framework for developing Cloud applications. At this stage, their focus is primarily on supporting the AWS cloud stack.

LocalStack spins up various Cloud APIs on local machine including S3, lambda, DynamoDB and API Gateway. All you need to do is, spin up LocalStack docker container, deploy your infra say Dynamo table or lambda function within LocalStack and connect to these services running on local machine from within your code.

Me> Interesting. Does LocalStack support all AWS services?

Hernandez> No, it supports quite a few but definitely not all.

I am sure Unit testing with AWS Lambda function code is understood by all of us but what is good to know is LocalStack can be used for integration testing.

. . .

Packaging and deploying an AWS Lambda application

Me> Jessica, you talked about unzipped code. Does that mean you have to create a zip file and upload it somewhere?

Jessica> Well, you have package your lambda function along with its dependencies as an archive, upload it either on AWS Lambda console or in an S3 bucket which will be referenced from your CloudFormation template.

Me> How do you folks package your application? It appears to me as if we need to create a “fat jar” kind of a thing.

Hernandez> We use typescript for coding our lambda application and webpack for packaging it. It does not create a zip file, just an out directory containing the transpiled code (js) and a handler.js file with all the required code from different node_modules plus its source map.

Me> How do you deploy your code then because you just seemed to create an output directory with a few javascript files.

Hernandez> We use CDK -for deploying our code which allows you to code your infra.

Me> Wow, the list of tools doesn’t seem to come to an end.

Hernandez> It’s simple. Just look at it this way, we have just created a directory which is ready to be deployed and moment you say cdk bootstrap, it will copy the contents of this out directory into another directory which will be archived and uploaded to an S3 bucket.

And when you say cdk deploy, you will see all the required AWS components getting deployed. Simple.

Me>Simple? You said contents of this out directory will be copied into another directory. Does that mean CDK already knows about the out directory?

Hernandez> That’s true. When you code your infra, you will specify where is your compiled (or transpiled) or ready to be shipped code located and that’s how CDK knows about this directory.

Me> Great, now I able to connect dots. Build your code -> get a shippable directory -> archive it -> upload it to an S3 bucket -> deploy it and CDK is one way to get all these steps done. Is that right?

Hernandez> Absolutely.

In order to deploy yours lambda function, it needs to be packaged along with its dependencies as an archive. You could use webpack if you are using typescript as a programming language. You can use CDK, CloudFormation or SAM for packaging and deploying your lambda function.

. . .

Applications built using AWS Lambda

Me> Jessica, Hernandez, what are the different types of applications that you folks have built using AWS Lambda?

Jessica> We have actually built serverless microservices using AWS Lambda and we also process web clicks on our application which is a stream of events flowing from user interface to AWS Pinpoint to AWS Kinesis to AWS Lambda.

Hernandez> We use AWS Lambda for scaling down images that are uploaded to our S3 buckets and for processing DynamoDB streams which is a stream of changes in DynamoDB table.

Me> Thanks Jessica and Hernandez.

Our panel highlighted different types of applications they have built using AWS Lambda including microservices, event processing (images on S3 buckets) and stream processing (web clicks and handling changes in DynamoDB).

. . .

With this we come to an end of our “Virtual Podcast” and a big Thank you to Jessica and Hernandez for being a part of this. This was wonderful, and hope our readers (yes, it is still virtual) find it the same way. Thank you again.

References

I guess we are ready to do TDD as well for Serverless.

Summary

Finally, we have come to an end of our first article where we made an attempt to design a small part of a serverless application that uses AWS Lambda, API Gateway and DynamoDB.

As a part of this application we have tried to draw some parallels with the MVC design pattern and bring the same to the serverless world.

Items that we have left:

I am sure you will be able to fill these gaps and at this stage, I will move forward.

There is a lot of work still left before we can deploy the code:

Code is available here .

Let’s move on to our next -article that explores integration testing using Localstack for our serverless application.

Let’s connect

diff --git a/en/page/projects/index.html b/en/page/projects/index.html index 84568e6..31733a9 100644 --- a/en/page/projects/index.html +++ b/en/page/projects/index.html @@ -86,10 +86,7 @@ } }

Feature sendEmail is enabled if the property feature.send.email is set to true.

I have a separate blog -about this library.