Search for a command to run...
My name is Michael Lehmann. I'm a developer, architect, technical team lead and occasional speaker. I work for Zühlke Engineering AG as a Lead Software Architect aiming to help my customers and team mates to design and develop software. I specialised in developing distributed systems with micro-service architectures and modern web technologies.
No comments yet. Be the first to comment.
15 years ago, C# did not have a large variety of unit test frameworks and supporting libraries. That has changed in the meantime. The community has grown considerably and so has the range of libraries and tools that can be used for unit tests. While ...
If you read my blog regularly you may have noticed that I recently introduced pagination to my article list. In order of that, I would like to explain how I implemented that with the tech stack of my blog - NextJS and MongoDB. Pagination is one of th...
A good friend of mine once told me about a conference talk that was about so-called task-based UIs. I considered this architecture style for an application in a private bank which was responsible for checking the suitability for finance instrument tr...
I recently implemented a small hint showing the reading time of an article in my blog. This is a functionality used quite much when reading some technical articles written by the developer community. It helps me to decide whether I have the time to r...
In larger projects, the cooperation of several teams and long-term maintenance is always an issue. The architecture must be defined in such a way that such aspects are possible. This is often implemented with a certain degree of modularization. This ...
On this page
In my current project, we use Self-Contained systems to modularize large web applications into multiple applications. We were facing the question of how we should share code across our applications in the system.
Let's talk about our drivers to use the self-contained systems architecture before we go deeper into that question.
We were facing a situation, where our customer had two legacy systems running. They are doing more or less the same. Actually, one of them was supposed to replace the other one, which has never been completed entirely. For extending and replacing those two systems we have chosen the self-contained system approach. This gives us the flexibility to maintain and migrate separate parts of the system in the future more easily.
One important part of the self-contained system architecture is to keep them as independent and decoupled as possible, otherwise, we would lose the advantages why we have chosen this approach.
We are working on a couple of applications in this system now. The user should not really recognize that he/she is browsing multiple applications. We can't avoid page loads due to the architectural design we have chosen. But design, styles, and layout should not look different between the app.
Sooner or later, we need to think about, how we can enforce these constraints. Now, self-contained systems have a lot in common with Micro Services.
One strong recommendation when building micro-services is to not share code between the services. Sharing code increases the coupling between the services. And that makes it harder to maintain them independently. There are some companies like Netflix that purposely share code though, but I think they are the minority.
The rule to not share code is also valid for self-contained systems. We don't want to touch the entire system of systems when we, for example, update an application to a new Angular version. On the other hand, we don't want to fix bugs in code which is used from multiple applications multiple times. Or change the style in all applications manually.
We need to find a way in between. Sharing code directly creates a hard dependency on that piece of code and we want to keep the freedom to prioritize and decide when we touch an application. We decided to create versioned libraries containing the shared code. It is important to make it versioned because it allows you to update this library in an application independently and on demand.
Building, publishing, and consuming an npm library is easy. So everything fine? No! For us, it introduced a completely new constraint. We have two teams and we first had to learn how we handle this library. Questions like "How do we do versioning?", "How do we handle branching?" or "How do we handle changes, especially breaking changes?" needed to be answered.
We introduced Semantic Versioning to be able to express breaking changes. We are working in a mono repo. When we create a release branch we update the major version number of the develop branch to avoid version conflicts between the branches. And we keep a lean changelog to have an overview of the changes and breaking changes we did. We also have a gathering among the developers. We call it a dev exchange. This is the platform where we discuss and announce cross-cutting concerns like our shared libraries.
Would I do it again? I'm not that sure. It definitely brings some value for us. It works quite well for things like UI components and global styles, but it also introduced an overhead we actually don't want to have.
Nothing is a silver bullet. It did not solve all our problems with shared UI components at the end. With this approach, we still need to touch all the applications when we introduce a new navigation item. But that is another story.