Article authored by John Fontaine
Upgrading a tech stack is a common problem faced by any company. Web development, especially front end development, moves too fast to keep up and deciding on what to implement is largely based on current popular trends.
Basing decisions on the latest framework can cause vendor lock in and be very difficult to upgrade and/or replace later on down the road. Change, adaptability and flexibility are key elements to a business’ ethos in order to grow and thrive in an ever-changing market. As engineers, we must keep this mindset when making these important decisions and build a future proof platform.
At Vizibl, a SaaS company dedicated to helping companies work better together by providing a platform for procurement and collaboration, we experienced this exact problem.
Our very large Angular v1.5 monolithic code base had outgrown its humble beginnings and the entire development process needed to be improved. One issue was upgrading Angular v1.5 to a newer version which would be a challenging process and only to be reliant on the Angular ecosystem once again. Another major concern and probably the most notable one, how do you replace an enormous code base without taking years to release and allowing limited resources to focus on growing the business? As a startup, the business needs to provide value without the inconveniences of rewriting a new code base every couple of years.
The Strangler Pattern is an idea by Martin Fowler, a renowned software developer and author. While visiting Australia, Fowler observed a type of tree which would seed at the top of the canopy and gradually work itself down and root in the soil. Hence, “strangling” the host tree underneath and completely taking over. From a software pattern perspective, the concept is to maintain the old system and over time, replace small parts with new technology.
The initial investment needed to “plant the seed at the top of the canopy” and allow for gradual change, far outweigh a complete rewrite of a legacy code base. Resources are able to focus on the same objective and businesses not only get a more modern product over time, but stay operational in the form of new features and legacy support. Another issue of maintaining a legacy system is that it is understandably difficult to find developers that want to work with old technologies. Developers want to grow, learn and experiment with interesting projects.
With an acknowledgment of our problems and a good understanding of the Strangler Pattern, we started planning. We needed to decide which architecture would mitigate this future problem of being stuck with a legacy system again and being able to stay on the cutting edge of technology if we choose to. Let’s face a fact not many developers are willing to admit. What you write today, will undoubtedly become legacy tomorrow. In other words, there is a high probability that a more efficient solution will exist or a more modern implementation will be better at solving a problem.
This is something that is often overlooked when building software and making sure it’s future proof. Also, the legacy system should continue working without any glitches, but at the same time, load the new solution on demand. With a small front end team, we set out to solve this difficult problem with an incredibly simple solution. One year later, we have made tremendous progress and new features are being shipped at a constant rate with minimal legacy obstacles.
Our new front end consists of a component based architecture with many micro front end applications, all living under a mono repo. Components are all the rage now and with good reason. We created a reusable UI library which has helped us tremendously with speed of development, quality and consistency of our code base. The UI library gives us the possibility to build micro front end apps as if they were Lego blocks and it has created a common language between designers and developers. Early on, we decided to take a framework free approach and build a foundation based on solid software patterns.
We have also invested in Web Components because we believe it will be an important part of the front end community in the future. Our lean approach to developing has benefited us in many ways. Each app is developed and tested in complete isolation and then integrated into the Angular code base. We built a script injector module in Angular to lazy load our micro apps when required. Integration is not always straightforward and many times, it is a challenge getting both apps to work together. However, every time we release a new micro app, we are strangling our legacy system little by little.
Also, it has been easy to improve our new development workflow and allowed it to evolve over time. We do have a “way” of building apps, but it is entirely possible to build a micro front end app with any technology. This allows developers to choose the right tool for the job and future proofs our front end. Due to our framework-less approach, there is not much to upgrade, but every package can be safely upgraded and redistributed whenever needed. No software system is perfect, but with this architecture, I believe we have struck the right balance between flexibility, adaptability, and future proofing.
The front end landscape has become bloated with fashionable technologies. Making decisions based on the newest trend today will undoubtedly have an impact in the future. As engineers, we need to take step back, rely on simplicity for building software systems and incorporate upgrade-ability into the plan when starting out new projects. It is inevitable that hindsight, different experiences, and new technologies will help evolve parts of the system. It should be part of the development experience. Existing projects with large codebases could benefit from the Strangler Pattern by breaking down small solutions into isolated apps. Every business suffers from limited resources and wanting to grow their products as quickly as possible.
The Strangler Pattern makes the business reevaluate their current situation, plan for incremental change, and then take a leap forward. All the while, allowing for all resources to focus on new features and decommissioning anything legacy. For us at Vizibl, it has not been an easy journey, but the initial hard work and investment has paid off now, one year later. We are nowhere near to replacing the entire Angular code base yet, but we have taken huge chunks of features, both new and old, out of angular.
Due to our new streamlined workflow, we build, test, and deliver much faster. We now have a consistent process to safely and gradually improve an out of date system and fulfill the future needs of the business and developers.
Article authored by John Fontaine