Influx Success Story

Transcript of the Conversation

Hey there, this is Gavin with the compute team here to talk about how we can use ConfigCat feature flags for Cloud to user testing.

The goal of this demo is to illustrate one possible user testing flow using ConfigCat feature flags. This demo is not the only pattern possible, there are a lot of opportunities to put the pieces of feature flags together to tell different user testing stories, whether we want to test different segments, or percentages of the customer base, or sit down with specific users and show them some prototypes. A lot of these different possibilities are possible with ConfigCat. Today we're just gonna show one pattern where we've got specific users in mind and we want to show them different prototypes.

Quick caveat, these patterns are new and untested, the backend's only had ConfigCat enabled for a couple months, the UI just got access, so there's probably some work to do to facilitate this user testing and iron out some kinks, but this is what we got so far.

Before we dive in let's just go through a quick overview of the feature flag architecture we've built out for cloud 2.

We're using a third-party SAS product called ConfigCat and that's where we configure our feature flag targeting rules. So we set those rules up in the ConfigCat console and they're saved in the cloud and then pulled down periodically by the cloud 2 cluster back-end. Those services pull down these roles and then they use the user ID, org ID, and other attributes associated with API requests, to actually evaluate those rules and compute a specific flag value for each API request that comes in.

So for example, we could turn on a certain feature for a specific user and have that user get a specific feature flag value, while all the other users send an API request get the original value.

If you look at the bottom left here, you can see that some of these feature flags can be opted in to also be exposed to the front end and used similarly there to control presentation and behavior on the front end. These are exposed by the API/v2/flags endpoint which is built into the existing UI framework so they can be used like any other feature flags that we have.

A quick overview of the demo we're gonna do before we dive in. The first thing we're gonna do is create a flag in the Influx DB configuration. And then we're gonna consume that flag in the Influx DB UI code. These first two steps are all you need if you're doing a feature flag in OSS, since we're focusing on cloud 2. We're then again gonna proceed to step 3 where we're gonna add our new flag to ConfigCat, so we can control it there. And then we're gonna deploy our flag to IDB. We're actually just gonna pretend and deploy it to my laptop for today. And then finally step 5, the rubber's gonna hit the road and we're gonna configure the flag to return a different value for different test users. We're gonna login and we're gonna see the page behave differently for each user.

In the example that we're gonna use today, you can see on the screenshot on the right. If you search for dashboards and your search criteria doesn't return anything, you see this message "no dashboards match your search term." For our contrived example today we're gonna pretend that we want to do some user testing on the language of that message. So we're gonna return different messages for different users.

Here I am in the flags.yaml file, which exists at the top level of the influx DB repository. I'm gonna add a new configuration item here to describe the flag that we're gonna be adding. We're gonna call this flag "Dashboards Empty Search Results". I will give the flag a description. I will give it a programmatic key. This is the key that the computer uses to interact with the flag. We'll give it a default value. We're gonna actually set the default value to the original message that is currently shown to customers, so that by default we don't change any behavior. I'll make myself the contact in case anybody has questions about this flag and then finally, I'm gonna set exposed to true. This attribute is gonna opt in this flag to be exposed to the front end so it can be used not only on the back end but also on the front end.

And then I'm gonna run one command here make flags. That's gonna generate some go code based on this configuration. If you're just working in the UI, the fact that it's generating some go code doesn't really matter to you. You don't need to interact with any go code to use it, this just helps us maintain some type safety in the backend.

So now, we can consume work our new flag in some code. I'm gonna hop over here to the DashboardsTableEmpty component, and we can see the original message here "no dashboards match your search term". We're gonna comment that out and instead we're gonna actually use the value that's coming back from our feature flag. We can do that like this: flagString is gonna return the string value at the key that we've provided which is dashboardsEmptySearchResults and you'll notice that this key matches the key that we put into the configuration. Take note of this key because this key is really the the ID of the flag and we're also gonna use it when we configure ConfigCat.

Here we are on the ConfigCat dashboard. We're gonna add the flag here to correspond to the configuration that we just added. We're gonna add a text setting. Put the key in just like it was in the configuration file. The name will also make match but it doesn't have to match necessarily. And then in a description here you can see me can set initial values. We're not going to deploy this so we don't care about production or tools right now but we're gonna use the acceptance environment and we'll set this again to just match the default original message.

So you'll notice we've set a default in two different places. We've set a default in our local configuration. So if our code can't talk to ConfigCat, it has a default, but then also we're setting this initial value in ConfigCat, so ConfigCat is gonna return this value for any users that it doesn't match. So for example, if we set a feature flag to change the language for one specific user but not for anybody else, it's gonna return this default value for everybody else.

Finally we'll click "Add text setting" and then while we're in here - you can see it created it here - while we're in here we're gonna set our targeting for our specific test users. So we click add new targeting role and we're gonna provide our users' identifier. And then we can provide a different value so the original message is pretty neutral "no dashboards matches your search term". Let's see, maybe we want to experiment with being a little bit more mean to our customers, so "no dashboards found dummy". I'm not sure that will go over well, but we'll see. This is what user testing is for and then maybe we want to try the other way for a second user. We can try being a little bit nice and see which which one our users prefer. Cool, so now we've configured two different values for our two different test users.

You'll note that I've scoped them by local/local. You'll see in the other real examples, there's scope for the actual environment provider and cluster name. That's because we only have one ConfigCat config for each deployment phase, so for example, in "acceptance" we've got multiple staging environments and you'll need to indicate which staging environment your ID lives in. Since I'm running off my laptop, I've just set this to local for now so it's a little bit strange. So now, we're just gonna save and then we can hop into the actual UI and see our flag get used.

Okay so now we'll login with our default user first, and we'll show that the feature flag by default shows the original value. There's that "no dashboards matches search term". Now we'll log in is our test user and we'll see that we get the feature flagged value returned "no dashboards found dummy". It's pretty mean. And then we can log in as our second test user and we can see they get the second configured feature flag.

So here we have three different users by default. We see the original message and then we've got two users that we're doing some user testing with and we're testing a mean prototype, and a nice prototype of this language.

And that's basically it for user testing with ConfigCat's feature flags in Cloud 2. Here I've got some links that are provided with this presentation for some more specific documentation and get into the nuts and bolts of it. As well as some ConfigCat concepts.

And if you have any questions please reach out. Thanks!