Working without Databases and Servers
Business: Let’s put a new kind of feedback form on the website. Let’s do it today. Also I would like an email on each form submission and while you are at it let’s sync a sheet with the data as well.
Developer: brrr .. 2 weeks. I will have to write a database migration. Write an API to submit form. Setup workers to send email. Let’s skip the excel, I will create a slave read only DB for you where you can query. We will also have to schedule a deployment and change our production DB. I am currently working on the new product feature so talk to the PM when this can be shipped.
Business requirements which are perishable or always changing or not directly relevant to the main product can often create mess in the codebase and add friction to the development. With modern tools at our disposal we can be smart and ship such requirements in a much efficient manner.
If you use AWS and Slack, the above problem statement can be solved in less then a day. The center of all this is AWS Lambda which let’s you run your code without provisioning or managing servers [1]. You can trigger a Lambda function using AWS API gateway[2] or SNS[3] notification or even when an object gets uploaded on S3. Setting up triggers is as easy as selecting options from GUI.
The architecture diagram with two possible solutions looks something like this:
Method 1:
Create a route in AWS API gateway from aws dashboard and set it as a trigger to the Lambda function. Use this route as form submit action url.
Method 2:
If you already have a route on your server to which the form is submitted, then create a SNS topic from AWS dashboard and set it as a trigger to the Lambda function. When the form is submitted, push a notification to this topic from your backend.
# Ruby
sns = Aws::SNS::Client.new
sns.publish({
topic_arn: params[:topic_arn],
message: params[:message].to_json
})Now you have to write the logic in a Lambda function which would be executed by AWS when a trigger is activated. This Lambda function can now post to Slack or send an email or even write in your database.
Let’s say you have to send the form submission data to a particular Slack channel each time a form is submitted. Just create an inbound webhook from Slack dashboard and use the sample below.
You can now just use Zapier[4] to configure writing to a particular google sheet each time this Slack channel receives a message or if you enjoy writing code, just write a google script attached to the sheet and use the outbound webhook of Slack. I have added a sample code for it as well in the repo.
This architecture can be extended to multiple use cases. Trigger a lambda function, process the data and send it to various consumers. Let’s say you want to compress an image each time it is uploaded on S3, this is much easier and scalable solution rather than setting up an infrastructure to do it.
At start this might look complicated with lots of moving parts which is true until you gets your hands dirty for the first time. The major advantages from my point of view:
- Cost: You pay what you use, literally. No base fee. Moreover first 1 million requests to a Lambda function are free each month which is a lot for an early stage SaaS startup like us.
- Speed: Complex business logic can be made up and running within no time as long as you can write code in JS or Python.
- Ease of Deployment: Testing and deploying is as easy as clicking a button without worrying about load balancing etc.
- Maintenance: Log can easily be configured and analyzed to fix bugs.
- Microservice: Can easily be replaced with something more complicated as the need grows. Does not add to the technical debt.
Github Repo with sample codes: https://github.com/theashishranjan/aws_examples
Curious about the motivation behind doing all this? Read my last post: Startup 01
If you would like us to publish more such hacks we use, do let us know in the comments.
