For the last few years I’ve been a part of several brand new and phase one projects. No matter the size of the team or business this project has begun with, mistakes are going to be made. Here I’m going to outline some of the most impactful decisions and their consequences I’ve come across. Follow all these steps closely to run a truly terrible project.

Image for post
Image for post
Devs standing around while the first user tries out the new bicycle

1. Bootstrap your spiked work into production ready code.

“Oh cool I got it working, let’s use it how it is.” — Dev who just finished configuring webpack for the first time.

Understand the magic of what you discovered.

Generally at the start of a new project, there is some time put aside to figure out your stack and approach. Whether this is a totally new set of systems or a single new layer, you will find some form of spiking is done. An example would be an API server with a new library you haven’t used before. The first step would be getting it running with a nice ‘Hello world’ response, then maybe you’ll rope in some middleware to deal with authentication. At this point you decide, ok, cool lets commit that to master and we’re good to go, right? …


Image for post
Image for post

tldr: inside an s3 bucket with site hosting add a redirect.html file, a CloudFront distribution that loads the file and a route53 record set that adds an ‘Alias’ for the CloudFront distribution. Solution and code below.

My Journey to this solution

Recently I re-launched a new design of my personal site, this also involved moving the domain from joshuatoth.com to jjt.dev. Having registered joshuatoth.com on AWS and jjt.dev on google domains.

Before the launch I had my jjt.dev redirecting to google domains via the ‘redirect’ domain control. Super simple

Image for post
Image for post

But when I had to do the forwarding in the other direction AWS was not as easy. There are a couple of recommended forwarding methods that AWS has noted down, however these didn’t work for my use case. …


Building an AWS native, Node.js, serverless, event-driven system to back up an IOT device capable of real time messaging and events.

Image for post
Image for post

In August last year I had the opportunity to work on a greenfield project within the financial sector. The pitch to me was: An AWS native, Node.js, serverless, event-driven system to back up an IOT device capable of real time messaging and events. I was very intrigued.

Architecture

The architecture of the project was more or less your expected serverless stack:

  • Lambda (Node.js) For both the API’s and event handlers.
  • DynamoDB
  • SNS + SQS for eventing
  • API Gateway (Authorised, Unauthorised and several 3rd party restricted APIs for integrations)
  • Cognito (Security) With both ‘User Pools’ and ‘Federated Identities’
  • SES for emails

On the Build/Ci side of…

About

Joshua Toth

Holistic software engineer. https://jjt.dev

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store