What Building a Full-Stack Database Project Taught Me That Lectures Didn't

A Computer Science student's reflections on building a real system, one broken query at a time

I began a Garage Management System as a project for one of my classes a couple weeks back. The brief was straightforward: a MySQL back-end, a Node.js/API with Express and TypeORM, and a React front-end with Redux Toolkit to connect the pieces together. We had studied normalization, ER diagrams and relational algebra in class. I thought that the hard part was over. It wasn't.

The Gap Between a Diagram and a Database

Lectures: An entity-relationship diagram is a completed artifact. You draw the boxes, you draw the arrows, you submit it, and it is right or it's wrong. Building an actual schema is nothing like that. When I started to try to wire dashboard statistics to real data, I realized that my initial schema assumed that all of the relationships in the system were clean and permanent. In real garages, there are those who abandon projects and leave without notice, bills that will be adjusted, and cars that turn up with slightly different names. But none of that is in a textbook diagram, and none of it is optional when you're building something that you actually want to run.

Debugging Is Its Own Subject

No one provides training on debugging as a course, but it consumed more of my time than any other component of this project. A broken TypeORM relation isn't as loud as a compiler error. It appears three layers removed, in a dashboard number that is lying in plain sight, or a chart that looks like it's window-shopping. I learned how to work backwards from bugs in the screen to the API response to the query to the schema. I have been instructed to walk the stack backwards (not necessarily guessing), and I learned that from no one single course. It was a result of getting the stuck feeling.

The Frontend and Backend Have to Agree on the Truth

With both layers of an application depending on each other, it was possible to discover a lesson that comes in handy when developing either layer alone: Applications need to agree on what a piece of data means, not just what it's called. A status field, a date format, a nullable column, each of these should have the same meaning on both sides or the entire system just goes off on a parallel track and becomes out of sync. It was the clarity of that agreement rather than any one framework feature that proved to be a key.

Progress Is Slower and More Honest Than It Looks in Class

It was a real accomplishment to complete the Dashboard Statistics module, it wasn't that it was flashy, but that each number on it was earned from a live schema. I find myself being less certain about the information now that I am in Analytics and using the Recharts visualizations, and verifying the information more. Not a good thing. This is between a finished project and a correct project.

What I'd Tell Someone Starting a Similar Project

Design your schema with the understanding that it's just as likely to be incorrect as it is to be correct. Instead of a guess and check, consider each bug a trace back exercise. But most importantly, make sure that your Frontend and Backend have the same interpretation of what the data represents, before you find out at the end of the day that they don't. There wasn't one of these on a lecture slide. It wasn't until I made something real and saw it break.