An Upgrade: Part 1 — Devising an Approach
Tags: serverless, data, aws, continuouslearning
Published: 2020-02-16 03:25:07

---
title: An Upgrade: Part 1 — Devising an Approach
published: true
date: 2019-09-27 01:39:17 UTC
tags: serverless,data,aws,continuous-learning
series: An Upgrade
canonical_url: https://medium.com/@guillermoandrae/an-upgrade-part-1-devising-an-approach-9b05090a50a8
cover_image: https://cdn-images-1.medium.com/max/1024/0*ji9rNBbIsr5SOAyi
---
For a little over a year and a half, [guillermoandraefisher.com](https://guillermoandraefisher.com) has existed as a serverless application that is powered by a familiar blend of services: [Amazon S3](https://aws.amazon.com/s3/), [Amazon API Gateway](https://aws.amazon.com/api-gateway/), and [Amazon DynamoDB](https://aws.amazon.com/dynamodb/). Things have changed significantly since I first deployed the index.html file — for me, and for some of the services I’ve been using. In this series of posts, I’ll discuss my mistakes, highlight relevant services, and walk through the overhaul of my small, drab corner of the Web.

### Continuous Learning

As a people manager, writing code isn’t something I do on a regular basis. Occasionally, though, some extraordinary circumstance forces me to enter scrupulously into a production code base and completely wreck a Scrum team’s velocity.

{% tweet 1165383036642312192 %}

I’m tasked with developing people instead of applications, and that charge presents its own set of fascinating, difficult challenges that do not leave room for much else in my work day. However, I do need to keep up with trends in pertinent tech, and I find that iterating on my unfrequented personal website in my downtime is a low-pressure way for me to get hands-on experience with contemporary tools of the trade. At my domain, I am free to fail, often and spectacularly, without consequence. That freedom is fertile ground for foolishness (like unwarranted alliteration), and it allows me to entertain grandiose ideas such as re-architecting an application from the ground up… and blogging about it.

### Devising an Approach

The home page of my website is made up of a few paragraphs of text, a small number of links, and footnotes that I personally think are fairly amusing. A RESTful-ish Web API called “Andrae” is available at the [api subdomain](https://api.guillermoandraefisher.com) and flaunts three endpoints: /posts, which is where anyone interested can get their hands on my social media posts in JSON format; /elephpants, which is an example endpoint I put together for a talk about [PHP](https://php.net) [AWS Lambda](https://aws.amazon.com/lambda/) functions built with [Bref](https://bref.sh) (which I’ve [lauded on Medium](https://medium.com/@guillermoandrae/automate-deployment-of-php-applications-to-aws-lambda-with-bref-aws-sam-and-travis-ci-90231dfae6ff) in the past); and /nicknames, which is a worthless collection of nicknames that I’m definitely going to delete but am mentioning here for posterity. My social media posts are pushed to the API with [Zapier](https://zapier.com). There’s a bare-bones search UI available at a search.html page that lets users dig through my old social media posts.

![](https://cdn-images-1.medium.com/max/667/1*p3mZAHQVBImXRNrdHMU_fQ.png)<figcaption>“Zaps” I’ve created to collect my social media activity in one place.</figcaption>

That’s the current state of affairs. I have 4 goals for this project:

1. I want to be able to answer questions about my social media activity using the data that I’ve been collecting. I’d like to marry it up with my [health data](https://www.apple.com/ios/health/) to see if any interesting connections exist.
2. I want to develop working proficiency with a new language: [Golang](https://golang.org/), aka Go.
3. I want to limit myself to serverless (read: fully managed, scalable) services because I’m lazy & cheap… or efficient & cost-conscious. Whichever you prefer.
4. I want to build a more engaging, more responsive, modern web application that features a proper RESTful API — and eventually a GraphQL API, just so I can say I’ve built one.

#### The Data Store

I’m going to continue to use DynamoDB as my primary data store. Given that my traffic numbers are low, I’m in no danger of exceeding [the AWS free tier](https://aws.amazon.com/free/?all-free-tier.sort-by=item.additionalFields.SortRank&all-free-tier.sort-order=asc&awsf.Free%20Tier%20Categories=categories%23databases&awsf.Free%20Tier%20Types=tier%23always-free) usage thresholds anytime soon, which means it won’t cost me anything to store my data. Said another way: it’ll cost me $0.00 to keep my data in a fault-tolerant, highly available, managed NoSQL database.

#### The Data Story

To analyze my data, I’ll catalog it using [AWS Glue](https://aws.amazon.com/glue/) and use [Amazon Athena](https://aws.amazon.com/athena/) to do some exploring. I’ll also use [Amazon QuickSight](https://aws.amazon.com/quicksight/) to put together visualizations.

#### The Web API

I’ve already mentioned Go — I’ll be using it to build at least one API endpoint. The others will be built with PHP and Bref. All endpoints, regardless of runtime, will be composed of Lambda functions that are exposed via the API Gateway.

#### The Front End

[A change in my professional life](https://www.linkedin.com/in/guillermoandrae/) has steered my attention towards [React](https://reactjs.org/). I need to have some idea of what it’s like to work with it because I support people who work with it every day. I’m especially motivated because it seems jQuery has fallen out of favor with the JavaScript crowd, and I’m mildly embarrassed that I still rely on it so much. The React app will live in S3.

### Next Steps

I’m going to start this off by getting my data in order. I made some critical errors with DynamoDB when I started, but I’ve since learned a lot about the service, and I’m eager to apply what I’ve learned.

Stay tuned for Part 2 in the series, friends!