Unveiling Feature Toggles in Angular: A Prelude to Server-Driven Configurations
Shout out to my fellow developers and tech enthusiasts! ๐
TLDR;
Stackblitz with code: Angular Feature Guard
Today, we embark on a journey through the complex world of feature management within Angular applications. The concepts can be translated into any frontend technology and are not exclusively tied to angular. In this series, we'll uncover the elegance of dynamic feature toggles and how they can revolutionise the way we deliver user experiences and of course ship/test features on different environments.
The Power of Route-Based Access Control
Initially we began with the implementation of a route guard, which prohibits routing depending on a currently hard coded feature/route configuration. For this we used the more modern approach of a functional route guard. The route guard imports a feature service, which in turn delivers a simple configuration to the route guard. The guard decides based on the config whether it is allowed to route to the desired location in the app or if it has to show a component which tells the user that he is not authorised to see the requested route. Furthermore we have introduced a HideFeatureDirective which creates a view depending on whether the user has viewing rights or not. This configuration could be extended to any conditions thinkable. And will in a later series be plugged into a user management/identity provider.
๐ The HomeComponent: Within the cozy confines of our HomeComponent, we've harnessed the HideFeature directive to control button visibility, crafting a user interface that's both intuitive and secure. Disclaimer: Please don't blame me for the inline styles/templates. This is due to the fact, that I want to keep it simple stupid. In Later series we might see a tailwindcss integration.
๐ง The Feature Service: The magic doesn't stop there. The FeatureService stands as the backbone of our feature toggle system. Itโs where we define our features' availability, ensuring that our app's behavior adjusts in real-time to our needs.
๐ก The Functional Route Guard: Angularโs route guards typically stand sentinel at the gates of each route. In our implementation it consults a feature/route configuration to make real-time decisions. When a route includes a featureKey
in its data, our guard springs into action, querying the FeatureService
to see if this feature is toggled. If not, access is denied, guiding users only to the features they're meant to engage with. It's like having a smart lock on your application's doors, ensuring every entry is as intentional as it is seamless. ๏ธIn Applications with user registration and auth token, it should either also test for authentication, though, it is recommended to create an own service, dedicated for checking a valid login.
๐ซฃ๏ธ The HideFeature Directive: The HideFeatureDirective allows us to bind feature visibility directly to our template, combining declarative templates with imperative logic. It creates or clears our viewContainer and makes the part of the view accessible or not. There are other approaches to hide a ui part, such as css solutions, that simply use display none, but I prefer the programmatic version, which makes absolutely sure, that there is no interaction possible if the feature is not toggled/enabled.
โ๏ธ The Main.ts: here we provide all the injection tokens we created with implementations and setup routing.
And last, but not least a small feature component that is currently only there to highlight our intentions and for demonstration purposes.
feature-a.component.ts (all other feature components and the unauthorized component are equivalent)
What's Next?
But this is just the beginning. In the next installment of our series, we'll be expanding our horizons beyond the Angular realm. We'll delve into the server side with NestJS, creating an AuthController that dynamically serves configuration.
In order to reach this goal, we will firstly introduce an NX Workspace, so we can manage and share code in a monorepo manner.
Imagine a world where your Angular app's features are no longer hardcoded but are fluid, controlled by server responses, adapting to user roles, permissions, and more. Stay tuned as we explore how to build a NestJS app that will serve as the central hub for managing our feature flags.
Join me in Part 2 as we build on our Angular foundations, constructing a NestJS app equipped with an AuthController that returns a tailored feature config. We'll see how server-driven configurations can further enhance our application's flexibility and user experience.
For now, I leave you with a repository of thoughts and codes snippets to ponder upon, and I invite you to share your insights and experiences with dynamic feature toggles.
Here is a Stackblitz of the current implementation. In the next part we will move this to a public github repo with nx: https://tinyurl.com/feature-directive-example
Until next time, keep coding and stay curious! ๐ปโจ
Stackblitz with code:
#Angular #FeatureToggle #WebDevelopment #NestJS #AuthController #Coding #JavaScript #TypeScript #ServerDrivenConfig #DynamicConfig #DevBlog #Cheveo
๐๐ง๐๐ ๏ธ๐
About the Author
Danyal
Iqbal
Senior Software Engineer
Who Am I?
Iโm an enthusiastic web developer boasting over 6 years of experience crafting web applications using technologies such as Angular, NestJS, TypeScript, NodeJS, Golang, Amazon Web Services, and Firebase. I have a relentless drive for learning new techrelated concepts and techniques to continually enhance my engineering skills. I take pride in my strong communication abilities and enjoy engaging in discussions about effective implementations and architectural ideas.