Goldilocks is a full stack application; we used React.js on the front end, Node.js and Express server-side, and Postgres with Sequelize for our database handling. While our database was nowhere near being classified as complex, it was the most nuanced approach anyone on my team had ever been faced with, and while a bit overwhelming at first glance, it was my favorite aspect of the project especially because I developed what I think are some really solid habits that lend themselves to best practice.
My database handling practice has come such a long way in the past couple of months (and it still has, undoubtedly, a lot of room for growth!). It’s sweet to reflect on how it has evolved & how my skills have, in time, loaded:
In my first semi-autonomous project, I was setting up components on the front end that made HTTP requests via Axios to the database, which then sent the response back to the front end, where I waited for that response to make another request to the database...
This approach was getting me the responses I was looking for, but I had a feeling that this wasn’t right. On my second project, a teammate helped me realize that that should all be done on the backend. I consolidated my requests a bit in that only one HTTP request was being made to the database from the frontend, but the code on the backend was a mess! I was chaining queries to other queries, and oh boy, there were many lines of code to be had.
This also did not feel right! It was easy to get lost in the code and be unsure of what response was coming back from where, so when it was time to get started on Goldilocks, I did some research into more efficient database querying. My crown jewel was discovering “eager loading” and learning that all of the database queries associated with one specific request from the frontend could be bundled into a singular response.
It took me a couple of tries to get it right. For it to work as intended, all model associations need to be set up properly, so my team and I had to go back and update our foreign keys (Postgres uses camelCase by default and not snake_case like we thought!) and then ensure all of our hasOne / hasMany / belongsTo / belongsToMany statements accurately demonstrated the relationships we were setting up. It was a hurdle having to go back and do that, but I knew that taking time to go back and adjust our models would pay off once we could integrate eager loading into our database query workflow. Once we got everything reconfigured, I could not stop singing the praises of eager loading! And what is even funnier is that four months ago, I was convinced that backend was not for me! I'm now finding myself getting fixated on learning more about query performance and being confident in my choices of data handling, and now that Goldilocks development is being put on hiatus & my program is wrapping up, I'm excited to transfer what I've learned thus far into a career.
Thanks for reading for the past couple of months y'all. Ttyl.