DEV Community

Cover image for Pro Tip: Don’t overcomplicate content storage / the database from the start
Filip Iulian Pacurar
Filip Iulian Pacurar

Posted on • Originally published at pacurar.dev

Pro Tip: Don’t overcomplicate content storage / the database from the start

Part A – The problem

I’m currently working on a fairly complicated project that basically is a single-page app having just a quiz. Based on the answers you give, you receive a special report and solution at the end. Something regarding loans and financial stuff.

The problem is that those questions must be editable from an admin interface within a Laravel app and as I was building the actual form and logic, I found myself writing a lot of migrations and changing database structure a lot. Run php artisan migrate:fresh --seed over and over again until you reach the perfect shape of the database, right?

Well… not necessarily. In my current project, even this was overkill because I found myself changing the structure from a refresh to a refresh of the page.

Part B – The alternative solution

In the project I am talking about I have a small GraphQL API that returns to the React frontend the set of questions to present to the user. What I’ve done is a “hack”: I thought myself, does the data actually need to come from the database right from the start? Couldn’t I somehow “mock” the set of questions? Well, GraphQL or the actual API endpoint can return the data from any source, the important thing is that the front-end needs the right structure.

What I’ve done is this: I created a YAML file with an array of questions and in that file, I could structure the object however I wanted – remove keys, add keys, change the shape of objects, anything… any change would just need adjusting in the YAML file and then CMD+S and boom, the API endpoint returned the new format.

Basically, you can load a JSON, Yaml, or any format you want and when you’re done and have the content in the final structure you want, you just create the database table in that format and you’re done with it. No more 100 migrations per minute, just a final migration that just works.

Alt Text

Closing thoughts

We tend to over-complicate everything in development, when in fact we should choose the more simple path for us to keep our sanity. What’s the point of going through a lot of database changes when you can freely explore ideas using a mocked set of data?

Remember: keep going back to the basics. It’s simpler for you. Don’t just blindly follow conventions unless you want to reach the burnout phase quicker than the other programmer fellows.

Originally posted on my blog only

Top comments (0)