DEV Community

Cover image for An Upgrade: Part 1 — Devising an Approach
Guillermo A. Fisher
Guillermo A. Fisher

Posted on • Originally published at Medium on

An Upgrade: Part 1 — Devising an Approach

For a little over a year and a half, guillermoandraefisher.com has existed as a serverless application that is powered by a familiar blend of services: Amazon S3, Amazon API Gateway, and Amazon 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.

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 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 AWS Lambda functions built with Bref (which I’ve lauded on Medium 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. There’s a bare-bones search UI available at a search.html page that lets users dig through my old social media posts.

“Zaps” I’ve created to collect my social media activity in one place.

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 to see if any interesting connections exist.
  2. I want to develop working proficiency with a new language: Golang, 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 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 and use Amazon Athena to do some exploring. I’ll also use Amazon 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 has steered my attention towards React. 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!

Top comments (0)