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.
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.
That’s the current state of affairs. I have 4 goals for this project:
- 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.
- I want to develop working proficiency with a new language: Golang, aka Go.
- I want to limit myself to serverless (read: fully managed, scalable) services because I’m lazy & cheap… or efficient & cost-conscious. Whichever you prefer.
- 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
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
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!