My Simple AWS App Backend

Eddie
Eddie
Nov 20, 2017 · 3 min read

I released my first iOS app! 🎉🥂👏🏽 It’s called WurstWetter check it out:

“Why did you make this?” you’re asking. I wanted a portfolio piece and I saw many others making weather and calculator apps as their first portfolio pieces, but I needed my own spin on it. So why not only show the worst weather across the US!? ⛈

The idea made this app a bit more of an undertaking than your regular weather app because I knew early on I would need a backend. That’s what this post is about, the WurstWetter backend.

Why I needed a backend

I knew I needed a backend because I didn’t want individual clients making hundreds of weather requests at once when the app was opened. As the user base would grow, I would get in trouble with weather data providers over how many requests I was making. I also didn’t want to pay for all of this weather data, it gets pricey quick 💸

Instead of having every client calculate the worst weather, I could centralize that process and have clients only request the end result. This way I have one server asking for all the data instead of individual clients.

Now, if I calculated the weather data on demand from every client, I’d be back at square one: making hundreds of requests at once. I got around this by updating the weather data every hour, and I spread out the requests over a few minutes. With this approach, clients just need to request the final JSON file.

Using AWS

I went with AWS as my hosting provider. I wanted to work with AWS because I wanted more experience with it; I know many companies use AWS, I think it’s valuable to know, and I enjoy learning it. Simple as that. 😌

Avoiding AWS API Gateway

When it comes to building modern day apps, people jump to creating RESTful APIs, and I thought about that too. Then I realized each client is getting the exact same data, so why add the overhead of creating a RESTful API for sending over a simple JSON file? I could store that file in one place, like an S3 bucket, and clients simply download that file. It’s still a GET request if you think about it right…🙃

Creating a RESTful API in AWS either requires a dedicated server running (which I didn’t want to set up) or using API Gateway. Now, I’ve used API Gateway before at work, and the amount of overhead it would add would not have been worth it in my opinion. I was definitely going to go the download an S3 file route given my options.

Also, the API Gateway calls from my clients would’ve added just a bit more to the overall cost of my backend. I wanted to keep my costs as low as possible.

How it works

  1. The Lambda that’s scheduled on the hour turns on the Weather Aggregator Lambda.
  2. The Weather Aggregator Lambda is also on a two minute repeating schedule. On each execution it makes requests to weather data providers.
  3. The data from the Weather Aggregator Lambda is stored temporarily in a DynamoDB until all the weather requests have been made.
  4. Once all the requests have been made, the last iteration of the Weather Aggregator Lambda reads the entire DynamoDB and calculates the worst weather list. The worst weather list is written out to a JSON file stored in a private S3 bucket
  5. Finally consumers read the JSON file. Currently I have two consumers, the WurstWetter iOS app and the WurstWetter Alexa skill which I’ve written about before: https://medium.com/@eddies5/how-i-published-an-alexa-skill-in-96-hours-using-aws-codestar-3ea20cbb4fc5

What do you think? Do you think I lost anything by not putting a RESTful API in between my data and my clients?

~Eddie.

Eddie

Written by

Eddie

Twitter: eddies5 | eddiesaenz.net | iOS Developer | Austin, Texas