Flexible Feature Control at Instagram
engineering.instagram.com
Flexible Feature Control at Instagram
1–10 of 12 posts
Re: Flexible Feature Control at Instagram
#2I was part of the team that designed this. AMA.
Re: Flexible Feature Control at Instagram
#3I was part of the team that designed this. AMA.
What did you have for breakfast?
Re: Flexible Feature Control at Instagram
#4I was part of the team that designed this. AMA.
what advice would you give to someone who would be looking to implement this in a less dynamic language such as C# or Java? In your opinion is this only successful due to the dynamic and special language features of Python?
Re: Flexible Feature Control at Instagram
#5I was part of the team that designed this. AMA.
How does this work in a developers local environment? Does it hook into the same central service or do you need re-define the gate in all environments?
Re: Flexible Feature Control at Instagram
#6Ah, I was hoping it was about their iOS or Android app.
Re: Flexible Feature Control at Instagram
#7I was part of the team that designed this. AMA.
I'm not clear from the post, is this used only to gate features in servers or is this used to gate features in the mobile clients as well? If it's used in the mobile clients, how is that done (in particular, checking looks to be synchronous, but would obviously need to be async to work)
Re: Flexible Feature Control at Instagram
#8I was part of the team that designed this. AMA.
How does this work in a developers local environment? Does it hook into the same central service or do you need re-define the gate in all environments?
At Instagram we have split dev and prod enviroments; gates are shared between dev-servers, but split from production.
For testing, we have context managers that let you do "with temporary_gate('gate_name', value)", so there's not much boilerplate in overriding/testing your code within a gate constraint.
Re: Flexible Feature Control at Instagram
#9I was part of the team that designed this. AMA.
I'm not clear from the post, is this used only to gate features in servers or is this used to gate features in the mobile clients as well? If it's used in the mobile clients, how is that done (in particular, checking looks to be synchronous, but would obviously need to be async to work)
This is primarily a server-gating feature. For the mobile clients, they periodically sync their experiment flags state using a call to the backend (eg at app start), which is handled using a related, but separate, system to Gate Logic.
Re: Flexible Feature Control at Instagram
#10I was part of the team that designed this. AMA.
The systems that I've seen of this nature have been rules-based, like this:
if A allow, else continue to next rule
if B deny, else continue to next rule
if C allow, else continue to next rule
deny all
For example, ufw rules have that form.
I see a few advantages compared to Boolean operators:
1. Easier to diff and version control.
2. Easier to build UI for, for example, to show which rule fails for a particular user.
3. Simpler to implement, no recursion in the DSL.
4. Arguably simpler to use.
5. Immediately obvious how short-circuiting works.
Why did you choose to go with Boolean operators rather than rules?