Serverless has become a major trend in the web development industry. It’s no surprise that AWS has become the lead ecosystem for serverless architecture.

I used to play around with serverless either a FaaS (Function as a Service) or BaaS (Backend as a Service) when I first started doing things “serverlessly“. It was as simple as sending a message to a queue and then CloudWatch event trigger a lambda function, get these messages and process them accordingly. But I’ve always felt that it can do more. Then I build an SPA (Single Page Application) and that’s where I got hooked.

I utilised the AWS Cognito service, which is a simple plug and play service that authenticates and authorises your APIs.

Building a new API was done in a couple of minutes and ready to use. The MobileHub out of the box proxies your API Gateway to a lambda function. The lambda function has the same role as the MobileHub has. To talk to other AWS resources. Once you have a solid understanding of how things work together, you’ll find that it’s not difficult to build an entire project within a day.

Your focus should be the front-end because the back-end can be done within a day or two.

Working with Suria Labs was great for me as we work on different projects all the time and they encourage their staff to play around with new frameworks and technologies coming up in the field. Luckily, we got our first serverless project.

The project is a mobile app that helps you save money based on everything you spend. It was built using React Native and BaaS with AWS. In other words, there’s no server for this app.

As you can see in the above figure, a user signs-in by authenticating with Cognito and sends back the token. Consequently, this user can use the API Gateway, which will trigger a lambda function that has permission to talk with the DB and returns results to the end user.

I used MobileHub to glue all the resources together and the AWSAmplify library to make life easier because all you have to do is install it, configure it by the `aws-exports.js` file which is generated by the MobileHub for you, then you can use Auth and API from the AWSAmplify. Need a new API? Easy, just go to the MobileHub dashboard select Cloud Logic and create a new API and right away you can use it. Same goes for a NoSql Database (DynamoDB).

All APIs are now set up and ready to go, again, with very little effort. Now we need to build some logic because serverless architecture is all about focusing on your app’s logic and functions instead of worrying about DevOps, deploying and scaling. None of that is a developer’s concern when you use serverless architecture because it scales with usage and has availability and fault tolerance built in.

Using serverless architecture has improved my understanding of the a “Separation of Concerns” and decoupling principle because our functions are stateless and all have well defined inputs and outputs so each function is totally independent. That being said, let’s look at the figure below.

As you might have noticed, each lambda function has a trigger and outputs. But let’s discuss the steps of this flow:

• First it starts with an AWS CloudWatch daily event which will trigger a lambda function. this function gets the desired users from the DynamoDB and pushes a SNS topic for each one of them.
• Following that, we have a another function which has a listener to a queue for any incoming messages (Thanks for AWS Lambda team for adding SQS to supported Event Sources). once a message is received, a lambda function will trigger, record a transaction in the DynamoDB and send a SNS topic with the results to update the user.
• Finally, the last lambda function also listens to the queue in question in the step above, takes the message, updates the user and checks if a notification needs to be sent to the notification queue if not, it ends there and that’s the end of the flow.

Each step has its own function and logs. So if anything happens during this flow, the message will retry X number of times, then go to the Dead-Letter queue so we can read it, fix it and reprocess the failed messages. This way we don’t lose any of information.

Similar to the flow above we ended up having a couple of flows like that which covered all the logic.

Pros and Cons:

We’ve already established two very good points in favour of using serverless architecture, but here’s a more comprehensive list:

• Scales with usage
• Availability and fault tolerance built in.
• Reduced server cost because you never pay for idle time. E.g. if we run a daily job we don’t need a server with Redis and Sidekiq working 24/7 to handle it.
• Frees up developer resources. As mentioned, you can focus more on your code and logic because working with serverless, there’s a lot of things you need not manage anymore. E.g managing DevOps or spending time on maintenance.

I can think of 3 cons:

• Latency. Sometimes, you may encounter some latency issues when dealing with lambda functions. It’s called First or Cold start.
• As this is relatively new, you may struggle to find engineers with serverless experience.
• Heavier reliance on vendor ecosystems. (But in my opinion, since we already rely on AWS for our instances and S3, why not serverless?).

When to use Serverless:

• If your app is small.  Where the logic is relatively simple and there aren’t a mountain of features.
• If the logic can be broken into well defined blocks with clear inputs and outputs.
• If you’re already making use of cloud computing.
• When you’re using Node.js, Java, Python, Go or just recently Ruby. No other languages or frameworks work with serverless.
• If your app doesn’t need to be up and running 24/7, i.e. only when users make a request.

In short, where serverless applications are appropriate, they work wonderfully.

Lastly, a word to those who are new to NoSQL databases and are planning to use it for your serverless application.

I’d highly recommend you spend a significant amount of time understanding how it works before developing. E.g. where you should add indexes? Do you need a global secondary index? How to calculate and identify Read/Write Capacity units you need. Strongly consistent vs eventually consistent reads, etc.

It’s totally worth it. Having a well thought out database architecture will minimise your workload and save cost from heavy and expensive queries should your app grow exponentially.

To conclude, I think it’s safe to say that we should start thinking about serverless on every project we’re planning to do to see if it fits, and if it does, proceed to implement it.