Frontend

An aspect of web development I've been looking to improve on for a while has been frontend development. Most of the roles that I've been in so far has demanded my backend skills, so I didn't really have a need to expand on the frontend, despite having a bit of experience in this area. Now, I've been given a better reason to expand my skillset (and an excuse to create a Frontend Mentor account).

For the frontend, I chose to use pure HTML, CSS, and TypeScript. I considered using React.js, but wanted to wait a bit before delving back into frontend frameworks. HTML, CSS, and JS each offer a powerful toolset, and, when used correctly, can create basically anything you want. Frameworks mainly (from my understanding) serve as a way to simplify the workload for you in favor of a more agile development process. I was used to static typing when working with the backend, and also wanted IntelliSense to help me in identifying DOM elements, so using TypeScript and compiling into JavaScript worked in my favor.

However, I had a problem. My initial frontend was trash not up to par with my expectations. Knowing the tools for HTML, CSS, and JS doesn't really teach you design principles, so I realized that I had to invest some time in developing my frontend skills. When I came back, I ended up with a design that I liked, and could extend/revamp for the future. If nothing else, I learned how essential UI/UX designers are for frontend development.

Backend

While the frontend did take a bit to get used to again, once I got the hang of it, design was my only enemy. Compared to the backends I've worked on before, the logic for the code wasn't too bad, and I didn't think the backend for this portfolio would be that difficult to do either. However, what ended up putting my dedication to the CRP rule to the test was working on the backend for this project. I used Terraform for my IaC tool since I've been wanting to learn more about the tool for a while, and it wasn't that bad to use. What I didn't realize, after using ClickOps for so long, was how much the AWS console automated for me when using different services.

Since I've recently created a new AWS account (despite having an old one) for following examples tutorials online while studying for AWS certifications, for this project, I chose AWS as my cloud provider (which will most likely be the same for a while as I continue creating cloud-based solutions). In order to consistently count the total website visits, I needed a database, an API endpoint, and a lightweight backend. DynamoDB provided a database that I can store the website visits in, API Gateway provided the API endpoint to receive and process requests, and AWS Lambda provided the lightweight backend for me to be able to handle requests and read/update the database accordingly.

What took about an hour and 20-30 clicks on the AWS console took about a week to learn how to configure using Terraform. The console had abstracted things like aws_lambda_permission, aws_cloudfront_origin_access_control, and provided defaults for most resources and roles, so I didn't really have a need to learn them in order to get things working using ClickOps. Terraform certainly didn't abstract these. I understood that this was most likely the annoyance that drove developers away from working with the Cloud in favor of just understanding more about open source tools like Docker and Kubernetes.

However, it was through tinkering with these resources that I had to give them greater attention. After having to continuously look at IAM policies, the structure of Statement, Effect, Principal, Action, and Resource became regular to me, which helped with understanding their purpose. I didn't initially realize that certain policies had certain purposes (such as an assume role policy only being for services to be able to assume an IAM role due to an API call being made, and, as such, required for there to be no Resource field in its policy), but having to look that up gave me more contextualization for how IAM policies are used.

In addition, another task that I had was to put my static website in an S3 bucket hosted by a CloudFront distribution attached to my DNS name and HTTPS enabled. One of the greatest benefits of Terraform is that it has great documentation (and great copy + pasting), but this didn't keep me away from errors. One bug took me about 2 days of Stack Overflow and GitHub issues sifting, ChatGPT asking, TF_LOG_FILE surfing, and Google searching to the point where Google basically couldn't give me any more relevant results for my problem.

My CloudFront distribution wasn't being made, and I kept getting an error that I had an invalid viewer certificate on my distribution despite having a valid certificate provided by Amazon Certificate Manager (imagine the frustration!). There was even someone else with the same exact problem as me, and the problem was left unsolved! If there was no solution in that thread nor anywhere else online, then I didn't really have much to go on... and my website would only allow HTTP instead of HTTPS (imagine the horror!).

Surprisingly, not through ChatGPT, but through examining the TF_LOG_FILE, I found the source of my problem. The CloudFront distribution was being created on my old AWS account!

Since I've recently created a new AWS account (despite having an old one) for following examples tutorials online while studying for AWS certifications...

I didn't expect for this to bite me. On my local computer, I have 2 profiles configured for AWS: my default profile tied to my old AWS account and a new profile tied to my new AWS account. Since I was using my new AWS account for deployment, I explicitly stated in my main.tf file:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

# Provider blocks
# For certificate management
provider "aws" {
  alias   = "us_east_1"
  region  = "us-east-1"
  profile = "NEW PROFILE"
}

# For resources
provider "aws" {
  alias   = "default"
  region  = "us-east-2"
  profile = "NEW PROFILE"
}

However, I suppose stating these things wasn't enough for Terraform. I switched the alias name and explicitly stated the alias for all resources that I created. This was enough for Terraform to understand that I wanted everything on the same account (despite me already stating this), and for me to be able to add a comment to the GitHub issue. Since I've always just sifted through GitHub issues for resolving bugs (mainly for work), I've never added to one before, so this was a nice change for me.

After resolving some DNS issues, and getting accustomed to creating resources for basically everything (especially for API Gateway -- the AWS console does a lot of the work for you there), my backend was finally ready! Since my static website was the origin of my distribution, it was just a matter of changing a couple lines of code to get the counter working on the frontend, and everything was ready to go.

In the end...

There's a long road ahead of me when it comes to learning more about the cloud and being a full stack developer. While there was a lot of knowledge gained, one thing is certain: continuous learning needs to be a routine. Through consistency, I have confidence that I'll be able to refine my craft and achieve the results that I’m looking for.