RETROSPECTIVE

October 10th, 2021

Writing Kubernetes Tests with Go

Kubernetes

Go

+2 More

These days, most of my application infrastructure exists on Docker containers, orchestrated by Kubernetes. My AWS account has a Kubernetes cluster, which is hosted using EKS (Elastic Kubernetes Service). Since two of my production applications (jarombek.com and saintsxctf.com) run on this Kubernetes cluster, the health of their infrastructure is critical. To help ensure that the Kubernetes cluster is running properly, I created tests which check the state of my Kubernetes objects and ensure that they exist on the EKS cluster as expected.

This article explores my Kubernetes test suite, which is written in Go and leverages the Kubernetes Go Client. It also describes how the test suite is run on an automated schedule, alerting me when test failures occur.

RETROSPECTIVE

September 24th, 2021

Creating Reverse Proxies with Nginx and Docker

Nginx

Docker

+2 More

Many of my applications contain frontend components and API components. These two components are loosely coupled but communicate with each other over HTTPS. For example, my saintsxctf.com application has a React frontend which communicates with a Flask REST API backend, along with other API Gateway REST APIs. One way to accomplish communication from a frontend to an API is by explicitly writing the URLs of the APIs in the frontend code. This works fine, but it also exposes information about API origin servers to clients. Origin server information exposure can be avoided by passing all API traffic through the same URL as the frontend application. This is accomplished using a reverse proxy.

The following image shows my SaintsXCTF website, and how the URL of the API is hidden from clients. If users inspect the website's network traffic, they see HTTPS requests sent to the reverse proxy server for saintsxctf.com, instead of the actual API server api.saintsxctf.com.

DISCOVERY

August 11th, 2021

Building Cypress End to End Tests in TypeScript

Cypress

TypeScript

JavaScript

Cypress is an end to end (e2e) testing framework written in JavaScript for front-end applications. Cypress tests run in a Chrome web browser or a headless browser, navigating through and interacting with web pages. It's reasonable to compare Cypress to other test automation frameworks such as Selenium or Puppeteer; however, unlike those frameworks, Cypress was created specifically for writing end to end tests. Because of its test first design, Cypress provides lots of features that make writing end to end tests easy. It is currently my preferred end to end testing tool.

While Cypress tests can be written in JavaScript, as is the case with my jarombek.com application, Cypress also has TypeScript support. Nowadays, I write most of my front-end applications in TypeScript due to its type safety. In my experience, TypeScript helps reduce the number of bugs and type mismatch mistakes in JavaScript code. For applications written in TypeScript, it is great to be able to write Cypress tests in TypeScript as well. This helps keep the programming language uniform across the front-end application code and test code.

DISCOVERY

August 2nd, 2021

Writing Less Stylesheets

Less

CSS

Sass

When it comes to CSS preprocessors (stylesheet languages that add features on top of CSS and transpile to CSS), in the past I've often used Sass. When I first started learning about CSS preprocessors, the two main choices were Sass and Less. The reason I decided to learn Sass instead of Less was due to its greater popularity and me trying to follow industry trends. At the time, Bootstrap had just released version 4, which switched its stylesheet language from Less to Sass1. In my mind, it didn't make sense for me to learn a preprocessor language that was being left in the dust.

Over time, I increasingly wished to learn the difference between Sass and Less. It was hard for me to tell if there were differences in the functionality of Sass or Less, or if Sass was picked as the favorite due to syntactical preferences and third-party library support. Last year I wrote two front-end application prototypes, graphql-react-prototype and apollo-client-server-prototype. Instead of using a stylesheet technology I already knew such as Sass or JSS, I decided to learn Less and use it as the stylesheet language for these prototypes.

RETROSPECTIVE

July 31st, 2021

Building a GraphQL React Prototype

GraphQL

React

+5 More

Last year, I started using GraphQL at my job. I decided to create some GraphQL prototypes in my spare time, to get better acquainted with the GraphQL ecosystem. In 2018 I learned the basics of GraphQL and wrote two articles about my experience, but never dove into using GraphQL in real world applications. The GraphQL React prototype discussed in this article along with my Apollo prototype are the beginnings of that production application journey. In the future, I plan on using GraphQL for the API layer of my applications.

The GraphQL prototype discussed in this article is a React front-end application that connects to a GitHub GraphQL API. The API provides details about my repositories, and React displays those details in a dashboard. The dashboard is shown below.

DISCOVERY

July 26th, 2021

Creating AWS CloudWatch Synthetics Canary Functions with Terraform

AWS CloudWatch

AWS

+6 More

AWS CloudWatch Synthetic Monitoring is a platform that enables the creation of functions that monitor applications or APIs. These functions are known as canary functions, and they use AWS Lambda for their infrastructure. Canary functions are written in JavaScript or Python. They utilize Puppeteer (JavaScript) and Selenium (Python) for browser test automation.

I started looking into Synthetic Monitoring as a way to test my SaintsXCTF application running in production. I had an issue where the website unexpectedly stopped working, and there was no automated process in place to alert me. With Synthetic Monitoring, I created canary functions to test critical paths of the website, such as signing in a user. If canary functions fail, I get an email alerting me of the issue.

DISCOVERY

July 3rd, 2021

Exploring AWS DynamoDB

DynamoDB

AWS

+7 More

DynamoDB is a NoSQL database on AWS specializing in key-value and document storage. DynamoDB is fully managed by AWS, meaning users don't need to provision any servers for it to run on. I often compare DynamoDB to MongoDB, due to their similar functionality and JSON document/item structure.

Recently, DynamoDB has come up quite a bit in engineering conversations I've had in relation to building cloud native applications. I wrote a series of articles on MongoDB in 2017 while I was prototyping with the database. Recently I did the same with DynamoDB, creating a sample DynamoDB table with Terraform and using AWS SDKs to modify and test its contents. This article discusses what I've learned about DynamoDB and showcases my prototype code.

DISCOVERY

June 30th, 2021

Styling React Components With JSS

JSS

React

+3 More

In my previous article on JSS, I discussed the improvements JSS makes over traditional CSS stylesheets and CSS preprocessors such as Sass. JSS utilizes the highly expressive JavaScript language, enables style reusability, dynamic styling, and provides name conflict resolution. Although JSS works with any front-end framework or library, it really shines when paired with React. In this article, I begin by discussing the basics of JSS in React applications. Then, I show sample code from my SaintsXCTF application, which is running in production and utilizes JSS for its stylesheets.

DISCOVERY

June 29th, 2021

JSS: The New Standard for Stylesheets

JSS

JavaScript

+2 More

In my relatively short time as a software engineer, I've used many different approaches to writing stylesheets for web applications. My initial naive approach was writing a single CSS stylesheet per application, such as the styles.css file for my SaintsXCTF application that I wrote in college. Although this was a common practice in the early days of web development, lumping an entire website's styles into a single file has many downsides. First, a single stylesheet is difficult to read and gets very long. Second, it doesn't follow programming principles like DRY (Don't Repeat Yourself), abstraction, and encapsulation. Third, CSS lacks many programming language features which enable scalable and reusable code, such as functions, conditional statements, and variables.

June 29th, 2021

While writing this article I learned that CSS recently added variables into its specification1. Variable support is a great new addition (although, unsurprisingly, it is not supported by Internet Explorer). If CSS continues to improve, I may consider its use in certain future applications.

RETROSPECTIVE

June 18th, 2021

SaintsXCTF Version 2.0: AWS Infrastructure

AWS

Terraform

+7 More

The infrastructure for my website saintsxctf.com is hosted on AWS. SaintsXCTF had AWS infrastructure prior to version 2.0, but it was redesigned and rewritten for the new version. This article outlines the infrastructure and walks through Terraform code which configures and builds the infrastructure.

RETROSPECTIVE

June 14th, 2021

SaintsXCTF Version 2.0: Architectural Overview

AWS

Kubernetes

+20 More

On December 24th 2016, I released my first website saintsxctf.com. I was still a senior in college at the time, and used my limited software development knowledge from classes and a summer internship to build the application. SaintsXCTF is a training log designed for my college Cross Country and Track & Field teams at St. Lawrence University. Running competitively in college had a major impact on my life, and I was really proud to create the website to assist my teammates and coaches. Shortly after releasing the website, I created an Android application and an iOS application for SaintsXCTF. With SaintsXCTF accessible via web browsers and mobile applications, I felt my development work was complete and moved on to other programming projects.

As I began my professional software engineering career in the summer of 2017, I gradually learned industry best practices and became more well rounded as a developer. At this point, certain shortcomings and misguided assumptions about my SaintsXCTF applications became apparent. First, the core web application and API did not follow the latest industry standards. Second, all three applications were not properly tested and were prone to degradation if left unchecked. Third, the security & infrastructure of the applications was very basic and not fault tolerant. Lastly, my assumption that releasing the applications meant my work was done proved to be incorrect. As all software engineers know, the work just begins when an application is initially released.

RETROSPECTIVE

November 5th, 2020

Building a Reusable React Component Library

React

JavaScript

+2 More

Front-end applications, specifically those created with React, are built with small reusable JavaScript functions called components. Each component renders and handles the business logic for a small chunk of the application. Components have props, state, and elements that render on the screen.

For developers working on multiple React applications or working for an organization that uses React, there are benefits to using reusable component libraries. Component libraries are shared amongst applications and contain generic components such as buttons, accordions, and form elements. Besides the obvious benefit of code reuse, component libraries help enforce organizational style guides and allow developers to easily iterate on components used in all their applications. Component library setup is easy and can save a lot of front-end development time in the long run.