Unpacking the Benefits of Code Bundle Removal: Optimising Our Websites
Written by: Jennie Rowe Jersling, Product Manager @ Boozt
In 2015, the idea of Booztlet.com was born — our Nordic Designer Outlet.
When building Booztlet.com, we took a different approach than with our Boozt.com codebase. For Booztlet.com we decided to have one bundle for desktop and mobile for the webshop to be responsive.
As the company grew so did the webshops. More features and functionality were added and while the codebases for the two webshops shared the same core logic, everything else was separate.
We build a lot of valuable features, usually initiated on one of the webshops. If the feature is a success we end up implementing the same feature on the other webshop as well.
This means duplicating code. Especially backend, where the logic is the same and there is no real reason to have different backend code.
As a majority of features started on Boozt.com, Booztlet.com was always lagging behind as additional time was needed to get the new features duplicated on Booztlet. We recognised that it was becoming a problem.
This is where the reason for removing the separate bundles came from. It was an ambitious challenge as it required a site-wide change and would involve a big refactoring. It also involved the whole web branch with multiple teams that each have their own focus areas and expert knowledge of how their features work. A single developer does not have the in-depth knowledge that is needed to fully understand the intricacies of all features and functionality of the whole webshop.
We had to work together and coordinate so we didn’t miss anything. The goal was that our end-users would have a seamless transition and not be affected by our change.
How did we approach the challenge
We started with a proof of concept (POC) to check that the idea was even feasible. During the POC one of the challenges we met was that we could not simply hold the code locally and wait for one big release. It needed to be done over time and allow us to test on production to really see the POC in action.
Our initial concept of the POC was to stick with our feature flag system and it paid off in the end. With the awesome usage of our internal feature flag system as well as service workers from CloudFlare, we could safely push rather risky changes to production without affecting the end-user. It also allowed us to test each change internally over time.
With our feature flag in place, each webshop team could start working on their own focus areas, checking if any feature or functionality was missing and if all the styling was correct. We couldn’t simply drop the Booztlet bundle and start using the Boozt bundle. We had to compare on a component-by-component basis, using whichever was the best version.
Our Boozt bundle still uses Symfony templates in some cases, while Booztlet had more React based components. These were great opportunities to clean out some legacy code and refactor.
In the cases where both bundles used React components, then we identified which one could be used as a base for a common component, and used the code that was more recent and optimised.
When it was time to start testing on a wider scale and get feedback from our business team, we turned the feature flag on internally only in our office. We managed to find some issues related to our app endpoints and got fresh eyes on it to see if anything else was missed — “don’t forget to make the button the Booztlet-green” was something I feel like I said more than once.
The next step was to test on production with real end-users. We picked one country to go live in, and after we saw everything was stable we went live in all countries.
Thanks to all our previous testing with the feature flag, most issues were found and our end-users were not affected by the change. (See screenshots, do you see any difference?)
Booztlet PDP Before
Booztlet PDP After
The power of teamwork
As previously mentioned this project took the whole web branch, eight teams all with different focus areas. That’s a lot of developers working together.
I’m extremely proud of all the teams, their engagement, proactivity and drive to work together. It was an ambitious project that required a lot of collaboration to make sure our end-users, the customers, have a seamless transition. Together we managed to find the best solutions possible, both for meeting business requirements and for improving our codebase for themselves and future developers!
If you enjoyed this article, and want to read more great stories from the Boozt platform team, be sure to subscribe to the Boozt Tech publication!
Or perhaps you’re interested in joining our platform team? Then check out our careers page.
