It should be cached in a way that invalidates the cache whenever the feature flag changes. This way you get instant updates, but only when something changes.
Really glad to see more advanced content in your channel. I already use feature flags in my office project with the database solution. VIDEO IDEA: make a video on logging service from simple to advanced
Thanks Kyle! For flexibility, I think using a function for the featureFlagRule would be great. You could just then use arbitrary logic and return a boolean. I'm not sure how nicely this approach would play with database storage though.
Also implementing the feature flag on database, with indexation and caching it will always add more latency than if it was in code or env vars; but it can be blazing fast to retrieve and transparent to users!
I cannot see why using the cache would be a good idea: it will literally break the concept of feature flags, as you will not be able to update them anymore in case of a bug
What I am saying to do is cache the feature flags themselves (not the code they output). Then whenever you change a feature flag you invalidate the cache. This will ensure getting a feature flag is quick (except the very first time it is checked after the cache is wiped)
But then to check if the cache needs to be invalidated, wouldn't you then need to fetch the flag on everyone's its checked defeating the point of cache
@@lifeisfakenews, here are two options I've written in the past for this: 1) Have an environment variable that you can set to force the cache to flush and refresh the values - handy for a kill switch but not the ideal scenario; 2) My preferred way is to have a single API that is behind authN/authZ that I can call. It has zero input parameters and just flushes the cache and forces a refresh of all values into the cache. Neither option is ideal but they're a couple of options you can use.
That is not the case. For simplistic purposes assume the cache is just an object in memory that stores the value of our feature flag. When we check a feature flag we first check this in memory cache to see if it is there. If it is there we are done and do not need to make any queries to the DB. If it is not there we query the DB for the information and then save it in the cache. Now jump forward to when we want to update that flag. We update the flag in our DB and remove the flag information from our in memory cache. The next time someone tries to get the flag data it will see the cache is empty, get the information from the database, and save it to the cache for later use.
I find that people start to understand SOLID principles more when using feature flags, as you have to have no side effects with existing code. There is another way to use feature flags, if your app is server side, you can have special headers that you can use when making an HTTP request; for more security, add a special token that only the developers would have.
You've kept it simple, and that's great. But don't let your feature flags encroach on your auth scheme. Auth role bloat is real, and many times it's due to excessive group memberships that control visibility outside of secure roles. But you do want this. For instance, a UI element that draws a new component that includes a button to call the API? The backend must be aware of that flag, otherwise preview elements are available to callers who can gain access to it through the UI. Sign your auth token first, then have users request their feature flags using that token. The feature flags look just like an auth token, and are even signed by an authority, but do not impact mainline functionality. This feature flag token should be passed to the backend in subsequent requests in a second header like FfAuthorization. If it's present, and valid, it, along with the auth token together are used to conditionally call feature flagged backend services. Updates to feature flag internals that require global re-evaluation and expiry can use key rotation to support this. Behind the scenes, the feature flag service is backed by a database.
My feature flags are dates with timezone, sometimes with time when a feature is to be enabled for a short period of time. This allow me to know when a feature has been enabled, to schedule a new feature enablement when client has requested us to do it.
I have a feature flag which tests page creation time for every X requests of a page. So I put X into the flag (or setting) and it just mods it with a page request counter. I can turn it off by setting X to 0. This way I can test page creation time over shorter or longer periods of time and then output the average creation time directly to a monitor page automatically. I could also dig into the logs of course and make some code for that, but I like this feature for testing purposes. It's also easy to remove, as it can be removed from the whole code by another flag which is only read at server startup. All my features are set up with flags like this and can be removed from the main code at server startup, so they're essentially independent extentions or plugins. The over head of implementing such plugin system is worth it IMO in the long run, simply because I can test each feature individually or together as I like.
I like to store many data in as little space as possible, and if you want a feature to run for a certain time, or days, months, years, or just having a start or end date, you could store this information in a 31 bit integer, so reserve the upper 6 bits for flags for page count, day count, month count, year count, start date or end date. In order to store a date, you would need 31 days +12 months +99 years, which would result in 31 days (5 bits), 15 months (4 bits), 127 years (7 bits), so you would need 16 bits, and it's more than enough because there are 31-6=25 bits to take from. I don't know if time zone could be implemented into that too though. But you could also implement time into it like hours or minutes. You can even add flags for user or admin mode too.
@@AntiAtheismIsUnstoppable for metrics I prefer open telemetry, traeffic (http router) or similar "out of the box" tools. For Open Telemetry you can rely on existing semantic conventions to provide your metrics in a reusable way. Being a "good citizen" by following those semantics brings you a lot of possibilities to aggregate and access metrics: you can link databases metrics to each of their parents' page generation ones to understand why some of page requests are longer than others, the same way you debug JavaScript performance with your brewer's flame chart.
10:45 - but the UI could be made to also control ENV variables (or even code). Obviously, code that changes other code is a horrible idea but it's all possible.
You'd go with the database storage option for this - admin page could allow an admin user to turn on or off a feature flag, that would be propagated to the DB (and invalidating any cache).
Good stuff Kyle! Thanks for sharing this. I've been working with FF for more than a decade, from using custom implementation to SaaS and third-party FF managers. I understand that FF are not a silver bullet when it comes to safely continuously integrate code in a releasable state. I also have an Open Source project called Switcher API that can help with managing features. I have been maintaining this project for over 4 years but as a solo maintainer is a bit hard for me to keep up with so much work as I do in my free time. There is a production SaaS with some limitations but also plenty of resources to self-host it using Helm Charts.
Hi Kyle, as an idea for one of your fiture long form videos, maybe you could inplement a web file system akin to vscode, with folders, files, dragndrop, searching, renaming etc
Is using cache faster than using a database in this case though, assuming our database were optimised, we use a key-value-pair store like Redis for caching and the latency between the server and both the database and cache are similar? I think a SQL database would be as fast as such caching solutions, except if by caching you meant we chose to cache the values in our program, which should be faster, but update would still be more difficult by having to do cache invalidations for each servers.
just one question here, if the feature flag assignment is random to 25% user. then is it possibble that today if i login i get the feature bbut tomorrow I wont?
I suppose the only issue is if these are exposed to the user. Hiding sensitive pre release features would need to be done carefully (so caution is required) so ensuring these are serverside only is important. I use feature flags all the time to ramp up new features to a subset of customers for slow dialup, which is invaluable. Yay feature flags! 😂
Excellent tutorial Kyle! I’ve taken the approach in my project of assigning a logged in user to a bucket preemptively, right after login (having 100 buckets). This is just like yours, deterministic and it’s calculated just once, so that checks are userBucket
Depends on what you want the behaviour to be like. Assuming the front checks if the session storage key is set on every page load, and makes a request to the relevant endpoint if it can't find it, that means that tab will only make one request as long as it's open. If the data becomes stale, then there's no practical way to update it and you will have to wait for the user to close that tab and open a new one. Also, note that session storage data is not shared between tabs. If that's the behaviour you expect, then you're good, otherwise, you might want to look into localStorage or session cookies.
This has some issues that may or may not be problems for you depending on where you are storing your session. If you are using the browsers session storage then every time someone comes to your page for the first time they will have no data in the cache. If you are using a server based session storage then it depends on how long that data is persisted and would work very similar to a normal caching system if the data is persisted long term.
Do a mix of Code, Env and Database. Code for something that needs quick changes from DEVs but can wait a month or three for deployment. Env for something that is not critical and hardly ever needs changed. Database/SaaS for most things including % of users and extremely for critical. Instead of adding a new import (unless using it in other places) could have written a simple hash yourself. simpleHash(str) { hash = 0 for(let i=0; i < str.len; i++) { const char = str.charCodeAt(i); hash = (hash
In my project, I want to implement a feature to disable advanced analytics not only on the frontend but also on the backend. The goal is that when advanced analytics are disabled, no analytics data is collected, and the backend service responsible for analytics won't incur charges. How can I implement this configuration so it ensures analytics are fully disabled across both frontend and backend, preventing any data collection or charges?
The main problem with feature toggles is that they usually stay in the code forever and even after some time they got broken by other features. Yes, the clean code, principles, and all. But reality is that in small project, you don't need them, in a big project they eventually get broken... And don't forget that testing is ultimatelly impossible with the amount of all of combinations of turning features on, and off respectively.
I'd say this laregly depends on the culture of the team you work with and generally how prone to tech dept it is. In our team for instance this has never been a problem, really. We mostly use feature flags to AB test though, but I can imagine also making use of it in the ways described in this video without much sacrifice or risk of them getting stale / broken anytime soon. My case is a rather compact product I'd say, but with quite a lot of traffic, so deploying something as a canary test gives us as a team much more confidence.
What's wrong with leaving them in code forever? It allows you to roll out an update to a feature or remove an older feature that is no longer being supported. I see no downside to keeping them. "in a big project they eventually get broken," then you have a broken QA process. I don't see how they would become "broken." "And don't forget that testing is ultimatelly (sic) impossible with the amount of all of combinations of turning features on, and off respectively." That's absolutely false, especially with automated testing.
There is a flaw in this implementation if you want to use it for AB testing. Since the same user might end up with multiple features you will not be able to say which feature caused your users to behave differently. Also you are going to have dirty control groups with random features enabled.
Realy excellent tutorial, and a real leap for any junior developer straight into senior territory. The only thing I would add after working in several big companies with a large set of feature flags - whenever you go for feature flag structures that are not simple booleans, like the structures showed in this video, I'd REALLY recommend that you choose standard feature flag structures. Because you need to remember that every feature flag has a non-technical user that will need to set it. And non-standard feature flags that have an ad-hoc structure will be hard to render with a simple UI for the non-technical product teams that will be using it, and you'll find yourself resorting to a non-structured text editor for editing feature toggle JSONs. This is extremely flakey and will result in a loooooot of weird production issues. Use a set of predefined feature toggle structures, and extend it only if needed. Even if you're building your project alone.
Database implementation is easy, just have it part of user class, and config class. Database request speed for user tied flags is essentially free, you will be querying the user each request anyway... You may also be checking config, but 1 extra simple request per page isn't going to impact your speed by any perceptible difference. Env variable update speed is fast, at least hosting PHP on Laravel Forge, I can instantly update environment, and it can be done via API also. Database isn't any faster to update. Tell me why oh why can't you store user percentages in environment??????
You kinda mixed up feature flag and shadow traffic in my opinion when it comes to fetching data in 2 different ways. I would probably count that as shadow traffic
Funny I just built a component using Laravel Pennant that allows me to load a GUI in an admin panel based on user roles and routing. I use ReactJS for my frontend and Laravel for my backend. Maybe I was searching for ideas about Feature Flags and then this video showed up in my timeline. Hmmmm
Looks like the user can bypass the security using this if you manipulate the feature values using the console for example. Is there any secure way to implement this?
In this particular code I am using Next.js and server rendering the code behind the feature flag. This means if the feature is not enabled for the user the code behind the feature will never even get sent to the client.
I would potentially distinguish between backend feature flags and frontend ones. Frontend feature flag as in a static deployment can only be updated when you deploy new versions of those files AND the user refreshes those files. There are easier and more complicated ways (service worker) to have the browser refresh sort of automagically, or at least prompt the user to do so. I would say if you have a SPA, make sure at least these FFs aren’t meant to be kill switch, but rather for phased roll outs etc
Could you please create a Project by watching and checking it with a Figma file having any design and upload that video to this channel so that we learn & get benefits? We need to learn the strategy to complete a project quickly through Figma.
I just have one question. how does the percentage of users knows how many users my app has? I can ser it to .5 today. and in 5 days my userbase has grown lets say another million users. how does it know the total amonut of users?
It doesn't matter how many users your app has. The algorithm doesn't use that information. All it does is convert the user's ID into a percentage (0-100%). This percentage is then checked against the threshold for the feature you set. This means the amount of users that see your feature should be close to the percent you set. With a smaller number of users it will be less accurate. This is because even though the hashing algorithm is evenly distributed if you only have 100 users it is pretty unlikely they will be perfectly distributed with 1 user in each percentage range. With thousands or millions of users, though, this problem goes away as the likelihood of the randomness placing a significantly larger number of people in one particular range is miniscule.
Wait, why would you need to redeploy your code when you change your env variables? @10:28 I really hope your .env is ALWAYS part of your .gitignore... you DON'T deploy environment variables. It completely negates the purpose of them being dependant on your ENVIRONMENT, which differs for everyone pushing or pulling from that repository. Also you obviously cannot only store true/false, you can store any string you want. It is limited if you need arrays or whatever though.
Any database operation is incredibly slow compared to a cache since often the database is hosted somewhere other than the application which requires a network request. Even if it is hosted in the same place it is still slower than a cache and if you have to make 5 feature flag requests on each page that adds overhead to your request which is not ideal.
Hey, Kayal can you build an extension based software. Where can I build an application and extend it with an extension. Just like a VS code or wordpress. Start with architecture design and the coding. It's new for mid level and senior developers.
It costs almost no code and complexity to implement a FeatureManager, and you're not a dumb-dumb it costs zero network requests. This would be obvious if we hadn't all collectively decided to never ever use singletons or globals (even when the scope of an operation is actually global.)
15:58 Bro, what on earth is this? FrontEnd doesn't include any of these things you're explaining here. This is a 100% Business Logic that belongs to the API in BackEnd. FrontEnd is just a User Interface to work with the main software (API)
Good vid. But it's sooooo hard to concentrate on the material while you are shaking your head that much all the time that in many cases I just stop watching a video... Please... Pleeeease stop doing that or make circle from your camera at least twice smaller... Please, I really do appreciate the content and effort you put in it. But this tiny thing ruins a lot.
@WebDevSimplified just being honest, suggest you do the same. It would suggest you don't have experience as a lead developer in a large company. Your content is very green. I think you already know this. I am just asking you yo be upfront about it.
I have been the lead dev on projects before. I definitley don't have as much experience as many people but I never claim to be an all knowing developer with decades of experience. If there is something about my code or presentation that you think is wrong I would love to know. Most if my content is targeted towards more beginner developers so it is going to lean more towards beginner and "green" implementations.
@WebDevSimplified I would suggest being upfront about your limited commercial experience. I can see why it is attractive to beginners, but it doesn't tell a real story, if you want more honest channel call it what is, not an example of how this would be used on a commercial project otherwise it is a false economy. I get it, you are young, and these distinctions aren't immediately obvious, but just be honest, and the rest will flow.
It sounds like you have no issue with the content I am producing and the only issue is with my age. That is fine. I have over a decade of experience in web development and have worked with many companies across different verticals, sizes, and scales. I obviously don't have the same experience as someone that has been programming since the 80s, but I do have enough commercial, enterprise, and start up experience to make content talking about topics related to them.
I'm absolutely loving this "Like a Senior Dev" series, it feels like these architecture patterns are rarely talked about.
Literally just got a ticket to add a flag around a new analytics feature yesterday lol your channel speaks to me man 😂 great tips!
Amazing content Kyle, the concepts that you explain and the importance of them as well, keep doing it please.
thanks for sharing your knowledge !
excactly one of the things i'm implementing for the first time at work atm - cheers mate!
Excellent content. Absolutely loving it. Keep making like these awsome videos.
Kyle - I love love love these deep dives, I find them so valuable!
Thank you so much!
I really like these concept Kyle. Please keep going !
Thanks
You are very welcome!
Keep up the brilliant work. 👏Really enjoyed this video and would love to see more about concepts and architectures.
love that you started make more depth content )
If you decide to cache it, the TTL needs to be inversely proportional to the request rate and how critical the feature is.
It should be cached in a way that invalidates the cache whenever the feature flag changes. This way you get instant updates, but only when something changes.
@@WebDevSimplified how would you do that ? By requesting changes on each new session for instance ?
@@fluentai-extension you're not caching them client-side, therefore whenever you change something you just clear the cache.
Really love the breakdown and would like to see more of these!
Really glad to see more advanced content in your channel. I already use feature flags in my office project with the database solution.
VIDEO IDEA: make a video on logging service from simple to advanced
Your videos are awesome, man! Keep it up!
GREAT stuff. Please do more like this!
Love it. And just for anyone curious: Unleash.
Thanks for providing the github link, it helps understanding a lot to be able to read it through
Thanks Kyle!
For flexibility, I think using a function for the featureFlagRule would be great. You could just then use arbitrary logic and return a boolean. I'm not sure how nicely this approach would play with database storage though.
Thanks for the explanation. I would like , please, more videos about this subject.
Thanks for the video, I like this approach around fundamental concepts of software architecture
Also implementing the feature flag on database, with indexation and caching it will always add more latency than if it was in code or env vars; but it can be blazing fast to retrieve and transparent to users!
I cannot see why using the cache would be a good idea: it will literally break the concept of feature flags, as you will not be able to update them anymore in case of a bug
What I am saying to do is cache the feature flags themselves (not the code they output). Then whenever you change a feature flag you invalidate the cache. This will ensure getting a feature flag is quick (except the very first time it is checked after the cache is wiped)
But then to check if the cache needs to be invalidated, wouldn't you then need to fetch the flag on everyone's its checked defeating the point of cache
@@lifeisfakenews And that's why you put a timeout on the cache invalidation.
@@lifeisfakenews, here are two options I've written in the past for this: 1) Have an environment variable that you can set to force the cache to flush and refresh the values - handy for a kill switch but not the ideal scenario; 2) My preferred way is to have a single API that is behind authN/authZ that I can call. It has zero input parameters and just flushes the cache and forces a refresh of all values into the cache.
Neither option is ideal but they're a couple of options you can use.
That is not the case. For simplistic purposes assume the cache is just an object in memory that stores the value of our feature flag. When we check a feature flag we first check this in memory cache to see if it is there. If it is there we are done and do not need to make any queries to the DB. If it is not there we query the DB for the information and then save it in the cache.
Now jump forward to when we want to update that flag. We update the flag in our DB and remove the flag information from our in memory cache. The next time someone tries to get the flag data it will see the cache is empty, get the information from the database, and save it to the cache for later use.
Are you the encyclopedia of web development? 🤩I love this video, thank you for your careful explanation.🥰
I find that people start to understand SOLID principles more when using feature flags, as you have to have no side effects with existing code. There is another way to use feature flags, if your app is server side, you can have special headers that you can use when making an HTTP request; for more security, add a special token that only the developers would have.
Well explanation, especially the database stuff at 8:35, never know we could do that.
The hash thing is just genius
that a great way to test things. Thank you for such videos.
You've kept it simple, and that's great. But don't let your feature flags encroach on your auth scheme. Auth role bloat is real, and many times it's due to excessive group memberships that control visibility outside of secure roles. But you do want this. For instance, a UI element that draws a new component that includes a button to call the API? The backend must be aware of that flag, otherwise preview elements are available to callers who can gain access to it through the UI. Sign your auth token first, then have users request their feature flags using that token. The feature flags look just like an auth token, and are even signed by an authority, but do not impact mainline functionality. This feature flag token should be passed to the backend in subsequent requests in a second header like FfAuthorization. If it's present, and valid, it, along with the auth token together are used to conditionally call feature flagged backend services. Updates to feature flag internals that require global re-evaluation and expiry can use key rotation to support this. Behind the scenes, the feature flag service is backed by a database.
Damn! This is a great one.
Thank you for the great video. I learned a lot. For other video ideas, could I suggest caching?
Very helpful, thank you!
I wanted to implement feature flags for a long time but did not manage to find a suitable tutorial for beginners
My feature flags are dates with timezone, sometimes with time when a feature is to be enabled for a short period of time.
This allow me to know when a feature has been enabled, to schedule a new feature enablement when client has requested us to do it.
I have a feature flag which tests page creation time for every X requests of a page. So I put X into the flag (or setting) and it just mods it with a page request counter. I can turn it off by setting X to 0. This way I can test page creation time over shorter or longer periods of time and then output the average creation time directly to a monitor page automatically. I could also dig into the logs of course and make some code for that, but I like this feature for testing purposes. It's also easy to remove, as it can be removed from the whole code by another flag which is only read at server startup. All my features are set up with flags like this and can be removed from the main code at server startup, so they're essentially independent extentions or plugins. The over head of implementing such plugin system is worth it IMO in the long run, simply because I can test each feature individually or together as I like.
I like to store many data in as little space as possible, and if you want a feature to run for a certain time, or days, months, years, or just having a start or end date, you could store this information in a 31 bit integer, so reserve the upper 6 bits for flags for page count, day count, month count, year count, start date or end date. In order to store a date, you would need 31 days +12 months +99 years, which would result in 31 days (5 bits), 15 months (4 bits), 127 years (7 bits), so you would need 16 bits, and it's more than enough because there are 31-6=25 bits to take from. I don't know if time zone could be implemented into that too though. But you could also implement time into it like hours or minutes. You can even add flags for user or admin mode too.
@@AntiAtheismIsUnstoppable for metrics I prefer open telemetry, traeffic (http router) or similar "out of the box" tools.
For Open Telemetry you can rely on existing semantic conventions to provide your metrics in a reusable way. Being a "good citizen" by following those semantics brings you a lot of possibilities to aggregate and access metrics: you can link databases metrics to each of their parents' page generation ones to understand why some of page requests are longer than others, the same way you debug JavaScript performance with your brewer's flame chart.
10:45 - but the UI could be made to also control ENV variables (or even code). Obviously, code that changes other code is a horrible idea but it's all possible.
You'd go with the database storage option for this - admin page could allow an admin user to turn on or off a feature flag, that would be propagated to the DB (and invalidating any cache).
I built a whole system based on this without even knowing what it was, its a tool used to build other website like a temple
Good stuff Kyle! Thanks for sharing this.
I've been working with FF for more than a decade, from using custom implementation to SaaS and third-party FF managers. I understand that FF are not a silver bullet when it comes to safely continuously integrate code in a releasable state.
I also have an Open Source project called Switcher API that can help with managing features. I have been maintaining this project for over 4 years but as a solo maintainer is a bit hard for me to keep up with so much work as I do in my free time. There is a production SaaS with some limitations but also plenty of resources to self-host it using Helm Charts.
Great Video. Add unleash to your comparison and everything is green :-D
Hi Kyle, as an idea for one of your fiture long form videos, maybe you could inplement a web file system akin to vscode, with folders, files, dragndrop, searching, renaming etc
11:34 why env var can only store boolean and not other data types?
Is using cache faster than using a database in this case though, assuming our database were optimised, we use a key-value-pair store like Redis for caching and the latency between the server and both the database and cache are similar?
I think a SQL database would be as fast as such caching solutions, except if by caching you meant we chose to cache the values in our program, which should be faster, but update would still be more difficult by having to do cache invalidations for each servers.
Thank you for the video. 💯👍
Im sure it was ask multiple times before, but can you share how the "draw line with the mouse thingy" is called?
Thank you so much
How you handle the security of feature flags when it comes to RLS with something like Supabase for example? Seems like it’d be a pain
just one question here, if the feature flag assignment is random to 25% user. then is it possibble that today if i login i get the feature bbut tomorrow I wont?
Crazy good video
Having it in Code is simply another way of saying you need to do a deployment to propagate changes(or a server restart if its on server)
What’s that app you are using for the diagrams? Looks really nice.
Excalidraw
Thanks!
I suppose the only issue is if these are exposed to the user. Hiding sensitive pre release features would need to be done carefully (so caution is required) so ensuring these are serverside only is important. I use feature flags all the time to ramp up new features to a subset of customers for slow dialup, which is invaluable. Yay feature flags! 😂
Excellent tutorial Kyle! I’ve taken the approach in my project of assigning a logged in user to a bucket preemptively, right after login (having 100 buckets). This is just like yours, deterministic and it’s calculated just once, so that checks are userBucket
We have launchdarkly and splitio, we cache the flag data responses into session storage, is that a good practice?
Sure
Depends on what you want the behaviour to be like. Assuming the front checks if the session storage key is set on every page load, and makes a request to the relevant endpoint if it can't find it, that means that tab will only make one request as long as it's open. If the data becomes stale, then there's no practical way to update it and you will have to wait for the user to close that tab and open a new one. Also, note that session storage data is not shared between tabs. If that's the behaviour you expect, then you're good, otherwise, you might want to look into localStorage or session cookies.
This has some issues that may or may not be problems for you depending on where you are storing your session. If you are using the browsers session storage then every time someone comes to your page for the first time they will have no data in the cache. If you are using a server based session storage then it depends on how long that data is persisted and would work very similar to a normal caching system if the data is persisted long term.
If you do some polling / new request every minute or so it might be sufficient for you to refresh your session storage
Do a mix of Code, Env and Database. Code for something that needs quick changes from DEVs but can wait a month or three for deployment. Env for something that is not critical and hardly ever needs changed. Database/SaaS for most things including % of users and extremely for critical.
Instead of adding a new import (unless using it in other places) could have written a simple hash yourself.
simpleHash(str) {
hash = 0
for(let i=0; i < str.len; i++) {
const char = str.charCodeAt(i);
hash = (hash
Ok, Kyle, but where do i keep the app cache? Sorry i am a new to using cache lets day in React or Nextjs
You could store it in Redis for example. Also, Next.js has its own cache that you could use.
In my project, I want to implement a feature to disable advanced analytics not only on the frontend but also on the backend. The goal is that when advanced analytics are disabled, no analytics data is collected, and the backend service responsible for analytics won't incur charges. How can I implement this configuration so it ensures analytics are fully disabled across both frontend and backend, preventing any data collection or charges?
if its a hosted / serverless container its very easy and fast to change an env var
wouldnt u do feature flags in the backend server?
I would love to know on the mobile app perspectives
The main problem with feature toggles is that they usually stay in the code forever and even after some time they got broken by other features. Yes, the clean code, principles, and all. But reality is that in small project, you don't need them, in a big project they eventually get broken... And don't forget that testing is ultimatelly impossible with the amount of all of combinations of turning features on, and off respectively.
I'd say this laregly depends on the culture of the team you work with and generally how prone to tech dept it is. In our team for instance this has never been a problem, really. We mostly use feature flags to AB test though, but I can imagine also making use of it in the ways described in this video without much sacrifice or risk of them getting stale / broken anytime soon. My case is a rather compact product I'd say, but with quite a lot of traffic, so deploying something as a canary test gives us as a team much more confidence.
What's wrong with leaving them in code forever? It allows you to roll out an update to a feature or remove an older feature that is no longer being supported. I see no downside to keeping them.
"in a big project they eventually get broken," then you have a broken QA process. I don't see how they would become "broken."
"And don't forget that testing is ultimatelly (sic) impossible with the amount of all of combinations of turning features on, and off respectively." That's absolutely false, especially with automated testing.
There is a flaw in this implementation if you want to use it for AB testing. Since the same user might end up with multiple features you will not be able to say which feature caused your users to behave differently. Also you are going to have dirty control groups with random features enabled.
You can with statistics. Tjis is Quote common to habe multiple experiments in larger organisations
For production grade implementation of this you can use CASL library.
any thoughts about unleash?
I might be confused but if someone reverse engineers your app, can't they just make themselves an admin or tester user?
Realy excellent tutorial, and a real leap for any junior developer straight into senior territory. The only thing I would add after working in several big companies with a large set of feature flags - whenever you go for feature flag structures that are not simple booleans, like the structures showed in this video, I'd REALLY recommend that you choose standard feature flag structures. Because you need to remember that every feature flag has a non-technical user that will need to set it. And non-standard feature flags that have an ad-hoc structure will be hard to render with a simple UI for the non-technical product teams that will be using it, and you'll find yourself resorting to a non-structured text editor for editing feature toggle JSONs. This is extremely flakey and will result in a loooooot of weird production issues. Use a set of predefined feature toggle structures, and extend it only if needed. Even if you're building your project alone.
Why we need to re-deploy whole app when we change env variable?
If you don't redeploy your app will not get the new updated env variable.
@@WebDevSimplified Is that true even if I host my app on Heroku and just do restart of the server as the env variables are set in the dashboard?
I guess redeploy was the wrong word for me to use. What I meant is your application needs to restart and possibly rebuild itself which takes time.
@@WebDevSimplified Thanks
Database implementation is easy, just have it part of user class, and config class.
Database request speed for user tied flags is essentially free, you will be querying the user each request anyway... You may also be checking config, but 1 extra simple request per page isn't going to impact your speed by any perceptible difference.
Env variable update speed is fast, at least hosting PHP on Laravel Forge, I can instantly update environment, and it can be done via API also. Database isn't any faster to update.
Tell me why oh why can't you store user percentages in environment??????
You kinda mixed up feature flag and shadow traffic in my opinion when it comes to fetching data in 2 different ways. I would probably count that as shadow traffic
Funny I just built a component using Laravel Pennant that allows me to load a GUI in an admin panel based on user roles and routing. I use ReactJS for my frontend and Laravel for my backend. Maybe I was searching for ideas about Feature Flags and then this video showed up in my timeline. Hmmmm
Looks like the user can bypass the security using this if you manipulate the feature values using the console for example. Is there any secure way to implement this?
In this particular code I am using Next.js and server rendering the code behind the feature flag. This means if the feature is not enabled for the user the code behind the feature will never even get sent to the client.
@@WebDevSimplified But this works only in case of server side rendering, not? So If I do client side, I can't really use this featureFlags, right?
I would potentially distinguish between backend feature flags and frontend ones. Frontend feature flag as in a static deployment can only be updated when you deploy new versions of those files AND the user refreshes those files. There are easier and more complicated ways (service worker) to have the browser refresh sort of automagically, or at least prompt the user to do so. I would say if you have a SPA, make sure at least these FFs aren’t meant to be kill switch, but rather for phased roll outs etc
so u actually test your queries? i deploy them and let the users do it for us XD
Could you please create a Project by watching and checking it with a Figma file having any design and upload that video to this channel so that we learn & get benefits?
We need to learn the strategy to complete a project quickly through Figma.
I just have one question. how does the percentage of users knows how many users my app has? I can ser it to .5 today. and in 5 days my userbase has grown lets say another million users. how does it know the total amonut of users?
It doesn't matter how many users your app has. The algorithm doesn't use that information. All it does is convert the user's ID into a percentage (0-100%). This percentage is then checked against the threshold for the feature you set. This means the amount of users that see your feature should be close to the percent you set. With a smaller number of users it will be less accurate. This is because even though the hashing algorithm is evenly distributed if you only have 100 users it is pretty unlikely they will be perfectly distributed with 1 user in each percentage range. With thousands or millions of users, though, this problem goes away as the likelihood of the randomness placing a significantly larger number of people in one particular range is miniscule.
Wait, why would you need to redeploy your code when you change your env variables? @10:28
I really hope your .env is ALWAYS part of your .gitignore... you DON'T deploy environment variables. It completely negates the purpose of them being dependant on your ENVIRONMENT, which differs for everyone pushing or pulling from that repository.
Also you obviously cannot only store true/false, you can store any string you want. It is limited if you need arrays or whatever though.
Building a killswitch. Caching a killswitch 🧐🤔
poetry!
Why would a database query be slow??? Using an index would be almost instant.
Any database operation is incredibly slow compared to a cache since often the database is hosted somewhere other than the application which requires a network request. Even if it is hosted in the same place it is still slower than a cache and if you have to make 5 feature flag requests on each page that adds overhead to your request which is not ideal.
You can request all feature flags in 1 statement, hence one single request.
Hey, Kayal can you build an extension based software. Where can I build an application and extend it with an extension. Just like a VS code or wordpress.
Start with architecture design and the coding.
It's new for mid level and senior developers.
99% of the time… it works every time
It costs almost no code and complexity to implement a FeatureManager, and you're not a dumb-dumb it costs zero network requests. This would be obvious if we hadn't all collectively decided to never ever use singletons or globals (even when the scope of an operation is actually global.)
This works for web, for React Native, it wont. You need a way to request the object and update these on global state.
15:58 Bro, what on earth is this? FrontEnd doesn't include any of these things you're explaining here. This is a 100% Business Logic that belongs to the API in BackEnd.
FrontEnd is just a User Interface to work with the main software (API)
🎉🎉
Who on earth creates a GA tag that allows you to buy stuff for free 😂
👀
Good vid. But it's sooooo hard to concentrate on the material while you are shaking your head that much all the time that in many cases I just stop watching a video... Please... Pleeeease stop doing that or make circle from your camera at least twice smaller... Please, I really do appreciate the content and effort you put in it. But this tiny thing ruins a lot.
Helloo
Shouldn't you be a senior dev first?
Sorry champ, you can tell you have no commercial experience. Please be honest about your gap of experience in your videos.
I do have experience across companies as small as
@WebDevSimplified just being honest, suggest you do the same. It would suggest you don't have experience as a lead developer in a large company. Your content is very green. I think you already know this. I am just asking you yo be upfront about it.
I have been the lead dev on projects before. I definitley don't have as much experience as many people but I never claim to be an all knowing developer with decades of experience.
If there is something about my code or presentation that you think is wrong I would love to know. Most if my content is targeted towards more beginner developers so it is going to lean more towards beginner and "green" implementations.
@WebDevSimplified I would suggest being upfront about your limited commercial experience. I can see why it is attractive to beginners, but it doesn't tell a real story, if you want more honest channel call it what is, not an example of how this would be used on a commercial project otherwise it is a false economy. I get it, you are young, and these distinctions aren't immediately obvious, but just be honest, and the rest will flow.
It sounds like you have no issue with the content I am producing and the only issue is with my age. That is fine. I have over a decade of experience in web development and have worked with many companies across different verticals, sizes, and scales. I obviously don't have the same experience as someone that has been programming since the 80s, but I do have enough commercial, enterprise, and start up experience to make content talking about topics related to them.