Two architecture rules more people should follow

How can you better structure code and think about web applications?

1. Create multiple frontends #

Self-contained System (SCS)

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.

  1. Each SCS is an autonomous web application.
  2. 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?

  1. Keep code in the same file
  2. Keep related code files in the same directory

It's probably best to see an example of a UI component directory called Button:

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.

Share on Hacker News
Share on LinkedIn

← Home

Want to learn more?

Sign up to get a digest of my articles and interesting links via email every month.

* indicates required

Please select all the ways you would like to hear from Krzysztof Kula:

You can unsubscribe at any time by clicking the link in the footer of my emails.

I use Mailchimp as a marketing platform. By clicking below to subscribe, you acknowledge that your information will be transferred to Mailchimp for processing. Learn more about Mailchimp's privacy practices here.