@@WebDevCody In the video, you say that when the feature flag is OFF, the endpoints are disabled and can't be used. Isn't that the same as "protect the route"?
Great vid! We use decorators or middleware for endpoints rather than wrapping in if statements. We use redis for storage of them. We have two kinds of feature flags. Global, stuff for site wide admins and user ones. Maybe when we get more users we’lol even do percentage of people for x time get to do things. Anyways I’ll stop rambling on now
If you have authorisation built into your app, it’s always better to model feature flags as assignable permissions. E.g “Can user do X” or “Can user see Y”. These can be assigned either directly to the user or to a group which a user can be assigned to. These permissions. Could be backed by configuration if necessary, but I have a suspicion that feature flags should generally not exists in configuration as it usually requires a server restart to take effect, where as permission based feature flags work in real time. I call this: promoting configuration to application run-time.
We do it in code, ours requires a redeploy but some values we can adjust in cookies if we allow them. Makes it nice for testing. Also less database requets when you have 100 feature flags adds up
I would be interested to see a video exploring the pseudo seeder function that computes based on user id. I think that might be quite performant, curious to see how you would go on implementing something like this
One idea I just had, instead of using a hash to enable the feature for a small percentage of users, you could have some analytics tool set up that tracks how users use your app, and with that you could enable the feature only for the users who use your app frequently, because it's less critical if a loyal user sees a bug than if a new user does. Of course this is only useful for larger apps who have a large user base and not for sass products that are just starting like your app
great value as always. I happened to be using the .env approach as a feature flag at work but it's starting to accumulate with multiple flags, also when I want to change something I'll have to contact the guys with the access to prod which is never fun. When I get some time I'll do database based flags with a /flags page to toggle things around. But I don't want to query flags for every request so I'll cache the config on CRUDS and toggles for better performance.
Great video , I always wanted to implement feature flags into my apps but didn't know how , I would like you to make a video in more details explaining and implementing feature flags maybe with a table in db instead of env variables , really like your videos
We have a vault to store feature flags apart from other things. We toggle features which works fine in backend but in order to reflect it in frontend, user has to manually refresh the page to get the new values of feature flags. Is there some logic to avoid needing a refresh to detect new changes like you showed in your video?
How would you suggest implementing on a static nextjs site with 1Mn+ page req / month? My current solution requires rebuild with env variables but I wonder if there's a better way!
What are you trying to flag? Sometimes you might just want to fetch the flags once when the user first hits your ui. If it’s critical they need the feature turned on or off the moment you flip the flag you’d need polling or web sockets. If the feature is around statically built routes, idk if you could do anything without redeploying
Considering that you use a macbook for programming, do you have any advice on how to extend battery life due to frequent charging. Do you put it on the charger and turn on the program to block the charging of the battery, but to work directly from the charger
The CEO of LaunchDarkly had a good talk--Patterns & Anti-Patterns for Effective Feature Flagging • Edith Harbaugh • YOW! 2019-- about some patterns/anti-patterns for using feature flags/toggling.
I think feature flags are a sort of example of positive technical debt. They allow you to get code out much faster, respond to issues better and more timely. The cost is that they have to be maintained and deprecated. The tradeoff is often worth it though.
you should remove the flags and branch logic after you've verified the feature is good or not. If you leave it in for a year, you're team needs to re-address how to refactor code.
I just like to push 100+ files... because no one care about anything, just push changes day and night, and when u wake the next day nothing make sense, and they like new changes
Make sure you also protect the route the feature flag is going to (people can still go to generate/bulk-generate)
Yeah, good point. I probably forgot about that
@@WebDevCody In the video, you say that when the feature flag is OFF, the endpoints are disabled and can't be used. Isn't that the same as "protect the route"?
Yeah they will be able to access the page through the route but they won’t be able to use any of the logic because the endpoints will throw errors
@@mykalimba route isn’t the same as api. You should protect both, but the api is the actual important one, the other is a UX concern
Great vid! We use decorators or middleware for endpoints rather than wrapping in if statements. We use redis for storage of them. We have two kinds of feature flags. Global, stuff for site wide admins and user ones. Maybe when we get more users we’lol even do percentage of people for x time get to do things.
Anyways I’ll stop rambling on now
I actually use this too in my work, didn't know it was called Feature Flags.
If you have authorisation built into your app, it’s always better to model feature flags as assignable permissions. E.g “Can user do X” or “Can user see Y”. These can be assigned either directly to the user or to a group which a user can be assigned to. These permissions. Could be backed by configuration if necessary, but I have a suspicion that feature flags should generally not exists in configuration as it usually requires a server restart to take effect, where as permission based feature flags work in real time. I call this: promoting configuration to application run-time.
Thank you! Pretty clear and nice info
We do it in code, ours requires a redeploy but some values we can adjust in cookies if we allow them. Makes it nice for testing. Also less database requets when you have 100 feature flags adds up
I would be interested to see a video exploring the pseudo seeder function that computes based on user id. I think that might be quite performant, curious to see how you would go on implementing something like this
One idea I just had, instead of using a hash to enable the feature for a small percentage of users, you could have some analytics tool set up that tracks how users use your app, and with that you could enable the feature only for the users who use your app frequently, because it's less critical if a loyal user sees a bug than if a new user does. Of course this is only useful for larger apps who have a large user base and not for sass products that are just starting like your app
great value as always.
I happened to be using the .env approach as a feature flag at work but it's starting to accumulate with multiple flags, also when I want to change something I'll have to contact the guys with the access to prod which is never fun.
When I get some time I'll do database based flags with a /flags page to toggle things around.
But I don't want to query flags for every request so I'll cache the config on CRUDS and toggles for better performance.
Great video , I always wanted to implement feature flags into my apps but didn't know how , I would like you to make a video in more details explaining and implementing feature flags maybe with a table in db instead of env variables , really like your videos
We have a vault to store feature flags apart from other things. We toggle features which works fine in backend but in order to reflect it in frontend, user has to manually refresh the page to get the new values of feature flags.
Is there some logic to avoid needing a refresh to detect new changes like you showed in your video?
First! I love you! You’re doing great!
You're the best!
Damn even members can’t be first anymore 😭
How would you suggest implementing on a static nextjs site with 1Mn+ page req / month? My current solution requires rebuild with env variables but I wonder if there's a better way!
What are you trying to flag? Sometimes you might just want to fetch the flags once when the user first hits your ui. If it’s critical they need the feature turned on or off the moment you flip the flag you’d need polling or web sockets. If the feature is around statically built routes, idk if you could do anything without redeploying
Considering that you use a macbook for programming, do you have any advice on how to extend battery life due to frequent charging. Do you put it on the charger and turn on the program to block the charging of the battery, but to work directly from the charger
I don’t do anything special, I just charge it to full then use it until near red, then charge it till full
Feature Flag can cause dead code if your team don't have good management process, especially in big team
The CEO of LaunchDarkly had a good talk--Patterns & Anti-Patterns for Effective Feature Flagging • Edith Harbaugh • YOW! 2019-- about some patterns/anti-patterns for using feature flags/toggling.
Thank you so much
1:02 which feature should I enabled on Mac to do that action? also what hotkey
I have it on cmd + shift +4, i thinks it's the default but not sure
We use unleash for our featureflags and it's a really good service
Yeah Unleash is really good
I think feature flags are a sort of example of positive technical debt. They allow you to get code out much faster, respond to issues better and more timely. The cost is that they have to be maintained and deprecated. The tradeoff is often worth it though.
you should remove the flags and branch logic after you've verified the feature is good or not. If you leave it in for a year, you're team needs to re-address how to refactor code.
@@WebDevCody yeah agreed
Which VScode theme are you using?
Bearded theme feat web dev cody
how the env variables reflect to live website like that :O
Because convex is based
Cool!
I just like to push 100+ files... because no one care about anything, just push changes day and night, and when u wake the next day nothing make sense, and they like new changes
"You can use third party service if you are that type of developer" neat way to insult someone
Do you feel attacked? I’m using a third party service for my entire backend
I want a tester role ;) ha
I got you
Second - you're doing great!
lol
ai slop dev
slop hard baby
Youre too good looking for coding bud, pick another career
Wait till they find my only fans