Serverless - It could be yours too, if you want it…

I recently saw a gif where a small child is about to trust fall into the arms of his family but to everyone’s horror, falls in the opposite direction. The gif is short and we are left to wonder if the kid is alright but my guess is that he is and that really the bottom wasn’t too far anyway. He survived the free fall. I’d like to think this gif represents my entry into software development. I could’ve continued to trust fall into the arms of my previous work experience, falling in a direction that generally seemed safer or instead jump into the world of tech, which for me was the great unknown. 

In my experience, the tech community can be very supportive but learning a new language, framework or service really happens on an individual level. I continue to jump into the abyss over and over again when I make the decision to learn something new. With each new fall, you hit the bottom and realize it wasn’t so deep as it is wide. Massively endless in fact, which helps propel my personal hunger for learning. It’s like I’m hitting the curiosity buffet everyday! 

My “trust fall” into the AWS rift came years sooner than I thought I was prepared for. AWS seems like a technology that a seasoned veteran learns - not a newb. And so I entered into my internship at Serverless Guru knowing virtually nothing about AWS but eager to learn albeit a bit fearful at how far I could really go with my current skill level. Turns out I have frequently been incorrect about who is allowed to “come in” to a technology and when. 

Don’t Gatekeep Yourself - Create a Gateway (And all those other fun microservices!)

API Gateway is a microservice that AWS provides and was a good place to start when trying to conceptualize my first serverless project before the actual work began. The internet is made up of piles of information and there are many routes and ways to gather that information. Gateway is the channel in which we take those routes - the arteries and veins of the backend. It was helpful to figure out what endpoints we wanted to eventually have in order to workout the Lambda functions we were going to need to build out.

I entered into my internship at Serverless Guru knowing virtually nothing about AWS...turns out I have frequently been incorrect about who is allowed to “come in” to a technology and when.

For the project I worked on with my fellow interns, our main objective was to create an application where we could utilize AWS services to play host to our backend while ReactJS took care of the front of house. The idea was to create an application that acted as a hub for multiple users to post and view tech learning resources. A user can view only the posts they’ve made and have it act as a resource one stop shop but their post also shows on a main feed so others can have access to it as a resource as well. Our minimum viable product (MVP) was to build out a simple CRUD (create, read, update & delete) API with DynamoDB as our database. Each Lambda function would handle a specific request to our single DynamoDB table.

In order to create autonomy for our users and a bit of protection, we utilized AWS IAM and AWS Cognito to handle authorization. This helped to lock down certain endpoints so that an original poster was the only user who could update or delete a post. By using IAM as our first checkpoint we effectively made sure that each user is allowed access to specific resources instead of all resources.

Check out our project here

Interweaving Resources & Chasing State

The larger a project grows and the more resources you tie in, the harder things can be to change. As you gain more experience you’ll have the ability to know what to plan for earlier on but since this was our first time handling AWS in a project, there were of course unforeseen issues that we had to work through.

Originally we had put IAM into place on all endpoints as a way to block all non-users from accessing resources unless they had an account and signed in to it. Halfway through building out our frontend we decided that we wanted to have an endpoint grant read access to all users of the app regardless if they had signed in or not. Since we had wrapped all endpoints up with this very powerful tool, unraveling that took a bit of work and trial and error. There are also an incredible amount of ways to resolve this sort of issue (a blessing and a curse!) and making sure we were utilizing the correct one was also tricky.

One of the biggest challenges for me is baby sitting state and making sure it doesn’t wander off into places it shouldn’t or isn’t handled with proper care right off the bat. There were a few times where this became an issue, especially when adding in 3rd party API calls. What’s wonderful about using serverless on our backend was that we didn’t need to pass state around through our frontend but could continue to use our API and DynamoDB to bring up new sets of state.

Serverless - Why learn it early on in your tech career?

Why not? If it’s something you are keen on exploring then go for it. I recently opened up an old To-Do List on Trello dating back to 2015 and at the top of the list it read - “Explore Coding”. It took me 5 years to dance around an interest before falling down the rabbit hole. With each new interest in software and tech I won’t make the same mistake again of waiting to explore something until I think I’m ready. Serverless and AWS isn’t going anywhere, in fact it’s still very much ramping up and you’ll hope that you are already on the ride when the rollercoaster finishes clicking up the hill, strapped in and ready, right before it really starts to fly.

Resources used: 
[1]