Two architecture rules more people should follow
How can you better structure code and think about web applications?
1. Create multiple frontends #
The Self-contained System (SCS) approach is an architecture that focuses on a separation of the functionality into many independent systems, making the complete logical system a collaboration of many smaller software systems. This avoids the problem of large monoliths that grow constantly and eventually become unmaintainable. Over the past few years, we have seen its benefits in many mid-sized and large-scale projects.
- Each SCS is an autonomous web application.
- Each SCS is owned by one team.
What I like about it is that it helps with experimentation and makes migrations easier as you can update one SCS at a time instead of one big and risky update. It doesn't mean that monoliths are always a bad decision, but in my experience you start adding things which have nothing to do with its primary purpose. Sometimes it's analytics or a status page. On other times it's a new UI for some particular users (e.g., business partners). Instead of showing engineering feats of code splitting and lazy loading, it may be a better idea to just link to a separate page.
I like to ask a simple question. How much of the page is going to be re-rendered? If you replace most of the page, then a separate System might work just fine for you.
2. Keep the code that changes together close to each other #
It may seem similar to single responsibility principle from SOLID, but it's not the same. I don't value SOLID rules that high. They have some value, but I've seen them used as a reason for overcomplicated class hierarchies too many times. They are so abstract that you can use them to force almost anything upon your code. The more abstract and complicated, the more it seems to fit. That's a bad sign in my book.
So what do I mean when I talk about keeping code close?
- Keep code in the same file
- Keep related code files in the same directory
It's probably best to see an example of a UI component directory called Button:
- Button.js
- Button.test.js
- Button.css
- Button.story.js
One of the most important things for me is to keep tests next to the files they test. I have no idea why would you place them in a completely different directory structure. Maybe it made sense in the 90ties to make deployments a little easier? It has a strong IDE code smell, so please place test files next to what they test.
It would make sense to say I recommend Modular programming as it's something you can use both on the frontend and the backend.
Want to learn more?
Sign up to get a digest of my articles and interesting links via email every month.