The Tipping Point - Part 2: The Stack

Let me begin by saying that my introduction to databases was pretty rocky. At the time I encountered ORM and it's assorted concepts I was working 60 plus hours a week, attending an online boot camp, and going to my local community college full time. Looking back on it, I may have bitten off more than I could chew. There were certainly areas that suffered because I wasn't able to focus on them as much as I would have liked and databases, specifically SQL databases fall squarely in that category.

I can lay the blame on being busy but mostly I just looked at the way SQL databases were organized and thought, "There's got to be a better way." The entire system of primary and foreign keys, immutable schemas, and data normalization just didn't make sense to me. I passed the class, by the skin of my teeth, but mostly it left me with a distaste for SQL databases that can be summed up for me as the real world just doesn't work that way. Now before the hate piles up on me, I know that these databases have existed since well basically the invention of modern computing. That they've stood the test of time and are widely used the world over but that doesn't mean they're the best or only way. So began my search down the road of NOSQL databases.

Because of its massive popularity, I almost immediately found my way to MongoDB. I liked that it was schema agnostic, I liked that the concept of documents and collections made almost immediate sense. I picked it up and begun to play around with it on some small MERN stack applications, working through tutorials and using it for a python web scraping application. Despite all of this it still wasn't really exciting, it didn't bring anything new to the mix besides being more intuitive and easier to use so I kept searching. That's when I found Neo4j.

Now for a database professional or data wrangling master Neo4j might not have been any kind of revelation but for me, it was immediately revelatory. Finally, I had found something that just made sense. There was an almost audible click inside of my head the first time I saw a Neo4j representation of a graph and how easy the relationships were to understand and traverse. In it, I knew I had found a way for this SQL simpleton to finally be able to model the relationships that I was hoping to work with. On top of that, the built-in visualizations for data beat the hell out of any ERD diagram I'd ever seen. Just look for yourself.

For me, the difference was clear. The Neo4j diagram requires no explanation to understand vs. the ERD diagram with its crows feet and non-intuitive structure. Now, of course, I've said before that I'm biased but having used Neo4j on projects for clients it's also great to see how quickly they can absorb the data and relationships right along with me. It's an incredible tool for presentations and explaining data. The patterns it helps to map are incredibly intuitive to people regardless of their knowledge of databases. People are visual, and having such a great visual way to show their data, hooks clients, almost immediately. In addition, the relationship labels are immediately humanly understandable which makes a massive difference when dealing with well just about anyone.
I'm going to wrap this up by saying that I've chosen the Grand Stack because of its use of Graphs and how easy, to me, they are to understand. GraphQL for the API, Neo4j for a Graph Database, graphs all the way down. In my next post, I'll go over Neo4j's GraphQL integration and how much easier it makes the development experience. In the meantime, you can check out the GRANDstack for yourself.