Portfolio Reboot

React

Next.js

Styled Components

Strapi

Node.js

GraphQL

MongoDB

The Thought Process

To improve the process of updating my portfolio, I opted to implement a backend. Upon doing some research, I decided to use one of the many open-source Node.js headless CMS platforms to speed up the backend development so I can focus on the frontend itself. Open source and funding were why I ended up going with Strapi. Knowing that Strapi is well funded and open source means that the project has a good chance of outlasting the others, and even if it does go under one day I can maintain the backend code myself since it’s open-source. In addition to this, the open-source nature of Strapi allows me to directly edit the source code which allows me to add custom business logic to the controllers in order to extend the functionality of the GraphQL API beyond what comes out of the box. Next, I worked on picking the frontend technology. Knowing that I will one day be implementing new features, I decided to use a frontend JavaScript framework due to component reusability, which will help speed up development and keep the website looking consistent. Due to the unopinionated nature of the framework, I opted for React. One of the bigger downsides of using a front-end framework that utilizes the VirtualDOM is its impact on SEO and site speed due to having to render the website on the client side. This is where Next.js came into play. Next.js allows me to generate static and server-side rendered pages on a page-by-page basis, this will make the portfolio performant and easily indexable by search engines and bots. Lastly, I chose to use styled-components for my styling. I never have had the opportunity to use CSS-in-js on a professional project, so I figured this was the best way to gain some exposure to a technology that’s becoming more and more common. One of the downsides of CSS-in-js is maintainability and performance hits on large websites, but I don’t anticipate my codebase getting large enough for this to be a reason not to use it. Worst case scenario and I can refactor my CSS to their own files later on.

Since this project involved many technologies that were new to me, I spent a lot of time researching and reading documentation during the planning phase. In addition to this, since I was learning as I progressed with the project, I revised much of the codebase before I was satisfied with it. One of the more interesting challenges was the “Skills Grid” layout on desktop. This was very difficult to match the idea I had in mind while keeping it responsive. At first, I attempted to use empty divs to create the hexagon shape, however, I found this very difficult to scale the height and width and maintain the same shape. I decided it was best to use a single div, with a background image in SVG format, along with padding and margin adjustments.

Although this project was just a simple portfolio website, I still learned a lot. One of the most valuable lessons learned was how to properly structure a React project using best practices. Since I haven’t yet ever developed a React-based project in a professional environment, I never knew of the common patterns and best practices that developers stick to when working with a React project. Another topic I decided to learn and explore was the tradeoffs between CSS-in-JS and separating CSS and js amongst different files. In my opinion, the choice of whether to use CSS-in-JS or not in a project just comes down to developer preference. On one hand, you have the advantages of not having to think about CSS selectors and a “ready only” stylesheet that grows as the website gets older. But on the other end, you might run into performance issues and increased difficulty trying to track down styling errors because of the dynamic (and sometimes confusing class names, which you then have to match up to the JS code.