aboutsummaryrefslogtreecommitdiff
path: root/_articles/2020-10-19-feature-flags-differences-between-backend-frontend-and-mobile.md
diff options
context:
space:
mode:
authorEuAndreh <eu@euandre.org>2020-11-03 15:35:49 -0300
committerEuAndreh <eu@euandre.org>2020-11-03 15:35:49 -0300
commit72e76d56ce5092b2d3bd3068c97f474647df93bf (patch)
tree484847db0e91cc492347eaee47e6402cf8f0880d /_articles/2020-10-19-feature-flags-differences-between-backend-frontend-and-mobile.md
parentMove other Nix files to nix/ (diff)
downloadeuandre.org-72e76d56ce5092b2d3bd3068c97f474647df93bf.tar.gz
euandre.org-72e76d56ce5092b2d3bd3068c97f474647df93bf.tar.xz
Feature flag article: start rewriting to make it more user friendly
Diffstat (limited to '_articles/2020-10-19-feature-flags-differences-between-backend-frontend-and-mobile.md')
-rw-r--r--_articles/2020-10-19-feature-flags-differences-between-backend-frontend-and-mobile.md83
1 files changed, 69 insertions, 14 deletions
diff --git a/_articles/2020-10-19-feature-flags-differences-between-backend-frontend-and-mobile.md b/_articles/2020-10-19-feature-flags-differences-between-backend-frontend-and-mobile.md
index 74d4e15..49b8dd3 100644
--- a/_articles/2020-10-19-feature-flags-differences-between-backend-frontend-and-mobile.md
+++ b/_articles/2020-10-19-feature-flags-differences-between-backend-frontend-and-mobile.md
@@ -1,6 +1,7 @@
---
title: "Feature flags: differences between backend, frontend and mobile"
date: 2020-10-19
+updated_at: 2020-11-03
layout: post
lang: en
ref: feature-flags-differences-between-backend-frontend-and-mobile
@@ -10,13 +11,20 @@ category: presentation
*This article is derived from a [presentation][presentation] on the same
subject.*
-When talking about [feature flags][feature-flags-article], I find that their
-costs and benefits are often well exposed and addressed. However the weight of those
-costs and benefits apply differently on backend, frontend or mobile, and those
-differences aren't covered.
+When discussing about feature flags, I find that their
+costs and benefits are often well exposed and addressed. Online articles like
+"[Feature Toggle (aka Feature Flags)][feature-flags-article]" do a great job of
+explaining them in detail, giving great general guidance of how to apply
+techniques to adopt it.
-I'll try to make this distinction clear, with some final best practices I've
-acquired when using them in production.
+However the weight of those costs and benefits apply differently on backend,
+frontend or mobile, and those differences aren't covered. In fact, many of them
+stop making sense, or the decision of adopting a feature flag or not may change
+depending on the environment.
+
+In this article I try to make the distinction between environments and how
+ feature flags apply to them, with some final best practices I've acquired when
+ using them in production.
[presentation]: {% link _slides/2020-10-19-rollout-feature-flag-experiment-operational-toggle.slides %}
[feature-flags-article]: https://martinfowler.com/articles/feature-toggles.html
@@ -32,12 +40,40 @@ Feature flags in general tend to be cited on the context of
> A: With techniques like canary, monitoring and alarms, feature flags, *etc.*
-Even though adopting continuous deployment doesn't force you to use feature
+Though adopting continuous deployment doesn't force you to use feature
flags, it creates a demand for it. The inverse is also true: using feature flags
-on the code points you more obviously to continuous deployment.
-
-But you should consider feature flags solely by taking into account this
-distilled trade-off analysis:
+on the code points you more obviously to continuous deployment. Take the
+following code sample for example, that we will reference later on the article:
+
+```javascript
+function processTransaction() {
+ validate();
+ persist();
+ // TODO: add call to notifyListeners()
+}
+```
+
+While being developed, being tested for suitability or something similar,
+`notifyListeners()` may not be included in the code at once. So instead of
+keeping it on a separate, long-lived branch, a feature flag can decide when the
+new, partially implemented function will be called:
+
+```javascript
+function processTransaction() {
+ validate();
+ persist();
+ if (featureIsEnabled("activate-notify-listeners")) {
+ notifyListeners();
+ }
+}
+```
+
+This allows your code to include `notifyListeners()`, and decide when to call it
+at runtime. For the price of extra things around the code, you get more
+dynamicity.
+
+So the fundamental question to ask yourself when considering adding a feature
+flag should be:
> Am I willing to pay with code complexity to get dynamicity?
@@ -52,6 +88,9 @@ absolutely worth the added complexity. This can vary a lot by code base, feature
fundamentally by environment: its much cheaper to deploy a new version of a
service than to release a new version of an app.
+So the question of which environment is being targeted is key when reasoning
+about costs and benefits of feature flags.
+
[cd]: https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment
## Control over the environment
@@ -114,14 +153,30 @@ having a dynamic control on the code itself, but rollbacks are cheap enough that
people usually do a normal deployment and just give some extra attention to the
metrics dashboard.
-On the **frontend**, CDN propagation delays and people not refreshing their web
-pages are rollouts by themselves. You could do this by geographical region or
-something similar, if desired.
+Any time you see a blue/green deployment, there is a rollout happening: most
+likely a load balancer is starting to direct traffic to the new server, until
+reaching 100% of the traffic. Effectively, that is a rollout.
+
+On the **frontend**, you can selectively pick which user's will be able to
+download the new version of a page. You could use geographical region, IP,
+cookie or something similar to make this decision.
+
+CDN propagation delays and people not refreshing their web
+pages are also rollouts by themselves, since old and new versions of the
+software will coexist.
On **mobile**, the Play Store allows you to perform
fine-grained [staged rollouts][staged-rollouts], and the App Store allows you to
perform limited [phased releases][phased-releases].
+Both for Android and iOS, the user plays the role of making the download.
+
+In summary: since you control the servers on the backend, you can do rollouts at
+will, and those are often found automated away in base infrastructure. On the
+frontend and on mobile, there are ways to make new versions available, but users
+may not download them immediately, and many different versions of the software
+end up coexisting.
+
[k8s]: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#creating-a-deployment
[staged-rollouts]: https://support.google.com/googleplay/android-developer/answer/6346149?hl=en
[phased-releases]: https://help.apple.com/app-store-connect/#/dev3d65fcee1