What I’m working on

(Concisely describe my current challenge and the question(s) I’m trying to answer)

Our project backend needs modularity and servicing of different frontends (web and mobile):

  • What are the ideal use cases for feature flags?
  • Can feature flags be used for modularity long-term?
  • How are feature flags different from simple boolean checks?

What I Learned

(Summarize new knowledge, reflections, or insights gained.)

Feature flags are runtime toggles that let you enable or disable specific features without redeploying code.

Under the hood, feature flags ultimately resolve to boolean checks: true means the feature is enabled, false means disabled. The logic is just boolean, but a framework (like Microsoft's FeatureManagement) can make it dynamic, scalable, and maintainable, instead of just hardcoding if (someBool). Plain bools are static and scattered in code, making per-user control and runtime changes hard.

However, while feature flags allow modularity like turning modules on/off per user, profile or company, they are designed for gradual rollouts, kill switches or A/B testing. As such, feature flags are often used temporarily - not permanently, as we need in our project.

Feature flags can still be used permanently, and some apps seem to do this for “premium modules” or per-customer customization, but it does not seem like the modern or fitting approach for our use case. Having many flags can also add a lot of overhead and branching code, which can add a lot of clutter over time.

[Update 08-28-2025] In researching modular monoliths and microservices (see post “Modular Architecture for Development”), I found that feature flags are often layered on top of these architectures. As such, they still seem to be valid to achieve modularity. However, the original point here stands: feature flags by themselves don’t provide solid modularity, but when combined with an actual modular architecture (modular monolith or microservices), feature flags can become powerful. Without decoupling: a flag is just a UI toggle, while backend logic still runs, and good decoupling ensures turning a flag off doesn’t break anything.

The Microsoft.FeatureManagement library offers central configuration for feature flags. It allows checks in controllers or services to determine whether a profile has access to a feature. A [FeatureGate("Courses")] annotation can be user for global toggling (“should anyone/no one see this?”) while IsEnabledAsync("Courses") with a targetingContext can be used for fine-grained per-user or per-company logic like shown below:

image-11.png

A simple test project demonstrating Microsoft Feature Management: Feature Flags Experiment

For production scenarios, feature flags can also be integrated with databases (to store per-user or per-company settings) or cloud services.

What do I need to do

(Write about any obstacles, or upcoming questions, that I may need to address)

  • Research microservices as a potential solution to modularity: they seem to naturally allow modular features per service.
  • Investigate how microservices can expose or restrict functionality per user/company, effectively “toggling” features at the service level.

Material

(Links, tutorials, or reference material)