Using the Strangler Fig with Mobile Apps

The Problem with Mobile Legacy Modernization

As applications age and grow, they tend to deteriorate both in quality and performance. Features take longer to get to market while outages and rolled back releases become more severe and frequent. There is a nuanced complexity to be understood about the reasons why this occurs both at the code and organizational level. To summarize though, at some point, an organization will grow tired of the poor outcomes from their software and start the process of legacy replacement. The decision to replace may be made based on multiple factors, including (but not limited to) cost/benefit analysis, risk analysis, or opportunity cost. Eventually a legacy modernization strategy will be chosen. This will be dependent on the organization’s attitude to risk. For example, a complex, high availability system may demand a more incremental or interstitial approach to legacy replacement/displacement than a simpler, less business critical one.

In the case of mobile application modernization, those decisions have in recent memory been reasonably clear cut. A mobile application was often designed to do an individual thing- Apple’s “There’s an app for that” still rings out loud and clear in people’s minds 15 years after the initial batch of advertisements. That message was one that was taken to heart by organizations and startups alike: If you need to do something, write an app to do it. If you need to do something else, write another app to do that. This example struck me when I was pruning the apps on my phone a couple of years ago. At the time I noticed I had several apps from the manufacturer of my car; an older one and a newer one. I also had two apps from my bank; one showed my checking account, another that analyzed and illustrated my spending habits. I had three apps from Samsung for various IoT devices, and at least two from Philips that controlled my toothbrush and light bulbs. The point I’m laboring here is that a mobile application was never allowed to get so complicated, that it couldn’t be torn down, split out or started from scratch again.

But what happens when this isn’t the case? Surely not all apps are created equal? Many believe that the mobile experience of the future will be centered around so-called “super-apps”; apps where you can pay, socialize, shop, call, message, and game, all under one application. To some degree this has already happened in China with “do-everything” applications like ‘WeChat’ and ‘AliPay’- we see the mobile device and its operating system as more of a vehicle to allow the running of these gigantic pieces of software. Comments from industry indicate a realization that the West is not quite as far along as China in this regard. But while not at the super-app, there is no doubt that complexity of the mobile app experience as a whole has increased significantly in recent years. Take the example of YouTube, when first installed, back in the early 2010’s, the application could play videos and not much else. Opening the application today one is presented with “Videos” and “Shorts”, a news feed, controllable categories, subscriptions, not to mention a content editing and publishing studio. Similarly with the Uber app, the user is asked if they want to order food. Google Maps can show a 3D view of a street and Amazon now recommends scrollable product-recommendation mood boards. These extra features have certainly enriched a user’s experience but they also make the traditional build, use, rebuild technique much more difficult.

This difficulty can be explained by considering some of the existing common problems of mobile application development:

• Massive View Controllers/Activities/Fragments
• Direct manipulation of UI elements
• Platform specific code
• Poor Separation of Concerns
• Limited Testability

With discipline, these problems can be managed early on. However, with a large application that has grown chaotically inline with the business it supports, incremental change will be difficult regardless. The solution then, as before, is to build new and release all at once. But what if you only want to add a new feature, or modernize an existing domain? What if you want to test your new feature with a small group of users ahead of time while serving everyone else the old experience? What if you’re happy with your app store reviews and don’t want to risk impacting them?

Taking an incremental approach to app replacement then is the key to avoiding the pitfalls associated with ‘big bang releases’. The Strangler Fig pattern is often used to rebuild a legacy application in place: a new system is gradually created around the edges of an old one through frequent releases. This pattern is well known, but not widely used in a mobile context. We believe the reason for this is that there are several prerequisites that need to be in place before diving headfirst into the pattern.

In their article on Patterns of Legacy Displacement, the authors describe four broad categories (prerequisites) used to help break a legacy problem into smaller, deliverable parts:

1. Understand the outcomes you want to achieve
2. Decide how to break the problem up into smaller parts
3. Successfully deliver the parts
4. Change the organization to allow this to happen on an ongoing basis

Only in the third point, can we envisage the invocation of the Strangler Fig pattern. Doing so without an understanding of why, what or how it might continue in the future is a recipe for failure.

Going forward, the article charts how Thoughtworks was able to help one of its enterprise clients expand its existing mobile legacy modernization efforts into a successful experiment that demonstrated the value behind the use of the Strangler Fig pattern in a mobile context.

Satisfying the Prerequisites

At this point, it seems appropriate to introduce the client that inspired the writing of this article – a globally distributed business with an established retail organization that had embraced mobile applications for many years. Our client had realized the benefits an app brought to provide a self-service experience for their products. They had quickly expanded and developed their app domains to allow millions of customers to take full advantage of all the products they sold.

The organization had already spent a significant amount of time and effort modernizing its mobile applications in its smaller sub-brands. Responding to a lack of reuse/significant duplication of efforts, high cognitive load in app teams and slow feature delivery, the organization chose a mobile technology stack that leveraged a Modular Micro-app architecture. This strategy had been largely successful for them, enabling proliferation of features common to the organization (e.g. ‘login/registration/auth’ or ‘grocery shopping’) across different brands and territories, in a fraction of the time it would have taken to write them all individually.

The diagram above is a simplified representation of the modular architecture the organization had successfully implemented. React Native was used due to its ability to entirely encapsulate a domain’s bounded context within an importable component. Each component was underpinned by its own backend for frontend (BFF) that came with the infrastructure as code to instantiate and run it. The host apps, shown above as UK and US, were simply containers that provided the app specific configuration and theming to the individual micro-apps. This ‘full slice’ of functionality has the advantages of both allowing re-use and reducing complexity by abstracting application domains to micro-apps managed by individual teams. We speak in depth about the results of this architecture in the already referenced article on ‘Linking Modular Architecture’.

As touched upon earlier, the organization’s mobile estate was made up of a number of smaller sub-brands that served similar products in other territories. With the modular architecture pattern tried and tested, the organization wanted to focus efforts on its 'home-territory' mobile application (serving its main brand). Their main mobile app was much larger in terms of feature richness, revenue and user volumes to that of the sub brands. The app had been gaining features and users over many years of product development. This steady but significant growth had brought success in terms of how well-regarded their software was on both Google and Apple stores. However, it also started to show the characteristic signs of deterioration. Change frequency in the application had moved from days to months, resulting in a large product backlog and frustrated stakeholders who wanted an application that could evolve as fast as their products did. Their long release cycle was related to risk aversion: Any outage in the application was a serious loss of revenue to the organization and also caused their customers distress due to the essential nature of the products they sold. Changes were always tested exhaustively before being put live.

The organization first considered a rewrite of the entire application and were shocked by the cost and duration of such a project. The potential negative reception of a ‘big bang’ new release to their app store customers also caused concerns in the levels of risk they could accept. Suggestions of alpha and beta user groups were considered unacceptable given the huge volumes of users the organization was serving. In this instance, a modernization effort similar to that seen in their sub-brands was believed to be of considerably higher cost and risk.

Thoughtworks suggested an initial proof of concept that built on the successes of the reusability already seen with a modular architecture. We addressed the organization’s big bang risk aversion by suggesting the Strangler Fig pattern to incrementally replace individual domains. By leveraging both techniques together we were able to give the organization the ability to reuse production-ready domains from their modernized mobile apps inside their legacy app experience. The idea was to deliver value into the hands of customers much sooner with less duplication than in a full rewrite. Our focus was not on delivering the most beautiful or cohesive full app experience (-not quite yet anyway). It was about obtaining confidence both in the stability of the iterative replacement pattern and also in how well the new product was being received. These pieces of information allowed the organization to make more informed product decisions early on in the modernization process. This ensured the finished product had been extensively used and molded by the actual end users.

Strangler Fig and Micro-apps

So how far did we get with the proof of concept and more importantly how did we actually do this? Taking the learnings from Modular Micro-app architecture (described above), we theorized the design to be as follows:

The initial state of the application involved the identification of domains and their navigation routes (Decide how to break the problem into smaller parts). We focused our efforts on finding navigation entry points to domains, we called them our ‘points of interception’. Those familiar with mobile application development will know that navigation is generally a well encapsulated concern, meaning that we could be confident that we could always direct our users to the experience of our choosing.

Once we identified our ‘points of interception’, we selected a domain for incremental replacement/retirement. In the example above we focus on the Grocery domain within the existing application. The ‘new‘ Grocery domain, was a micro-app that was already being used within the sub-brand apps. The key to implementation of the Strangler Fig pattern involved embedding an entire React Native application inside the existing legacy application. The team took the opportunity to follow the good modularity practices that the framework encourages and built Grocery as an encapsulated component. This meant that as we added more domains to our Strangler Fig Embedded Application, we could control their enablement on an individual level.

As per the diagram, in the legacy app, Grocery functionality was underpinned by a monolithic backend. When we imported the New Grocery Micro-app, it was configured to use that same monolithic backend. As mentioned previously, each micro-app came with its own Backend for Frontend (BFF). In this instance, the BFF was used as an anti-corruption layer; creating an isolating layer to maintain the same domain model as the frontend. The BFF talked to the existing monolith through the same interfaces the legacy mobile application did. Translation between both monolith and micro-app happened in both directions as necessary. This allowed the new module’s frontend not to be constrained by the legacy API as it developed.

We continued the inside out replacement of the old application by repeating the process again on the next prioritized domain. Although out of scope for this proof of concept, the intention was that the process shown be repeated until the native application is eventually just a shell containing the new React Native application. This then would allow the removal of the old native application entirely, leaving the new one in its place. The new application is already tested with the existing customer base, the business has confidence in its resilience under load, developers find it easier to develop features and most importantly, unacceptable risks associated with a typical big bang release were negated.

Diving Deeper…

So far we’ve presented a very broad set of diagrams to illustrate our Mobile Strangler Fig concept. However, there are still many outstanding implementation-focused questions in order to take theory into practice.

Implanting the Strangler Fig

A good start might be, how did we abstract the complexity of building both native and non-native codebases?

Starting with the repository structure, we turned our original native application structure inside out. By inverting the control of the native application to a React Native (RN) application we avoided significant duplication associated with nesting our RN directory twice inside each mobile operating system’s folder. In fact, the react-native init default template gave a structure to embed our iOS and Android subfolders.

From a developer perspective, the code was largely unchanged. The legacy application’s two operating-system-separated teams were able to target their original directories, only this time it was within a single repository. The diagram below is a generalized representation (that is, applicable to both iOS and Android) of the current pipeline from the Client as we understood:

Bi-Directional Communication using the Native Bridge

We’ve already touched on navigation with our previously mentioned ‘points of interception’. It is worth looking deeper into how we facilitated communication and the transfer of control between native and React Native as it would be easy to oversimplify this area.

The React Native ‘Bridge’ enables communication between both worlds. Its purpose is to serve as the message queue for instructions like rendering views, calling native functions, event handlers, passing values etc. Examples of properties passed across the bridge would be isCartOpen or sessionDuration. While an example of a bridge function call might be js invocations of the device’s native geolocation module.

The diagram above also references the concept of a ‘React Native Micro App’. We introduced this concept earlier in the article when we described our app in terms of journeys. To recap though, a micro-app is a self-contained encapsulation of UI and functionality related to a single domain. A React Native app may be made up of many micro-apps similar to the micro frontend pattern. In addition to those advantages we have already discussed, it also allows us to have a greater degree of control over how our Strangler Fig application grows and is interacted with. For example, in a situation where we have more confidence in one of our new journeys than another we are afforded the option to divert a larger proportion of traffic to one micro-app without impacting another.

Bringing both concepts together, we utilized the bridge to seamlessly move our users back and forth across experiences. The ability to pass information allowed us to preserve any immediate state or action from the UI that needed to persevere across experiences. This was particularly useful in our case as it helped us to decouple domains at appropriate fracture points without worrying whether we would lose any local state when we crossed the bridge.

Handling Sensitive Data

So far we’ve discussed moving between legacy and new codebases as atomic entities. We’ve touched on how local state can be shared across the bridge, but what about more sensitive data? Having recently replaced their login and registration (auth) process in their other customer-facing React Native apps with a modular, configurable, brand agnostic one, the client was keen for us to reuse that experience. We set ourselves the task of integrating this experience as an initial demonstration of the Strangler Fig pattern in action.

We leveraged the techniques already discussed to implant the Strangler Fig: i.e. the new authentication journey on the React Native side. When a customer successfully logged in or registered, we needed to ensure that if they moved away from the new experience (back into the legacy journey), their authentication status was preserved no matter where they were.

For this, we utilized the native module code calling side of the bridge. The diagram above explains how we achieved this by using a React Native library that served as a wrapper to save authentication data to the Android EncryptedSharedPreferences or iOS Keychain after a successful login. Due to the flexible structure of the data inside the keystore, it allowed us to seamlessly share the (re)authentication process irrespective of whether the user was in the native or non-native experience. It also gave us a pattern for the secure sharing of any sensitive data between experiences.