Feature Flagging With React

Hi, everyone. My name is Fahad Hilal. I work as a Principal Engineer in DAZN company. We are all about sports streaming and many other things related to sports. And today, I'm here at React Advanced. Thank you for letting me come here and give you a talk about feature management in React.js applications.

So initially, when I submitted my talk, I had the idea that I'll just come in and talk about a new open source project of mine and just like advertise it, let everyone know about it, but I realized that's going to be a big, big failure if I really do it that way, because then nobody will understand why I even built that tool and what are the pain points and suffering that led me to even think of building such a tool. So then I backtracked a bit and then I made this my agenda. So I want to focus more on the conceptual side of things, starting with feature management, like what it is, what kind of practice it is, the techniques involved in it, and how we can adopt it, what are the benefits, and also what are the pain points that come with it.

And very quickly, after that, I also want to touch upon two topics called infrastructure as code and also GitOps. So I really want to insist that I understand this is a conference that is focused more on the React side of things in the front-end area. Even if you do not know these terms, I have a very strong feeling that you actually know it without knowing these terms. So I'll clear that up very, very soon. And then, once we have covered the conceptual side of things, I'll show you how I combined these three different practices, three different concepts together to create this solution that I call Feature Advisor. And then I also want to, again, mention that the tool is the negligible part of this talk really. A tool could be anything, like it could be a third-party SaaS tool or this tool that is open source or something that is bespoke and built by yourself, it really doesn't matter. So it's really the concepts, the practice in software engineering. And then of course, because it's a React advanced conference, so I also want to show you how you can bring this practice in your React application and also benefit from that. So I promise that I'll show you some code, but at the very, very end.

So first things first, what is feature management? What is it like? How does it differ from some other source of management, like content management or things like that? So if I were in the same room with all of you, I think I would have asked you all to raise your hands asking, have you ever used feature flags before in your organization, in your source code, in your team? Have you ever done that? But since we are remote right now, so I will just go ahead with my slide. So I'll start by saying that feature management in the end is a practice. A practice that is consisting of several different techniques that we apply in software engineering. So the first one that comes to my mind is called feature flags or feature toggles that you might already have used before. So if you have not, then I want to mention that it's really an if condition, an if statement. It's an on off switch that you check in your code somewhere with an if statement somewhere. It could be JavaScript, it could be Golang, really language doesn't matter here. And if something is true, you do something. If not, then you do something else. As simple as that. But the idea is that conditions that evaluate those values as true or false is something that is externally managed and something that is not hard-coded in your application.

Because the idea is we want to decouple your application deployment from your feature releases. I'll talk more about it soon in the next slide, but for now, let's just assume that it's an on-off switch that just controls the behavior of your application in certain areas.

And then also, if you are into more product development, you might have also heard about A-B testing or multivariate testing. So, what happens is, imagine you have a new sign-up journey designed and you want to test different variations, like variation A, variation B, variation C. So, you want to test it against all your traffic. So, maybe 33% of the traffic gets variation A, other 33% gets B, and the others C. And then you figure out which one converts best. Is it the B variation that gives you the most successful sign-ups and on? So, this is one of the techniques as well that you externally manage while influencing your application without requiring any further deployment.

And one other thing that's very, very crucial that I found in my carrier is the concept of gradual rollouts. So, imagine you and your team have been building a new product feature that you're launching, let's say, next month. You don't really want to go for a big bang release. You don't want to release it to the entire world or to 100% of your traffic. You want to be confident that, hey, we built this thing for such a long time without exposing it to users. Maybe you should figure out if it actually works with real users at all before we expose it to everyone. So, what you can do is launch it only to 5% of your traffic. Then 10%, gain some confidence, see that everything works well with your back-end system, with your front-end code and everything. And then you gradually move the percentage level all the way up to 100%. And you know that, okay, now it's completely out. Nothing is held back for anyone anymore. And so that's gradual rollout.

The other one is remote configuration. Imagine you have some very specific product behavior that you can parametrize, and you do not want to hard-code that configuration in your application itself. So you manage that configuration externally, and you can tweak the configuration whenever you feel like it, and it influences the behavior of your application right away, without requiring any further deployment. How amazing is that? Imagine this new redesign that had some toggle, like on or off. You could just toggle it off whenever you feel like, because you think that this is causing some harm to your production environment. And then comes audience targeting. So I'll pick one example from Facebook, actually. They call themselves Meta now. So New Zealand was always their playground, their testing ground. So they used to always launch these new features and they would expose it to users in New Zealand only, for some reason, don't ask me why.

And then they'll figure out if it's working or not. Even in Netherlands, there are big companies sometimes launching some new products in Netherlands first, before they roll out to the rest of the world. So they target their audience. So this is audience targeting. You figure out in the runtime if the country is equal to Netherlands or country is equal to New Zealand, I want to expose this feature for the rest of the audience. I do not want to show anything yet until I'm ready. So that's audience targeting.

So I'm talking a lot. And so this is actually just the techniques that I mentioned. But why even adopt them? What is the need for even knowing these techniques and why incorporate them? How does it make your life better? So now we move on to the next slide. So this is only the few handful of items that I have come up with for this talk. So the first one is decoupling releases from deployments. So now this may sound a bit confusing, like what is a release and what is a deployment? So deployment is when you ship your code. So imagine you built a React application and you have bundled it. It's already sitting in a dist folder somewhere, and you upload it to a CDN or your server. So that's the deployment part. The code is being shipped, but code being shipped doesn't necessarily mean that it's actually already being exposed to users. Maybe there are some certain features that are not in enable state, like behind a feature flag. So that's the decoupling part. So you keep them separate, the feature configuration and the feature code itself. That's a shipping part.

And so it also, like if you adopt this way of working, like when they are decoupled, it also helps your team and your organization to adopt this mindset of continuous delivery. And what do I mean by that? So there are different approaches of managing code in a Git repository or any other versioning system. It doesn't matter. It's called often trunk-based development. So you keep on merging new features that you develop, and you just keep merging it to your main branch or master branch, whatever you want to call it, and you just ship the code. But they are not actually exposed to your users yet until you feel ready. And this helps like avoid having to maintain a long running feature branch for a long period of time. It introduces so many conflicts, if there's so much sync issues, you can really abort all that. So misdelivery really, really helps you there.

Other thing is increased control and flexibility. So by control, I mean it can control who sees what, where and when. I mentioned the country's like based configuration before. So it could be like anything, it could be also like saying, Okay, I only want to launch my feature to people aged above 25 or below 50, like whatever, you could come up with these conditions yourself. As long as the evaluation is being done by the code, the configuration could be coming from somewhere else, totally separate from your application, giving you that flexibility.

Risk mitigation, one more thing. So I mentioned it briefly before. So if you have some feature that is like a launched, but you realize that okay, it's like a causing some bad to happen in your, like organization or your system. So you can quickly roll back, you can just disable it very, very quickly without having to coordinate, I don't know, deployments across maybe 20 or 30 different teams, depending on your organization size. So it always like centralized in one place is much more easier and with centralization of all these like feature flag management, like configuration and their product specific behavior. It also gives you a very solid visibility in your entire organization. So product, marketing team, engineering, of course they can all come together and get behind a single source of truth. And they can collaborate in one place without leading to any confusion or any like, pain and suffering that can come from it if people are not aligned. So these are like all good things. I mean, I think we can agree that we at least I get some benefits like by just going to this list here.

But in real world things are not just rainbows and butterflies all the time, you know, like there are many, many operational pain points that come with it. So I'll briefly mentioned those two. And I can really tell you that every single item here has caused me great pain in my career. listed them down here in this list. So the first one is, having a reviews and approval workflow. So what happens with most of the tools is like there's many third parties like SaaS tools there for like feature management needs. And the ones that I reviewed myself, I would say more than 80% do not have this reviews and approval workflow. So most of us in this audience right now, I'm assuming that we are mostly engineers. So we know how to work with Git and GitHub. And we know how to send full requests. So we have a very review and approval based culture, you know, so we like to like make it peer reviewed before something goes live. So this is something that doesn't always exist in feature management tools that I really, really dislike. And it has caused so many issues before, like in my jobs, like multiple different jobs. And this is something that I really miss. Another thing is that most of these tools allow you to create a single project and it makes sense that you want to have your entire, like feature management managed centrally as in a single project.

So everyone can see everything. But the problem is the serving of this configuration. So imagine you have a front-end application, there is landing page, there is a sign in page, sign up page, there's a checkout flow, all that. They're separate areas of your, like, you know, like organization, each team doing their own thing. Even though like from end user perspective, you are seeing them all together. But when you fetch the configuration, you might be loading, let's say, configuration of checkout area, when you're just trying to render a landing page. That's not really cool. Like with web, like performance is like a very important, like we only want to like load as less as possible to deliver the maximum value to our customers so that we can give them a good experience, make the page load really, really fast and all that.

So this thing really, really hurts this configuration size that we all need to fetch for our like feature flags. Deprecating is one other problem. So with these tools, you see that people just keep on adding and adding more feature flags and more feature configuration like to the tool, and they never delete them. And because everyone is afraid to delete anything, what if like I delete something and it like break something in Australia or break something in the United States, because we don't know. So if we have a deprecation workflow saying that, okay, if someone is evaluating this feature, show them a warning so the engineers can like take care of it themselves for removing it. So this is also a missing problem, missing like a use case that I see in many tools.

Feature dependencies, when you have like one feature depending on another one, that's also like a concept that doesn't exist in many tools. Another one is establishing ownership of all the features. So if I create a new feature flag, do I get to assign myself as an owner or a team as an owner? So as owner, so that the next time you want to change something so that he can know like who this person is or who the team is that I need to communicate to. Testing and production, another one. So if you have a QA team in your company, you must like consider yourself very, very lucky because not many teams and companies have that. So everyone has to test everything themselves before they shift to production. So many of the tools are not really designed around the QA workflow, the quality assurance team. So you want to maybe expose a feature flag as enabled only for your QA team only so they can actually test in real production before exposing to the rest of the users. So this is another operational pain point that I have. So I've been mentioning a few of these, every single item that I face myself, I'm sure like many of you have faced yourself as well. And trust me on this when I say it, coding challenges, technical issues are something that we, most of us can handle. But operational pain points, like when you have to be in a room full of like 15, 20 people, everyone like stressed out trying to figure out what went wrong, where and you don't know it, you really want to avoid that kind of situation. You don't really, really want to be there. And this is a gif that I just like added in the slide. So a great man once said, like in this kind of situations where external environment is trying to put too much pressure on you or like you are getting too much like inputs, be like water. Like it was a Bruce Lee, a very disciplined man.

But thing is in reality, I mostly act like this. So I mean, as much as you want to like, you know, be very composed, very calm, when stress level is high, and there are many people from different departments coming together, like sometimes a different version of you can come out. And all of that, that I learned actually, through this journey, I tried to pour into this new tool that I built that I want to show you soon.

But before I go there, I just want to mention two new topics very, very quickly. So first one is infrastructure as code. So this is a sentence I copied from Google with some edits. So infrastructure as code is a practice in software engineering where infrastructure is provisioned and managed using declarative code. And by declarative code, I mean code but code that tells the system what like what to do, but not necessarily how to do it. Because we have what all the manual process is like we are telling almost a person like do this thing and the person figures out how to do it and then it gets the job done. And if I give you some quick examples, there's Terraform, there's Docker, there's Kubernetes and all that. So they're all like adopting this ICC principles, ICC short for infrastructure as code. But I really want to focus on the last part only because I think that's where we have the common ground in front end and back end. Many of us have already dealt with CI, CD pipelines, GitHub actions is a popular one. They are also like free for open source projects and all there's GitLab CI and there are more. So what happens is we define what we expect from our CI, CD pipeline in workflows. We define a YAML file with a job, with the steps, and then we just like hand it over to GitHub and GitHub source everything out for us. It runs the job, it gives us a green or red status based on if the build passed or build failed. So all of that is taken care of by them. So we don't really like to figure out all the little hows to make that work. So that's really IAC.

The next one that I want to quickly touch upon is called GitOps. So we know about DevOps and other sorts of operational works, but GitOps is a new term that's also gaining a lot of popularity and it builds on top of the principles of IAC, but we manage everything in a git repository. So everything is like declared in a declarative syntax like YAML file or JSON file or TOML. It could be any language of your choosing, as long as it is declarative, like without any programming code. We use everything in Git. So everything is, this is a source of truth. We have reviews and approval workflow out of the box because everything goes via pull requests and we have automation via CI-CD pipeline because everything's like backed by it. And of course it's Git, so we have audits like out of the box because it maintains all the changes that we have and it has a full history. So no, everyone will know like who did what when, so you have like more like transparency in your organization right away. So we learned like a few different concepts.

Now we learned about infrastructure as code. We learned about feature management. We also touched upon GitOps. So I really was like struggling with this concept for the last two or more years and wanted to figure out like, is there any way to bring these three parties together and build a solution that can make engineers lives happier? So that's why I, and this year I finally cracked that API in my head and I really went for it. And so I'm calling that tool Feature Advisor. It's free and open source. It works with JavaScript, it works with React, with SDKs and all. And again, I want to say that the tool is not really the important part here. I'll show you some of this tool's functionality. You can really use any other tool, but it's the principles that really matter the most.

And this is where my slides actually end. I will go to the website quickly to show you how that tool works and how you can even take this learning to any other tool of your choosing. Maybe you can build something yourself and benefit from that. This is the homepage. So I'll ignore the landing page details for now and I will take you straight to the bottom of this page and I will show you the way of working with this tool.

How does GitOps apply to feature management? So you have a Git repository. This is your feature advisor project. This project, this repository is independent of your application code. So that's how we make releases decoupled from deployments. And you send pull requests for updating all your feature configuration as their individual YAML files. And once the pull request is reviewed and merged, a CI-CD pipeline takes in that you own yourself. I have templates for GitHub Actions so you can copy that if you want. And it will build the configuration files that is consumable, and then it will upload to a CDN of your choosing. It will be your own server.

And the third step is basically, once those configuration files that is built and uploaded to a CDN, you can fetch it in the runtime on your application. And by runtime, I mean if you are a React application developer, it could be the browser environment. You fetch that configuration from the browser directly and use Feature Advisor SDKs to evaluate those values as true, false, or some other variable value. And there are three building blocks to defining the features. So I will quickly go through them. Attributes are like fields. For example, if you want to have a condition set against countries, like if country is equal to New Zealand, or country is equal to Netherlands, so define a country attribute. That's your field that you will have a condition against. So here I'm creating an attribute slash country dot yaml file. I'm saying it is of type string, and I have some description just for documentation purposes for us humans. And then comes the segments part. Segments is like how you define like, what are our targeting conditions? So if we want to let's say target iPhone users in the United States, this is like one way that we could define it. So you'll have an iPhone US dot yaml file. And in our conditions, we'll say that, okay, the country attribute must equal to the value of US. That is the country code of US, United States, and the device should equal iPhone. So all of a sudden, we just have like a segment, reusable segment that we have defined that we can use when we define our feature allow rules.

Segments have like an exhaustive list of operators that you can use, like beyond just equals operator. So I do not really have the time to go through all of them, but you can come back to it later. Like when you visit the website.

Then comes the features part. This is like the most interesting part. This is where you define your individual feature flags. The idea of defining a feature is you either want to evaluate one of three different values. The flag value itself that is like an on and off status. There's variation. You can use AB test. If you're using variables for like remote configurations, you can also use some key value pairs as configuration here. So here this is a very, very simplest form of feature definition in Feature Advisor. So you create a new sidebar.yaml file because that's what you want to call your feature flag. So you have a sidebar and then you define some rollout rules in a different environment. So here I only have production environment, but imagine I could also have like staging environment or development environment or anything else, you know, it's totally up to me to customize it. And then I have the rules. I'm saying that, okay, I want to launch it to everyone. So asterisk means that all segments, full audience and percentage is like if I wish to rollout gradually. So it could be any value between zero and hundred. And we previously created a segment called iPhone US. So imagine we wanted to launch this sidebar feature to only iPhone US users only. So we could have done something like this in the segments instead of asterisk. We could just say like, okay, instead of Germany, I could just call like a United States or iPhone US users, anything, you know, we are totally free to compose our own targeting conditions the way we want customizing against our own needs. So this is the definition part.

So I will not touch upon the topics of the CICT part. Like it's just like one command that builds everything. You can use that from the website. But I'll quickly touch upon the SDK itself. So the JavaScript SDK, so I'm going to come to React like right after this. So the JavaScript SDK is like universal.

It works in Node.js and also in browser environments. There are like more SDK's in other languages and development already, but JavaScript is like the one that's already done. And you just initialize it by providing a data file URL. So imagine you downloaded, uploaded your like configuration file to your own CDN, you just provide that URL. And you just initialize that using the create instance function of it. That's it. And once you have it, you can like evaluate your feature flags by calling, if the feature of other instance has this feature key as enabled or not, you get the value and do whatever you want with it. Like you can do if it's enabled, show this sidebar, if not enabled, do not show it. It could be anything. Same thing for variations and variables and all that.

But I really want to like move to the React side now. And also because we are in a React conference after all. So the React SDK complements the core JavaScript SDK, which is only like six kilobytes in size, the core SDK. Like it's very, very small and very, very efficient. And there's a provider component that you import from the React package of FeatureVisor. You set the instance at the root of your components tree, so that like all your child components can like make use of this. And it has a bunch of different hooks. So if you want to check the flag status, if a certain feature is like enabled or disabled, you can import the use flag hook and then call it synchronously in your component. And then like evaluate it and react to it like whatever way you want. Same for variations, like use variation hook or A-B test. Same for variables if you want to have some remote configuration. So all of that is, all of the common use cases are like already covered for you. And it works with React Native too. So I tested an iOS application myself. There's an example repository too. So it's the same package that works everywhere, because React Native already comes with a fetch API. So you have that covered. That's the only API that FeatureVisor has a dependency on. And so yeah, like you really can completely decouple your like application development and your feature management separately. So that like you can tweak the configuration at the time of your choosing without having to go through the deployment process of all your individual applications in your organization. And many of you may have like multiple teams managing multiple different services in backend, frontend. You can bring them all in one place with this tool.