Overcoming Challenges through Modern Technologies

In this series, we will discuss some technical challenges we have faced and how we utilized different modern technologies to overcome them. We aim to explain how these technologies solved our particular problems, and we will cover other beneficial features these pieces of tech contain.

Backstory:

In 2021, we were tasked with renovating the user interface (UI) of our web applications for our product VoterVoice. This was no small feat as we have numerous applications across several different technologies. Our design team had already laid the groundwork for the designs, icons, states, color palettes, and such and it was getting close to the time for us to start development. As developers, we had decisions to make.

Throughout the entire planning process we faced two major challenges:

First — and what we will focus on today — we needed the ability to simultaneously support the new and existing UI, and be able to switch back and forth at runtime.

Our next challenge involved the navigation menu included in the redesign. It was currently replicated and reused across multiple applications for a seamless transition between applications but was a maintenance headache. Any time a change needed to be made to the navigation menu the developer had to remember to make the change in all locations where this navigation menu was coded. Relying on memory or awareness isn’t exactly setting up the best future for the codebase. In a forthcoming segment of this series, we will relay how we faced this obstacle.

Challenge: Feature flagging. Enter, LaunchDarkly.

“Simultaneously support the existing UI as well as the new UI and be able to switch back and forth at runtime.”

Our first hurdle directly dealt with runtime feature toggling. I’ll admit I was excited to custom design and build a feature flagging system into our codebase. It is a very useful feature to use across any and every application. However, one of our dev team discussions involved using LaunchDarkly instead of rolling our own. After some discussion and weighing the pros and cons we decided to run with LaunchDarkly (see quick comparison below).

Building our own feature flagging system could have turned into a yak-shaving project of its own. Remember the focused task at hand is “Redesign the application and support the existing UI as well.” LaunchDarkly is extremely robust and delivers all anyone would need when it comes to feature flagging throughout environments, release rates, and specific targeting of users or groups. I think most importantly, LaunchDarkly would give us access to feature flagging quickly.

We used LaunchDarkly to run some user trials with the new UI while still serving the existing UI. LaunchDarkly was a success, but after receiving feedback and running some successful user trials we had one more small challenge arise that would also easily be solved by LaunchDarkly. We wanted to make sure the transition to the new UI was easy on our support staff. Switching all users at once to a new UI could be jarring and could result in a flood of needed support. In order to mitigate all clients calling simultaneously we leveraged LaunchDarkly’s Percentage Rollout feature. We were able to roll out our new UI to percentages of users at a time over the span of several days to a week. This made our release(s) smoother than any large-impact release I’ve ever worked on.

LaunchDarkly has all sorts of features. Here are just a few:

• Hierarchical flags by project and environment
• Server-side api and client-side api support for pretty much any language you could need.
• Global rules and specific targeting rules
• Insights into flag usages
• Integrations with all sorts of communication and/or management apps.
• Any employee with an account can use it. This enables non-engineers to manage feature flags

We were off the ground with LaunchDarkly within a day or two and it has been used on many projects since. Challenge one…solved!

Further on the topic, by having a feature flagging system in general we have been able to include new large features in deployments well before being released. This has helped us reduce the amount of large code silo merging. Merge often and keep the feature behind a flag.

Conclusion:

As problem solvers, we face issues that sometimes require fast fixes. As fun as it would be to architect and build the perfect resolution ourselves, it may be substantially better to find and utilize a technology that already solves that problem. If you seek to reap the benefits of including feature flagging in your applications, LaunchDarkly is a strong candidate for consideration.

The next segment of this ongoing series will highlight Web Components and Tailwind CSS — stay tuned!