I'm absolutely loving this "Like a Senior Dev" series, it feels like these architecture patterns are rarely talked about.
@KingInternetEnjoyer28 күн бұрын
Literally just got a ticket to add a flag around a new analytics feature yesterday lol your channel speaks to me man 😂 great tips!
@remi-avec-un-i29 күн бұрын
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
@WebDevSimplified29 күн бұрын
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)
@lifeisfakenews29 күн бұрын
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
@0xDEAD_Inside29 күн бұрын
@@lifeisfakenews And that's why you put a timeout on the cache invalidation.
@mikelinde526729 күн бұрын
@@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.
@WebDevSimplified29 күн бұрын
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.
@FilipeBento-me29 күн бұрын
If you decide to cache it, the TTL needs to be inversely proportional to the request rate and how critical the feature is.
@WebDevSimplified29 күн бұрын
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.
@fluentai-extension15 күн бұрын
@@WebDevSimplified how would you do that ? By requesting changes on each new session for instance ?
@Volodymyr-y1c4 күн бұрын
@@fluentai-extension you're not caching them client-side, therefore whenever you change something you just clear the cache.
@jaaq129229 күн бұрын
excactly one of the things i'm implementing for the first time at work atm - cheers mate!
@sandrodezerio525329 күн бұрын
Amazing content Kyle, the concepts that you explain and the importance of them as well, keep doing it please. thanks for sharing your knowledge !
@MohamedAdelQuickDeveloper29 күн бұрын
Keep up the brilliant work. 👏Really enjoyed this video and would love to see more about concepts and architectures.
@TechWithCaleb29 күн бұрын
I really like these concept Kyle. Please keep going !
@taksuyu28 күн бұрын
Really love the breakdown and would like to see more of these!
@jfftck29 күн бұрын
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.
@PeeledBanana-c8i13 күн бұрын
Love it. And just for anyone curious: Unleash.
@rivershertz596729 күн бұрын
Kyle - I love love love these deep dives, I find them so valuable! Thank you so much!
@John-eq5cd29 күн бұрын
Thanks for providing the github link, it helps understanding a lot to be able to read it through
@futhedude484827 күн бұрын
Well explanation, especially the database stuff at 8:35, never know we could do that.
@robertphillips12471429 күн бұрын
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.
@davidentzat567128 күн бұрын
Thanks for the explanation. I would like , please, more videos about this subject.
@DjCtavia10 күн бұрын
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!
@drfranca19852 күн бұрын
The hash thing is just genius
@nage744714 күн бұрын
love that you started make more depth content )
@sitedel29 күн бұрын
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.
@AntiAtheismIsUnstoppable28 күн бұрын
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.
@AntiAtheismIsUnstoppable28 күн бұрын
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.
@sitedel21 күн бұрын
@@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.
@mortenthomsen122 күн бұрын
Your videos are awesome, man! Keep it up!
@Hellowellozello29 күн бұрын
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.
@vincent_sz29 күн бұрын
You can with statistics. Tjis is Quote common to habe multiple experiments in larger organisations
@d4v3w27 күн бұрын
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! 😂
@tonyrogers710129 күн бұрын
GREAT stuff. Please do more like this!
@jiayu030728 күн бұрын
Are you the encyclopedia of web development? 🤩I love this video, thank you for your careful explanation.🥰
@cfmanooo29 күн бұрын
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.
@dmnkb29 күн бұрын
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.
@SeansAnthology29 күн бұрын
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.
@bgu.60420 күн бұрын
Thanks for the video, I like this approach around fundamental concepts of software architecture
@AzureRoki21 күн бұрын
I was told once in interview that feature flag is nothing related to A/B testing. Dang, he should come to watch Kyle's channel.
@jasonennis490529 күн бұрын
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
@miervaldis4229 күн бұрын
I wanted to implement feature flags for a long time but did not manage to find a suitable tutorial for beginners
@rogerpetruki475929 күн бұрын
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.
@Vlad199899622 күн бұрын
that a great way to test things. Thank you for such videos.
@AnindoSarker29 күн бұрын
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
@philadams925429 күн бұрын
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.
@technovelodos29 күн бұрын
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).
@deatho0ne58728 күн бұрын
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
@vincent_sz29 күн бұрын
Great Video. Add unleash to your comparison and everything is green :-D
@bentoth432429 күн бұрын
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.)
@jaya_surya19 күн бұрын
Thanks
@WebDevSimplified2 күн бұрын
You are very welcome!
@kasvith18 күн бұрын
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)
@rendezone29 күн бұрын
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
@edwarda709629 күн бұрын
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
@B0re_d23 күн бұрын
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
@hamburger--fries17 күн бұрын
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
@RobHuzzey29 күн бұрын
What’s that app you are using for the diagrams? Looks really nice.
@WebDevSimplified29 күн бұрын
Excalidraw
@raphauy28 күн бұрын
Very helpful, thank you!
@sajidrsheikh29 күн бұрын
For production grade implementation of this you can use CASL library.
@jaydeep-p29 күн бұрын
We have launchdarkly and splitio, we cache the flag data responses into session storage, is that a good practice?
@philipfisher885329 күн бұрын
Sure
@parlor311529 күн бұрын
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.
@WebDevSimplified29 күн бұрын
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.
@rendezone29 күн бұрын
If you do some polling / new request every minute or so it might be sufficient for you to refresh your session storage
@AvihuTurzion29 күн бұрын
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.
@xeridea25 күн бұрын
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??????
@tomich2029 күн бұрын
so u actually test your queries? i deploy them and let the users do it for us XD
@BennyAlex9826 күн бұрын
if its a hosted / serverless container its very easy and fast to change an env var
@dileepa-mn2to26 күн бұрын
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?
@AlekVila29 күн бұрын
Damn! This is a great one.
@EmīlsLaganovskis28 күн бұрын
Thank you for the video. 💯👍
@TheDuckPox29 күн бұрын
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.
@aarsdruiper300028 күн бұрын
Crazy good video
@palandrascsokan63829 күн бұрын
Ok, Kyle, but where do i keep the app cache? Sorry i am a new to using cache lets day in React or Nextjs
@WebDevSimplified29 күн бұрын
You could store it in Redis for example. Also, Next.js has its own cache that you could use.
@bastien498529 күн бұрын
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
@Gabriel_Wangai20 күн бұрын
I might be confused but if someone reverse engineers your app, can't they just make themselves an admin or tester user?
@harmoniapositiva29 күн бұрын
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?
@WebDevSimplified29 күн бұрын
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.
@1998TheMisi29 күн бұрын
@@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?
@rendezone29 күн бұрын
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
@PramathKelkar28 күн бұрын
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?
@SkiLLFace36029 күн бұрын
Im sure it was ask multiple times before, but can you share how the "draw line with the mouse thingy" is called?
@ajiteshmishra00059 күн бұрын
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.
@aymenbachiri-yh2hd29 күн бұрын
Thank you so much
@jareddiscipio176829 күн бұрын
99% of the time… it works every time
@benediktmathes252810 күн бұрын
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.
@srdjagunjic29 күн бұрын
Why we need to re-deploy whole app when we change env variable?
@WebDevSimplified29 күн бұрын
If you don't redeploy your app will not get the new updated env variable.
@srdjagunjic29 күн бұрын
@@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?
@WebDevSimplified29 күн бұрын
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.
@srdjagunjic29 күн бұрын
@@WebDevSimplified Thanks
@bit-0_40422 күн бұрын
poetry!
@anthonypetruzzi15829 күн бұрын
Why would a database query be slow??? Using an index would be almost instant.
@WebDevSimplified29 күн бұрын
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.
@rendezone29 күн бұрын
You can request all feature flags in 1 statement, hence one single request.
@SinaSoltani-tf8zo24 күн бұрын
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)
@DarioCooks27 күн бұрын
Building a killswitch. Caching a killswitch 🧐🤔
@carlosdubon853927 күн бұрын
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?
@WebDevSimplified27 күн бұрын
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.
@RishiRajxtrim29 күн бұрын
🎉🎉
@specialhitgamingtv297122 күн бұрын
any thoughts about unleash?
@catofdeepblack18 сағат бұрын
Shouldn't you be a senior dev first?
@joe0hill29 күн бұрын
Who on earth creates a GA tag that allows you to buy stuff for free 😂
@LeGatoDarko24 күн бұрын
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.
@0xtz_29 күн бұрын
👀
@singh.aadarsh29 күн бұрын
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.
@rockenOne28 күн бұрын
Sorry champ, you can tell you have no commercial experience. Please be honest about your gap of experience in your videos.
@WebDevSimplified28 күн бұрын
I do have experience across companies as small as
@rockenOne28 күн бұрын
@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.
@WebDevSimplified28 күн бұрын
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.
@rockenOne28 күн бұрын
@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.
@WebDevSimplified28 күн бұрын
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.