Replacing a Frontend While It Stays in Production

The situation

An internal storefront for employees ran on AngularJS 1.7, a framework without vendor support. A rebuild in one piece was out of the question: the application was in daily use and was to receive new features in parallel. Behind it sat a GraphQL API and several REST services grown over the years for products, cart, promotional codes and loyalty points, each with its own authentication method.

The solution

The replacement ran over two years and reversed direction halfway through. First React 18 was embedded into AngularJS and feature after feature was taken over, while new features kept being built in the legacy system. Once the React share prevailed, we inverted the relationship: from that point on AngularJS ran embedded in React.

The two constants across the whole period were the event bridge between the two frameworks and the interfaces. The bridge grew with every feature taken over, because each new interaction between the old world and the new one needed a path along which state and events travel reliably in both directions. On the interface side it was about authenticating against several methods, about normalising very different response shapes onto a common model, and about error handling per source. Before, a single failed service took the entire interface down with it, white screen. Afterwards the application stays operable and tells the person which area is currently unavailable and which function is missing as a result.

Routing was a chapter of its own, because both frameworks reacted to the same navigation event and calls were therefore triggered twice or three times, with correspondingly many superfluous requests. That could be solved cleanly once and pulled into a module of its own, which was then used everywhere.

The result

The switch ran without a cutover date and without a feature freeze, and the application was in productive use throughout the entire rebuild.