Has this happened to you?

Have you ever built something, be proud of it, and then years later realize that your product was not designed well? Maybe the UI didn't age well, or maybe you over-engineered a solution?

That's how I felt after a few years of experience.

I built my first professional portfolio in Fall 2017 using Django as a static site server, and thought it was my first big step in software dev. It had one page to include all of my experiences, and would constantly go down whenever Digital Ocean decided to do maintenance, even with Gunicorn and setting the process as a persistent thread.

Where did I go wrong? What did I do to make it better? Let's first talk about what made me want to go back and fix this issue.

The Original Portfolio wasn't Pretty

I was proud of my CSS skills from 2017. Well, not in 2020. For comparison my portfolio used HTML/CSS/jQuery served from the Django server. While not a bad solution for the time, I wasn't aware of UI libraries or tools like Sass.

The end result looked like a MySpace page out of the early 2000's.

The Original Portfolio was Bulky

Django is a mono-lithic Python web server. It has a lot of great features for an industry-grade web server like built-in SQL support, REST and Graph API support, and even SMTP support. It's a big package. Given that, it shouldn't be used for a micro-case like a personal website.

Hosting it was not simple

I mentioned that Django has built-in SQL support. Well, it actually requires at least Sqlite installed in the system. I mean, it's a web server. As a college student working two jobs and going to class full-time, I didn't have much money.

Digital Ocean is a great platform to give virtual machines to use for servers, but keep in mind that:

• You have to admin a Linux server
• You have to manage your Domain Provider
• You have to manage your own SSL credentials
• You have to decide how you want to manage the SQL Database
• You have to secure your server with fail2ban, SSH certs

And the list goes on. For a large scale application that would be used in a customer facing app, this would make sense. However, we're hosting a simple web page that maybe four people a year were viewing.

But where do we make this better?

When I started using React in 2018, I began to use React as the frontend application for a Django server application. They would work together in an organized Docker container chain and communicate to one another.

But this sounds even more complicated, right? That's what I realized after reworking it in 2018.

After I graduated from the University of South Carolina, I joined the workforce full-time, and wanted to spruce up my website. So I designed a basic framework for what I wanted to show others.

It had to do the following:

• Look pretty
  • I decided to use MaterialUI for hasty development
• Make the codebase easy to read
  • I used only JavaScript as to keep everything simple, and used React as the frontend.
• Make the hosting straight-forward
  • Netlify gave me a the CI/CD integration directly with GitHub and essentially runs itself

Using these simple steps, I was able to build a fast and easy website with React, MaterialUI, and hosted on Netlify in a matter of two days.

But are we done?

Unfortunately no. After learning more and more about the internet, I realized a few problems.

• My website would never be found on Google
• The SEO and Performance scores on LightHouse were sub-70%
• The website was not indexable since there was only one URL
• I felt like I could reduce how much data is being sent to the client
• I wanted to have a contact form, a blog, a timeline, etc.

I could have just built onto my React app, but after working more with frameworks such as Next and Gatsby, I realized I could use these to my advantage.

What did I end up building?

I ended up reusing parts of the React-based portfolio, but decided to use the following stack:

• Gatsby
  • As the ReactDOM framework to compile my React project to a static site, giving easy SEO and making pages easily to scale.
• TypeScript
  • Since we have to compile the project to a static site anyway, there is little overhead in performance. Using TypeScript made structuring data and props for components significantly easier to write and more readable.
• Sass
  • I wanted to reduce the size of pages being sent over the network, but I also wanted to make my CSS modular and easy to read/write. Sass gave me the tools I needed to build my own framework and make it easier than using base CSS.
• Contentful
  • Using Gatsby, we can query Contentful and pre-load blog posts and data with GraphQL. The free tier is more than enough for a simple blog
• GetForm
  • Alongside Formik and Yup, GetForm easily and seamlessly accepts data from the Contact Page and emails responses to me.
• Netlify
  • As with the first React portfolio, I chose to use the same hosting platform given the feature-set and generous free tier.

This sounds like a lot, but it actually was simple to set-up. I'll write a guide on how to set-up a portfolio given my own some day.

For now, you can see the final product at my GitHub repository