• Home
  • >
  • DevOps News
  • >
  • Building a Standard Interface for Feature Flags with Node.js – InApps Technology 2022

Building a Standard Interface for Feature Flags with Node.js – InApps Technology is an article under the topic Devops Many of you are most interested in today !! Today, let’s InApps.net learn Building a Standard Interface for Feature Flags with Node.js – InApps Technology in today’s post !

Read more about Building a Standard Interface for Feature Flags with Node.js – InApps Technology at Wikipedia



You can find content about Building a Standard Interface for Feature Flags with Node.js – InApps Technology from the Wikipedia website

Vince Gandolfo

Vince is a software engineer at LogDNA, where he works primarily on LogDNA’s backend services using Node.js, Elasticsearch, Kubernetes and more. He has worked on a number of LogDNA’s features including Archiving, Usage Quotas, and the Template Library.

Feature flags are an essential part of many modern development processes. They help us decouple deployment from release and gain more control over user access, and they also allow us to toggle features on and off. However, just enabling feature flags is not enough. To have more predictable releases, it’s essential to create a standard process for how flags are used.

At LogDNA, feature flags were part of our software development life cycle (SDLC), but weren’t organized in a standard way, which led to confusion across the organization. For example, in our web application, there are multiple sources where feature flags originate. From there, they were combined into a single location in an unpredictable fashion. This made it hard to know what took precedence and what overrides existed.

On the backend, feature flags were tacked onto account records from the database or even stored in environment variables. Storing flags in the database introduces complexity and risk — the exact thing you’re trying to avoidwhen flags need updating because you must manually modify a production database or use a tool to make updates in bulk. Additionally, flags that are left lying around after they’re no longer needed can cause confusion.

Read More:   How to Manage SaaS Apps Like You Own Them – InApps Technology 2022

Adopting LaunchDarkly

To solve these pain points, we adopted LaunchDarkly. Now, we have a central home where all feature flags live and a standard process for rolling out new features. Not only can we pick out specific accounts to toggle a feature for, we can also target accounts based on specific properties.

For example, we support customers across a dozen IBM environments as well as our direct customers who are hosted on LogDNA infrastructure. There are cases where we want to toggle a feature only for IBM accounts or only for LogDNA accounts. LaunchDarkly even offers percentage rollouts, where only a certain percent of accounts see a new feature. This facilitates A/B testing and can help with reducing impact if there’s an issue with a new feature. With LaunchDarkly, features can be disabled for accounts without requiring a rollback, which can be helpful during incidents. Alternatively, if a feature rolls out smoothly to a percentage of accounts, we can easily bump it up so that all accounts see the feature.

Adopting LaunchDarkly has helped us move faster, experiment more and mitigate risk. However, we wanted to push its capabilities even further by creating a standardized interface for interacting with the service.

The Node.js Client

Since our codebase is written in Node.js, we decided to build a wrapper around LaunchDarkly’s node-server-sdk. We wanted it to be able to read flags from LaunchDarkly, enforce some validation and format the user data before it’s sent to LaunchDarkly to request a feature flag.

The initial implementation of the client worked well, but we ended up running into some issues with it. During testing, we found that we needed to add a lot of code to capture the requests LaunchDarkly’s sdk client makes and to mock the results it receives. This was just too much effort and required vendor-specific logic just to get testing to work. Also, this would need to be duplicated in every project we wanted to add our client to. We had to go back to the drawing board and design the client in a way to make testing simple.

Read More:   Let’s Put an End to Salesforce Change Paralysis – InApps Technology 2022

In the new version of the client, we wanted to abstract away the vendor-specific logic and remove the need to monkey-patch the client’s functionality. The client now has a couple of new storage backend options, which determine from where to read feature flags. The “memory” backend maintains a local store, just a plain old javascript object, to add and read flags from, while the “dummy” backend simply returns whatever default flag value you pass to it. Both of these new backend options are great for testing and make it a lot easier to add the client to any of our repositories. Lastly, the “launchdarkly” backend reads flags directly from LaunchDarkly, just like the previous version, and is meant mostly for use in production.

The feature flags client can now be dropped in anywhere in our codebase. It requires only a small amount of code to be added, and testing with it is relatively simple.

Conclusion

For the LogDNA engineering team, adopting LaunchDarkly was the first step in rolling out a robust feature flagging process. Standardizing our interface with the service with a custom-built Node.js client has taken this process to the next level, and now we’re deploying with more confidence than ever before.

InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: LaunchDarkly.

Photo by Shashank Kumawat from Pexels.



Source: InApps.net

Rate this post
As a Senior Tech Enthusiast, I bring a decade of experience to the realm of tech writing, blending deep industry knowledge with a passion for storytelling. With expertise in software development to emerging tech trends like AI and IoT—my articles not only inform but also inspire. My journey in tech writing has been marked by a commitment to accuracy, clarity, and engaging storytelling, making me a trusted voice in the tech community.

Let’s create the next big thing together!

Coming together is a beginning. Keeping together is progress. Working together is success.

Let’s talk

Get a custom Proposal

Please fill in your information and your need to get a suitable solution.

    You need to enter your email to download

      Success. Downloading...