My first 14hrs with AWS Lambda

Dennis Machu
Nov 3, 2019 · 3 min read

Serverless! Serverless!! Serverless!!!

Everybody seems to be talking about it.

To some, this movement has come to stay, and today, I decided to give it my all.

Goal: To build RESTful API’s that I can call from postman, both locally and from a remote pc/over the internet

I woke up with the urge to do something new today, that urge pushed me to look into Serverless computing as an add-on to my skillset 😂

Started by just jumping into it. With my first 4 attempts I didn’t achieve my desired results and from that, I learnt 4 ways of not going about it. At this point, my interest had peaked and there was no turning back.

I managed to get my first endpoint out and shared with few friends to check it out and give me feedback.

After some good round of feedback, I decided to go deeper, this time, to create multiple endpoints without going through the stress of creating new functions every time. Did all I could and didn’t achieve desirable results so I did what every dev does, went on google and read and practised with about 5/6/7 😝 articles and I was still not impressed till I came along one that spoke my language (NodeJS + MongoDB).

After a lot of tweaks and frustrations, I made it with a deployed CRUD (Create, Read, Update, Delete) API Endpoints that could be accessed remotely.

My take on AWS Lambda so far

What I like:

  1. It is fantastic, for someone like me who doesn’t want to worry about how to build a scalable server and deal with rate limits in API calls, this is the game-changer. You don’t have to manage anything, you don’t worry about uptime, it’ll just work and the best part, it scales in and out automatically. if you’ve been there before you will accept scaling servers is not fun 😍😍😍
  2. API endpoints documentation are automatic 🥳
  3. Everything can be built in a Serverless manner 📡
  4. You are forced to employ ‘separation of concerns’ architecture — separating your database from your back end. 🎛
  5. It’s cheaper compared to having and maintaining your own server. 💰

What I didn’t like:

  1. I couldn’t arrange my functions neatly into folders for easy maintenance and navigation; for me, order in my code & file structure is an art. 👌🏽
  2. Initially, I had to use Cloud Watch, which had loads of logs for me to comb through and it wasn’t a nice experience at all. I only wanted to see my console.log(“You know what I mean”) 😍

I am so excited about this, and I will be publishing another article in a week, on my step by step approach deploying serverless function on AWS. 💃🏽💃🏽💃🏽

Dev Stack Experience:

  • JavaScript => NodeJs
  • NoSQL => MongoDB
  • AWS experience => Cloud Practitioner

Number of tries: 29 || Success: 12

Tools Used:

Dennis Machu

Written by

Professional Scrum Master | Full Stack Javascript Web Applications Developer | Fintech Enthusiast | Cloud Technology Enthusiast.

More From Medium

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade