Feature Flags can be used to show different variants of a feature to each visitor. Which variant a visitor sees can depend on their unique attributes. This article describes the ins and outs of how you can configure your feature flags to show each user the variant of a feature they are supposed to see.
Let's quickly recap the basics.
<h3 id="happykit">HappyKit</h3>
HappyKit is a feature flagging service specifally written for Next.js. What sets it apart from the competition is that it integrates extremely nicely with Next.js. No matter if you're using SSR, CSR, SSG or a mix of it, HappyKit has got your back.
This article doesn't show these features off, but you might want to explore them on <a href="https://flagshappykit.dev/">flags.happykit.dev</a> or in the <a href="https://github.com/happykit/flags"><code>@happykit/flags</code></a><a href="https://github.com/happykit/flags"> docs</a>.
Okay, enough context building. Let's get to the actual flag resolution logic.
<h3 id="variants">Variants</h3>
When you create a feature flag in HappyKit, you first need to choose the type of the feature flag. It defines the type of the values your feature flag will resolve to.
These three types are available:
<ul>
<li>Boolean</li>
<li>String</li>
<li>Number</li>
</ul>
For example, a feature flag of type Boolean has two variants: One with a <code>false</code> value and another with a value of <code>true</code>. So when the feature flag gets evaluated, it can either resolve to <code>true</code> or <code>false</code>.
You can also add an optional name and description to each value. These are only ever used to make the HappyKit's UI more meaningful. They are not used when the feature flag gets evaluated.
<img src="https://happykit.dev/content/assets/variant-meta.png" alt="">
A feature flag of type String can resolve to any string. You need to create a new variant for each string your feature flag might resolve to.
And lastly, a feature flag of type Number can resolve to any number.
<h2 id="environments">Environments</h2>
HappyKit knows of three environments: production, preview and development.
All feature flags will always exist across all environments. However, each feature flag can be configured differently per environment.
Environments can be switched at the top of the page.
<img src="https://happykit.dev/content/assets/environments.png" alt="">
When you integrate HappyKit into your application using <code>@happykit/flags</code>, you can set the <code>envKey</code> by calling <code>configure()</code> as shown <a href="https://github.com/happykit/flags/tree/master/package#setup">in the setup instructions</a>.
<code>@happykit/flags</code> will then evaluate all feature flags for the environment you chose based on the Environment Key you passed in.
<img src="https://happykit.dev/content/assets/keys.png" alt="">
It's typical to store your Environment Keys in an Environment Variable, so that each environment uses the appropriate HappyKit environment.
<h3 id="active-vs-paused">Active vs Paused</h3>
A feature flag can either be active or paused, for each environment.
So a feature flag might be paused in production but active in development.
<img src="https://happykit.dev/content/assets/active-vs-paused.png" alt="">
You can see and toggle the state of a feature flag per environment. The screenshot above shows a feature flag that is active in the production environment. It can be paused by clicking the switch next to the label.
When a feature flag is paused it will skip all configuration and always show the paused default.
<img src="https://happykit.dev/content/assets/default-paused.png" alt="">
When a feature flag is active, it will respect all evaluation rules. It will respect the Target individual users settings you configured (mroe on this later), as well as the Target by rules settings. If none of these match, it will fall back to the active default.
<img src="https://happykit.dev/content/assets/default-active.png" alt="">
This approach to feature flags regularly surprises people who use feature flags for the first time. The approach is chosen as it's the most versatile. It can handle pretty much any use case. The nicest property of this approach is that you won't ever have to think about your advanced configuration in case you simply want to turn off a feature as quickly as possible. It also allows you to keep your configuration around for when you eventually turn the feature flag back on.
<h3 id="target-individual-users">Target individual users</h3>
This setting allows you to show a specific variant of a feature to a specific user based on their user key.
<h3 id="showing-a-feature-only-to-a-select-group-of-people">Showing a feature only to a select group of people</h3>
A common use case for targeting individual users is when you want to show a feature only to specific users, while keeping it off for everyone else.
To do this, first configure the defaults to both hide the feature.
<img src="https://happykit.dev/content/assets/defaults-for-individual-user-targeting.png" alt="">
Then turn the feature flag on by setting it to Active. No one will be able to see the feature at this point, since the feature flag is on, but the default is set to not show the feature.
Next, show the feature to the desired users using Target individual users.
<img src="https://happykit.dev/content/assets/target-individual-users.png" alt="">
Finally, pass the keys as <code>{ user: { key: "..." } }</code> when evaluating feature flags.
Since the feature flag is active, it will now respect your individual user targeting rules. It will fall back to the default if none of these match. The active default is configured to hide the feature.
This setup achieves exactly what we wanted: showing the feature to a select group of users only.
<h3 id="target-by-rules">Target by rules</h3>
Next up is targeting users by using rules. This is similar to targeting indiviual users, but way more powerful.
You can target anyone visiting your app based on:
<ul>
<li>visitor key - A key HappyKit automatically assigns to your visitors</li>
<li>user - Information about the user you may provide when evaluating feature flags</li>
<li>traits - Any other generic information you may pass along when evaluating feature flags (like the name of the current branch)</li>
</ul>
I'll not go into more details here as this is likely enough to fill another article. Just know that the system is really powerful and you'll likely be able to achieve whatever you have in mind.
<h3 id="summary">Summary</h3>
All feature flags always exist across each environment. Each feature flag can be configured differently per environment. The variant a feature flag evaluates to depends on the environment you are evaluating it in and on the provided inputs, for example the user key for individual user targeting.
Flags can be active or paused. When a flag is paused, it will go straight to the paused default. When a flag is active, it will try to match by individual user targeting. If none match, it will try to find a matching dynamic rule. If none of these match, it will fall back to the active default.
Not a HappyKit user yet? I'd love if you try out HappyKit. It's free for personal projects. Create your first feature flag at <a href="https://happykit.dev/signup">happykit.dev/signup</a>
If you have an questions about how feature flags get evaluated, or about HappyKit in generaly, feel free to tweet at me or send me a DM on Twitter. You can follow my journey building HappyKit on Twitter as well: <a href="https://twitter.com/dferber90">@dferber90</a>.
If you're looking for a more details introduction, check out <a href="https://frontend-digest.com/using-feature-flags-in-next-js-c5c8d0795a2">Using Feature Flags in Next.js</a> which will walk you through the full setup.

Learn how to configure your feature flags to show the right variant to the right visitor.

The ins and outs of configuring your feature flags.

How HappyKit evaluates Feature Flags

Turn your API Routes into cron jobs. Execute them on a fixed schedule, reliably. HappyKit Taks are great for anything you need to run periodically.

Announcing HappyKit Tasks, the easiest way to run cron jobs in Next.js.

HappyKit Tasks: Turn your Next.js API Routes into Cron Jobs

Working with Next.js is absolutely great. I firmly believe Next.js will be the foundation for a growing number of web applications for the foreseeable future.
And I noticed that something is missing.
<h3 id="a-friend-to-run-with">A friend to run with</h3>
Next.js itself is the best framework I have ever used to build web application. But there are some things almost every web application needs that a framework just can't provide.
Some examples are Analytics, Feature Toggling, Cron Jobs, Event Tracking and so on.
The traditional solution to this problem space has been to use different SaaS-tools, each solving a different piece of the puzzle. But sometimes the pieces just don't connect with Next.js or with each other. Hard to integrate. And having to use many different services can get quite costly pretty quickly.
HappyKit wants to be your one-stop-shop which offers the most common things any web application needs out of the box. Interconnected, easy to use, quick to integrate and built specifically for Next.js.
Think of HappyKit as the "control center" for your application.
<h3 id="innovation">Innovation</h3>
One of the biggest innovations Next.js has brought along is that it made it possible to write code for the server and the client in the same project and even in the same file.
The existing npm ecosystem either offers packages for the client or the server. In some cases isomorphic packages can run on either side. But they are almost never written in a way where data is expected to flow from the server to the client, while including both sides.
HappyKit's tools are designed for Next.js specifically, so they can take full advantage of these capabilities. The prime example of this is Feature Toggling.
As with most other Feature Toggling solutions: You can call something like <code>useFlags()</code> on the client to load the latest feature flags.
But with HappyKit, you will be able to preload the feature flags on server-rendered pages using <code>getServerSideProps</code>. You can then pass them to the client as props. This allows you to get perfect server-side rendering where the server-generated markup matches the initial render on the client exactly. On the client, you'll then call <code>useFlags(props.initialFlags)</code> to rehydrate what the server provided. And the client will sync the flag state from thereon out.
Another example of HappyKit's tight integration with Next.js is HappyKit Analytics. HappyKit Analytics is a dead-simple analytics service specifically built for Next.js. The vast majority of current analytics services are integrated using a tiny snippet added to HTML which loads a much bigger suite later on. This slows your application down and causes an extra HTTP request. HappyKit Analytics comes as an npm package which is only 1kB as it reuses the Next.js router. No additional HTTP request to load a large analytics suite. Just a single kilobyte. Thanks to the tight integration with Next.js, HappyKit Analytics not only tracks which paths your traffic is going to, but it can further show you your most popular paths. To give a more practical example: HappyKit Analytics tracks page views of paths like <code>/blog/foo</code> and <code>/blog/bar</code>, but it can also track page views per underlying route like <code>/blog/:slug</code>. This allows you to get low level and high level insights without configuring anything.
Feature Flags and Analytics are just two examples of HappyKit's great pairing with Next.js. This coupling gives you big advantages over traditional solutions. We can do similar things for Performance Metrics, Event Tracking and other services. I look forward to explore these more as HappyKit grows.
<h3 id="bundled">Bundled</h3>
Imagine you open up HappyKit and visit the stats of one of the posts on your blog. Let's say you're viewing the stats for <code>/blog/trip-to-california</code>. For this route, you see how much traffic it received. That's pretty normal for any analytics service. But thanks to the Next.js integration, you can further see how much traffic blog posts under <code>/blog/:slug</code> receive in general. Maybe you were trying out a different blog layout. You also see which Feature Flags were enabled on this page, and the distribution of viewers who were shown each version of your layout. Maybe you were using server-side rendering to preload the feature flags. The Performance-section shows you how long server-side rendering took for this blog post, and the number of times the requests succeded/failed. Did you build a call-to-action into your blog post? You can log each newsletter signup using HappyKit Events. The same page showing you all the other information will then also show you the most recent events, and the top events fired there.
<h3 id="motivation">Motivation</h3>
As HappyKit grows, more and more tools will end up in its toolbox. The benefit of having interconnected, purpose-built services and aggregating the information seamlessly drives me to make HappyKit the ideal companion for Next.js.
Build less. Make more.
HappyKit is free for your personal projects. Start <a href="https://www.notion.so/signup?ref=blog">here</a>.
There will likely be a paid plan for teams later on. For now I'm focused on building the best possible tools to get sophisticated users and your immensely helpful feedback.
Follow my journey building HappyKit on Twitter: <a href="https://twitter.com/dferber90">@dferber90</a>.

Why I'm building a control center for your Next.js applications