To me building out an application is less about sticking to every rigid requirement, and more about building harmony in your codebase. As an application grows, and business requires new needs, those early requirements will either evolve or be thrown out the window. So what are you to do when architecting? In my opinion, you should take inspiration from water.
Why Water
Water is probably the most versatile element we have in existence. It comes in all shapes and sizes and ranges from enjoyable to dangerous. One raindrop falling from the sky causes no commotion. However, that same raindrop, in conjunction with a multitude of others falling rapidly per second will create a dangerous storm. That’s pretty much how I see application infrastructure.
The First Drop
Like a great thunderstorm, vast ocean, or overwhelming flood, a great architecture starts with one drop. To me this is no better showcased by building your collection of simple stateless components.
This could be anything from an input field component that handles showing validations for you or a general use component placeholder loading wrapper. It all has to start small and then scale up.
Drops Join In Unison
Once you have enough individual components set up, that’s where the fun begins! While each individual drop does a solid job on it’s on, they do so much more when built together with other drops!
Now that you’ve built out the core of your application into general use components, you’re able to easily join them together as needed to start building out your application while also being in a great position to scale as needed.
The Big Splash
At this point your application should be in great shape. You have a generous amount of dumb grunt level components, and they prop up other components of higher importance. Good job! So with that take a step back, and think about how you just built this application of yours with a couple of practical use cases.
Say for some reason there is an issue with the way the validation methods appear on our general use input field. Of course you don’t worry because that field is a dumb component that once you fix it in one place everywhere else is good as well.
That’s the key in building out applications this way, as opposed to a per page/screen basis. At the end an application isn’t measured by how fast it was built, or by the degree of complexity it was built with. In reality, it’s about addressing your business concerns in an architecture that can easily shift when needed with little to no fuss. As well as the developer experience in it being enjoyable 🙂