Planning was my Key to Success

I am currently working through a coding Bootcamp and had a week to plan and execute a small app to show off some of the skills that we have acquired with Rails as our backend API and React as our frontend. I wanted to create something that utilized a shopping cart because it’s something that I had never attempted and thought this project would be a great place to learn. I knew the key to my success was planning out the foundation of my rails backend, I knew that if I made a mistake on the backend it would only bring pain and suffering when I started coding out the React portion of my app. For me and many others, the most painful part of working out the backend are the models, if models are miscalculated it can truly bring down the wrath of the gods upon the poor coder in the late game, so to avoid this wrath I sat and pondered over my best course of action.

The app that was being created was that of a humble business that was creating a place for people to buy and sell their Musical Instruments. Given the time frame, I was going to keep this very simple. I knew at the bare minimum I was going to need a User Model, a Listings model that would house the instrument and its details, and a Cart model for when a user found an instrument that they were interested in.

Knowing I needed at least these three models, that’s where I began, perhaps three was enough but I knew I couldn’t just set it and forget it without first doing some extensive testing to see if I could get the functionality that I desired. I started by drawing out my models and trying to think about their relationships.

So, in this case, a user would have many listings and a user would have many carts, a cart would belong to both a listing and a user and a listing would have many carts and belong to a user. I sat and pondered whether this was going to work for me, for my simple app this could work, but the more I thought about it the more I saw these model relationships limiting me in the long run. The limitations would come from my cart model acting as the join table between listing and user, this model set up was giving my cart model to much responsibility and less flexibility if I wanted to expand the project. Having to add up the cost of every listing across an array of cart join models sounded possible but sloppy and implementing a user’s shopping history or a favorites section started to sound a lot more simple if I take some time and adjust my models a bit.

What ended up making the most sense was to remove the cart’s responsibility as the join model and create a brand new model that would take on the responsibility of a join table between cart and listing. I dubbed this new model, item. The item would simply be the listing that was added to the cart, after drawing out this new model I felt like I could breathe again, less cramped and more room for flexibility.

In the end, the new configuration of my models ended up serving me well, it allowed me to add unique attributes that allowed the app to be able to expand with less resistance. The lesson I think I took away from this experience was that if you really take the time to map out the framework of your models before you take the first keystroke you’ll end up saving yourself from the pain of realizing late in the game that you have a mistake that will cost you time and frustration.