Switch to a laptop (or maximize your browser window) for an optimal viewing experience.

UWB Hacks the Cloud Documentation

All the essential information needed to create an amazing cloud-based application at the UW Bothell 2020 hackathon.

Go to Documentation Home Go to Hackathon Website View on GitHub

FeelGood, an Example Project for AWS

The hackathon organizers wanted to build an application that facilitates self-service for good vibes and positivity.

From that ideal, the project grew to provide additional registration options to facilitate laughs and silliness.

Read about the project and how we built it!

Goals

TL;DR: automatic, supersonic, hypnotic, funky fresh

User Experience

  1. A user goes to the application’s website to sign up for messages.

    via GIPHY

  2. The user subscribes to a topic.

    via GIPHY

  3. The user gets a welcome message after subscribing to a topic of their choice. They can continue to subscribe to other topics they are interested in.

    via GIPHY

  4. At set times during the day, the user gets a text message reminding them to:
    • Feel good
    • Drink water
    • Laugh
    • Commune with their crow friends

    Of course, the messages they actually get are dependent on which topics they subscribed to.

    via GIPHY

    via GIPHY

Architecture

To realize these desired behaviors & user experiences, we used AWS services and deployed the application to the cloud. The application’s design is described below.

User Subscription

View the website code here.

View the subscription Lambda function here.

Here’s a diagram of the system’s flow of logic:

FeelGood subscription mechanism

User Notification

View the publication Lambda function here.

Here’s a diagram of the subsystem’s flow of logic:

FeelGood publication mechanism

Implementation Notes

The specific instructions, how-tos, and details we encountered are organized here by AWS product.

S3 & Website Construction

We used to the following resources as a guide for configuring S3 buckets to host the subscription website:

API Gateway

There are multiple types of APIs that can be built using API Gateway, such as REST, HTTP, or WebSocket. This document will focus specifically on REST APIs. AWS’ API Gateway documentation has a helpful tutorial that covers creating a REST API with Lambda Integrations. This was the approach taken for FeelGood.

Create a Resource

A resource is something that can be accessed through the REST API using CRUD operations. GCP has a good explanation of REST APIs and resources if you are unfamiliar with the concept or would like to refresh your memory. In API Gateway, the resource also represents your endpoint. For example, on a hypothetical website for a car dealership, the URL might be www.cars.com/buycar. The endpoint in this scenario is /buycar. Each endpoint has its own set of methods.

Create a Method

A method is the actual operation to be performed on the resource, such as GET, PUT, POST, DELETE, etc. The method’s settings are where integrations with Lambda functions including input pass-through are set. See the API Gateway page on REST API methods for a detailed tutorial.

Setup CORS

CORS stands for Cross-Origin Resource Sharing. This is required to tell your browser that it is safe to access certain API endpoints. Whether or not CORS is required depends on what the API does. See Mozilla’s MDN Docs on CORS for more information on what it is and why it’s needed. See API Gateway Docs on Enabling CORS for REST APIs for a tutorial on enabling CORS.

Deploy the API

Once everything is setup correctly, all that’s left is to deploy the API. You can create stages like “staging” and “production” and deploy different versions on the API to each stage. It is recommended to deploy a staging version of the API for testing before deployed the production version of the API for use in an application. Note that the name of the stage will be part of the endpoint URL. See API Gateway Docs on Deploying a REST API for a detailed walkthrough.

Lambda

AWS Lambda handles all of FeelGood’s computation. Within AWS Lambda, there are several important things that must be configured in order for FeelGood’s code to operate correctly.

Give Lambda access to SNS

By default, creating a Lambda function from scratch, adding SNS code, and pressing “Test” won’t work. Why? Simple, because the Lambda function does not have access to SNS. Cloud systems operate on a least-required permissions model, meaning that in order for your Lambda function to access SNS, you must explicitly grant Lambda access to SNS (and any other AWS services you might want Lambda to access). Refer to AWS documentation on IAM permissions for SNS, and check out the TL;DR explanation of IAM on the documentation site for this hackathon.

Set up environment variables for Lambda functions

Set up aliases for Lambda functions

Configure CloudWatch Trigger Invocation

Simple Notification Service

Gotchas & Lessons Learned

  1. Amazon SNS may have reliability issues that are outside of your control; message delivery to subscribers is not guaranteed. If high availability or reliability is important to your application, consider incorporating an API-accessible service which specializes in SMS, such as Twilio.
  2. Always, always, always set up robust logging. AWS streamlines setup of logging and performance monitoring for many services via CloudWatch. This was particularly useful when troubleshooting unreliable message delivery to subscribers, monitoring S3 usage, and monitoring the frequency of API requests.

via GIPHY