Introduction

Welcome to the second post in my series to refactor my old project: HypeTracker. In this series I hope to detail my process in updating / upgrading my old project using best practices and other good stuff I have learned in the 2 years since I completed the project. You can find the GitHub repository here.

Origin of HypeTracker

It's rewind time

2018 was a different time in my life, I completed my first internship in IT and thought I knew everything when I went back to university. An "Internet Computing Technologies" course using JQuery and PHP? How archaic. Everyone knew NodeJS and Javascript was the future!

Okay, I might be exaggerating a little bit but from some of the comments about PHP, this is literally what people think about these technologies. (I do agree about JQuery becoming obsolete but that's an opinion for another time)

In the end, I did learn more about web technologies: the history of HTTP and how the various headers can be used, the client / server architecture and how service-oriented architecture helps supplement it, and other titbits which I can say I have successfully forgotten about.

Born from those learnings is my classmate's and my final project: HypeTracker. HypeTracker was an exercise in designing and implementing a 3-tier architecture application, splitting front-end from a vanilla PHP backend, which in turn uses SQL prepared statements (or basically just raw queries) to interact with a MySQL database. There was no testing, no documentation, no issue or pull requests. It was a perfect mess of an application. But it was a functioning mess.

Future of HypeTracker

Let's turn away from that mess now

As I talked about in my last post, despite all of HypeTracker's issues (or lack thereof), the project concept is still interesting and that is the reason I want to refactor it. Instead of creating yet another project, I figured, let's apply what I know now to my old project!

Current State

Before I can improve it, let's list out what was done.

• Front End
  • uses AJAX to search the database
  • login / logout
  • users have their own pages
• Back End
  • serves database data as an HTTP endpoint (form data)
  • password hashing / user authentication
  • session based user authorizations
  • routes are handled by separate files

Improvements

My recent philosophy with starting projects is: don't reinvent the wheel. My other philosophy with picking technology stacks is: pick the first one on DuckDuckGo. Which is why I will be migrating the project to use Laravel.

"Why don't you use technology x or y?"

I enjoyed working with PHP and there are always new technologies out there, instead, just pick one which has good documentation (yes, I did read through Laravel docs beforehand) and stick with it. You'll get more work done this way instead of bikeshedding.

Why Laravel?

If you thought I was joking about being the first result on my search engine, unfortunately, I was not. I knew I wanted to use a framework to speed up my (re)development of HypeTracker mostly because it's a personal project and the bootstrapped framework helps with tooling, conventions, and obviously, documentation. Don't be afraid of using tools to speed up your development, but also be sure to understand how the tools work or be able to implement it yourself given enough time!

Afterword

That's my rough plan! Despite noting in the last post I was going to move away from JQuery (and I will), I don't think I care as much about the front end just yet as opposed to the shift from vanilla PHP to Laravel. Instead, I'll make an interim post discussing how I changed a few specific functions from JQuery to vanilla Javascript.

Please leave a comment below if you will also be uncovering an old project to work on and your view on bikeshedding!