I've seen a few posts lingering around, bashing clean architecture for being too opinionated, or creating too much development overhead.
In my first few Flutter projects in the real world, it wasn't used and I'd barely heard of it. Only in my latest professional role had I come across it in the wild, and I'll admit: my initial take was unconvinced. What changed? My perspective on my next two side projects.
When developing Wrapd I decided to leverage clean architecture, and again when working on my latest project, On Court Tennis. I've realised that in all my previous projects, what I thought was a good separation of concerns, really wasn't. I couldn't just switch backend infrastructure on a whim with all my previous projects - I'd be stuck with a massive overhaul to remove existing and replace.
Now I can hear the clean detractors wailing "you're never going to change the backend services" or "you'd still have loads of work to do". I can answer these two - one at a time.
Never going to change backend services
Actually, I do. Right from the off. See, I like to develop my Flutter apps using the brilliant Very Good CLI. With this comes one absolutely pivotal feature for rapid app development: flavours (or flavors, for those who prefer American English).
You know what's useful to have when you're building software? Demo data that plugs straight into the app. I missed this with Wrapd but won't do again. On Court's dev flavour points directly to a dummy data layer implementation. That generates some test data on startup and holds the rest in memory on device. When I hot restart, everything is gone and it's obviously not that useful for profiling.
But you know what it lets me do? Completely develop my UI before I deploy anything to the backend. Iterative changes are now much quicker and much safer.
And it gives me a perfect mock data source for automated testing. I can also use it when automating screenshots for the app store and play store deployments thanks to fastlane. Those screenshots can be deployed safe in the knowledge that the app would look exactly the same with data from a real service. All because of clean.
You'd still have loads of work to do
Yeah - switching providers isn't easy. But I've worked in data environments before and I know that it's almost always possible to batch transfer large amounts of data when making a switch. Painful, yes. But possible.
So if you have backups and you get an unrecoverable server or service outage like kiwix posted on mastodon shortly before this article) your application doesn't have to wither and die with the trust your customers once had in you. You can recover from the unrecoverable.
And if you're using clean architecture then you don't need a full rewrite of your app - you only need fresh implementations of your data layer repositories (hooray!). They get their app back and you don't get a bunch of angry reviews on the app store or play store about how long they had to wait for it.
For example, Wrapd has a fairly complex API and data model, but switching the provider would require me to only rewrite 14 repositories - 14 classes that need to implement their abstract domain layer counterparts. With the right docs for whatever service I'm switching to, that's less than a day's work. Compare that to the 22 screens in the app (with more coming soon). On the surface, that sounds like a reasonable comparison, perhaps not much more work. However, each page might contain several API calls - finding and updating all of them without using clean would be tough. That 1 day changing repositories might become a week, or even a month to get an app without clean updated.
Still not using clean architecture? Better pray you never need to switch cloud service providers. Still not backing up? Better ask other people to pray too.
Final word - consistency
I've seen so many different patterns used in developing Flutter apps. They're all trying to achieve the same thing - consistency in your codebase. So why would I favour clean architecture over the others? In my experience, other mechanisms leave too much to interpretation in comparison to clean. That's arguably less important for me when developing apps by myself, but I like to remember that present Dave is different to future Dave. A consistent codebase helps that developer too. Would have been handy if past Dave knew that too - but that guy is an idiot.
Top comments (0)