Merging Two Front-End Applications
Over the past several years, Managed by Q has been undergoing a transformation from a tech-enabled cleaning company into a software platform for office management. One key part of our transformation has been the addition of a new Task Management capability to our platform, which lets office managers organize and track employee requests. Rather than build this capability from scratch in-house, we chose to acquire Hivy, a French startup that had already developed a popular tool for this purpose, and integrate its product into ours.
Integrating two entirely separate products with different but overlapping user bases gave us plenty to chew on. We had to get from two separate products with two separate authentication and identity systems to a seamless user experience with a single frontend, and continue serving existing customers of both products without interruption throughout the integration process.
We decided early on to keep the Hivy backend running as a separate service. We shared user data between the two backends and made the Q backend the source of truth about users, so that Hivy users were able to use the product with a Q user account.
The front-end presented a greater immediate challenge. We knew that to deliver a great user experience, we would need to fully merge Hivy’s front-end with our own. We took a two-step approach to achieve this goal. First, we served the Hivy front-end in two different products simultaneously. Then we followed up by fully merging the two front-end codebases into one.
One front-end, two products
We had several requirements in mind as we developed the initial version of our integrated product. First, we wanted to reuse as much of the existing Hivy front-end code as possible, displaying the Hivy interface within our own. Second, we needed to continue operating the existing standalone Hivy application in the interim to support current Hivy customers. And third, we wanted to avoid forking the Hivy front-end codebase and maintaining two separate front-ends, because we wanted to continually add new features to Hivy throughout the integration process and did not want to add the same features twice.
These requirements led us to serve the same Hivy front-end code in two products simultaneously. The Hivy front-end code would continue to be used in our standalone product throughout the integration process. The very same front-end code would also be used as a secondary JavaScript bundle within our integrated application. A feature flag allowed us to render different user interfaces in the integrated and standalone front-ends without forking the codebase.
How did we get the same front-end code to appear in two different applications? We moved Hivy’s front-end code into Q’s front-end repository, bundling it separately and deploying it to Amazon S3 alongside our own front-end. We then exposed an endpoint in one of Q’s backend services that allowed the Hivy backend to retrieve front-end assets via the Q backend.
Merging the front-end code
While we were able to use the same front-end codebase in two products, we now had a new problem: a convoluted architecture in our integrated product. Thanks to an aggressive makeover, the integrated app looked like a single unified front-end, but behind the scenes it now consisted of two different JavaScript bundles, with different dependencies, build pipelines, and architectures.
We knew that this architectural debt would slow down our future development. For example, if we wanted to add a new feature to the navigation bar that appeared at the top of the user interface, we would need to build it twice: once in each front-end bundle. We would also be unable to share state between the two applications, so our ability to build features that crossed the architectural boundary of the two front-ends would be impaired. For these reasons, we decided to follow up by fully merging the two front-ends into one.
Both front-ends were written in React. To merge them, we first had to harmonize all dependencies across both apps, from React on down to the most minor library, and then use the same package.json and Webpack config files to build both. From there, we set about converting the entire Hivy front-end into a React component that could be nested into the larger Q front-end instead of being bundled as a separate application.
When we switched from serving two front-ends to one front-end, users didn’t notice any difference. But by combining the applications into one, we were able to share state across the full experience and also ensured that our dependencies would not drift apart in the future, allowing us to more easily introduce new technologies and patterns in both apps simultaneously.
A Successful Release
After overcoming these and many other hurdles over an eight-month development cycle, we were able to successfully retire the standalone Hivy product and release our fully-integrated Task Management feature to the world in April of 2019. We’ve turned our attention to deepening our backend integration and building new features that leverage the combined power of these two products.
