The component I’m talking about is the most underrated part of every stack. I learned that the hard way. I learned that the most neglected part of any software project is the database. And yet that’s where many of the improvements can be found.
Most applications produce or consume data of some kind. And that data is typically stored in a database — usually one of your own choosing. But that’s the question, isn’t it? How do you choose a database? How do you choose how you interact with the database? How do you know if you’ve made the right choice? Most developers I’ve met have a simple answer to this question: “Who cares?”
I mean, that’s what our actions say. We tend to neglect the data because the ramifications of bad design aren’t immediately obvious. If you screw up the CSS, you know immediately. But if you screw up the database, not so much. I mean, what does a screwed-up database integration even look like? Well, I think a well-designed database integration doesn’t get in the way of the logic.
For instance, when you have complex logic running on your data, the last thing you want is your storage format getting in the way. After all, I run a trading bot platform. And as you can imagine, there’s murderous complexity there to wrap your head around. Hence we spent a lot of time designing the database integration. We knew we’d have to eliminate as much friction between the data and the logic as possible. And now, we’re glad for it. A couple custom APIs and well-configured databases later, we’re all happy campers. The data doesn’t get in our way. It allows us to fully support our users, as we should.
Sure, the database might not change very much. And you might not even bump into it very often. But data is the foundation of most applications. So I truly believe it’s one of the most important things to get right. Good application design flows from a good data model. And a good data model in turn flows from a solid understanding of the problem. But that’s a story for another day.