Something I've noticed is that there's a distinction between short lived feature flags that are used as part of the CI/CD process to keep master stable and feature flags that determine which features a customer has access to, like product tiers. The CI/CD flags are temporary and need to be cleaned up quickly to reduce tech debt When people confuse the two it can lead to problems

@Jeggettmega

Ай бұрын

CI/CD flags are the ones you usually set via env variables?

With some features touching many files (Validator, UI, Service Logic, and Controllers); introducing a feature toggle can be non-trivial. I am considering deploying the new feature without a toggle to a staging server and directing small portions of traffic to the staging server until all users are then using the new feature. Similar to A/B testing and routing traffic to the newer deployment of the app.

Agree I've been in the situation where too many feature flags were disabled but they still exist in code, another kind of tech debt was created I guess

Hi. I don't remember if there was a video regarding using DDD in a legacy code, but I wonder how can we jump into legacy project with huge amount of sub-projects and 15 years dependency chain and impement a DDD (with or without CQRS or Event Sourcing). Is there a way how can we define our aggregates and bounding context and pass this smoothly? Or should we throw that idea and do as it always was done all this time before (by making yet another patch/workaround)?

They definitely are! (more than just Toggle that is!)

Just implemented a feature toggle to evaluate two different dates when calculating account expiration dates. Super handy as the feature will only be in our domestic deployment and not our international deployment.

I am currently implementing a custom feature flaging system with dynamic json editor front-end management that syncs the values from db and dynamically caches them for usage, so that the application admins has full access to rollout period and parameters. The most usefull thing that no stakeholder or product owner ever gonna think. Every tech lead in major enterprise workflow should push for a sprint like that.

Doesn't it become a centralised config store at that point? The lines are blurring.

@Jambajakumba

3 ай бұрын

yeah exactly

Amazing channel, thank you. We need a video about authentication and advanced authroization in a microservices event driven architecture please.

@spicynoodle7419

3 ай бұрын

Authentication seems straightforward, you only do it once on the backend for frontend. Authorization probably needs to be handled by each domain for itself

@juststudying1019

3 ай бұрын

@@spicynoodle7419 yep authentication is simple, I have advanced access control Role based and attribute based and access control depending on time, how handling it in each domain will be better ? I thought of a single domain and each service will call that service but it will be slow but i will add cashing even though i think it is not the best idea. And if i will make it as a seperate service absolutely i will not call it via events because i want it to be synchronous so is it best practice to do that in an event driven architecture? Any thoughts on that? I am new to the world of microservices

@CodeOpinion

3 ай бұрын

Authorization is a good suggestion.

Hey Derek, what do you think of services like LaunchDarkly? It's a great UI with many features for managing feature flags with reactive SDKs for consuming the feature flags, but maybe it isn't the right move to add the outside service dependency for any business critical logic.

@CodeOpinion

3 ай бұрын

It's an interesting problem. I think with any vendor, you kind of have a couple options. One is jump all in and really leverage it to maximize your use of it to really make your system better. Or two, abstract it so you can easily remove it but often losing a lot of the value.

@featbit

3 ай бұрын

Hi, my name is FeatBit, it's open source and designed to help people self-host on their own systems. The major difference between me and others is: I highly recommend myself to provide technical support, enabling teams to build their own needed features based on what I offer, and maintain consistency with FeatBit's upgrades."

testing is a nightmare!

I don't think long-term toggles should be called Feature-Flags. The problem is that if you have a feature-flag in the system, then during testing you'll need to check all combination to ensure that your system works as expected. If a flag in production never changes it's value after a rollout, then said flag needs to be removed. Then you end up having these nested dependencies that flag X only works if feature Y is on etc. #IMO it's a lot cleaner if one doesn't mix short lived feature flags with long term values for configuration. So if different deployments support different caches (to stick with the example) then said cache should be configured via a different source then feature flags. (Also if a feature gets released and needs to be supported in the long run, then said flag should be migrated over to this other location) Also long term configs tent to resemble a hierarchy while short lived flags are usually flat. I've seen deployments with 680+ feature flags still in the system. Now good luck testing that...

First of all, this is a really good channel. I've subscribed to it and enjoyed many vids here. Secondly, I think it's worth pointing out that there are also other ways to improve on his approach by utilizing better code design. As he says, in their basic and "naive" form, feature flags can be seen as (1) "if/else" conditions in the application with (2) an effective way to specify which conditional path to go by means of some kind of configuration elsewhere. Now, "if/else" conditions have implications on CNN and OCP: CNN: Every additional condition in your code adds to the CNN (Cyclomatic Complexity Number), i.e. your code will be MEASURABLY more complex. OCP: If you have to change the existing code to insert the feature flag conditional then you're violating the OCP (Open Closed Principle which is the "O" in S.O.L.I.D.). Therefore I try other techniques first and insert conditionals only if I have no other realistic option: 1) One of his examples is a feature flag to turn on/off a cache or select which cache to use. Caches are a textbook example of the DECORATOR pattern. This allows to wrap the data provider transparently into a surrounding implementation which can then function as a cache. No implementation code needs to be changed for this to happen. The only thing left to do is the configuration part. There you MIGHT need a conditional for the factory that wraps one into the other. However, you may also leverage your Dependency Injection (DI) container or use annotations and/or AOP tooling for this. 2) Another way to create a feature flag would be to use good old polymorphism. Your feature is then a new implementation of the "thing" it is being swapped for. If, instead, your feature is not REPLACING anything existing but is ADDITIONAL functionality then put the functionalities (old and new) into a list and iterate over the list. The configuration will decide whether to put the new feature in or not, which makes it, in effect, a feature flag toggle. The rest is how you configure which implementation is to be used where or added to the list of features. This is typically the job of a DI container or similar mechanisms. (I think Derek is kind of thinking this direction in his second example about the "tenant". However, his example still interprets a boolean to change the app's behavior. My approach on the other hand specifies the concrete implementation class to be used or not, i.e. the is no need to interpret anything thus keeping the CNN from growing.) Sometimes, this requires existing code to be refactored first so that the pieces can be separated by polymorphic implementations. If the effort and/or risk for this effort is too high I do admit that we may end up with the traditional if/else conditionals instead.