aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorEuAndreh <eu@euandre.org>2020-10-14 00:40:07 -0300
committerEuAndreh <eu@euandre.org>2020-10-14 00:40:07 -0300
commitee4a894a5be2ebabeccd7a3dd4b8e87f1396ad73 (patch)
tree1207e1fb554549837eede8c6192cb9a94a641b9d
parentSpelling of feature flags article (diff)
downloadeuandre.org-ee4a894a5be2ebabeccd7a3dd4b8e87f1396ad73.tar.gz
euandre.org-ee4a894a5be2ebabeccd7a3dd4b8e87f1396ad73.tar.xz
feature flag article: proofreading
-rw-r--r--_articles/2020-10-14-feature-flags-differences-between-backend-frontent-and-mobile.md39
-rw-r--r--scripts/spelling/en.txt1
2 files changed, 21 insertions, 19 deletions
diff --git a/_articles/2020-10-14-feature-flags-differences-between-backend-frontent-and-mobile.md b/_articles/2020-10-14-feature-flags-differences-between-backend-frontent-and-mobile.md
index 4cc41e9..8b3b97a 100644
--- a/_articles/2020-10-14-feature-flags-differences-between-backend-frontent-and-mobile.md
+++ b/_articles/2020-10-14-feature-flags-differences-between-backend-frontent-and-mobile.md
@@ -45,11 +45,11 @@ distilled trade-off analysis:
It is true that you can make the management of feature flags as
straightforward as possible, but having no feature flags is simpler than having
any. What you get in return is the ability to parameterize the behaviour of the
-application in runtime, without doing any code changes.
+application at runtime, without doing any code changes.
Sometimes this added complexity may tilt the balance towards not using a feature
-flag, and sometimes the flexibility of changing behaviour on runtime absolutely
-is worth the added complexity. This can vary a lot by code base, feature, but
+flag, and sometimes the flexibility of changing behaviour at runtime is
+absolutely worth the added complexity. This can vary a lot by code base, feature, but
fundamentally by environment: its much cheaper to deploy a new version of a
service than to release a new version of an app.
@@ -78,7 +78,7 @@ with similar characteristics: desktop applications, command-line programs,
On **mobile** you have even less control: app stores need to allow your app to
be updated, which could bite you when least desired. Theoretically you could
make you APK available on third party stores like [F-Droid][f-droid], or even
-make the APK itself available for direct download, which you give the same
+make the APK itself available for direct download, which would give you the same
characteristics of a frontend application, but that happens less often.
On iOS you can't even do that. You have to get Apple's blessing on every single
@@ -92,11 +92,13 @@ having a dynamic flag on the backend may or may not be worth it since you could
always update the code immediately after, but on iOS it is basically always
worth it.
+[f-droid]: https://f-droid.org/
[^force]: Technically you could force a reload with JavaScript using
`window.location.reload()`, but that not only is invasive and impolite, but
also gives you the illusion that you have control over the client when you
actually don't: clients with disabled JavaScript would be immune to such
tactics.
+
[apple]: http://www.paulgraham.com/apple.html
## Rollout
@@ -139,9 +141,9 @@ and client version.
On the **backend**, those are useful for things that have a long development
cycle, or that needs to done by steps. Consider loading the feature flag rules
-in memory when the application starts, so that you avoid querying the database
-or an external service for applying a feature flag rule to avoid intermittent
-network failures.
+in memory when the application starts, so that you avoid querying a database
+or an external service for applying a feature flag rule and avoid flakiness on
+the result due to intermittent network failures.
Since on the **frontend** you don't control when to update the client software,
you're left with applying the feature flag rule on the server, and exposing the
@@ -150,14 +152,14 @@ itself, and fallback to a "just refresh the page"/"just update to the latest
version" strategy for less dynamic scenarios.
On **mobile** you can't even rely on a "just update to the latest version"
-strategy, since the code for the app could be updated to a new feature but it
-can't get through the store. Those cases aren't recurrent, but you should always
-assume the store will deny updates on critical moments so you don't find
-yourself with no cards to play. That means the only control you actually have is
-remote via the backend, and parameterize the runtime of the application using
-the API. In practice, you should always have a feature flag to control any relevant
-piece of code. There is no such thing as "too small code change for a feature
-flag". What you should ask yourself is:
+strategy, since the code for the app could be updated to a new feature and be
+blocked on the store. Those cases aren't recurrent, but you should always assume
+the store will deny updates on critical moments so you don't find yourself with
+no cards to play. That means the only control you actually have is via
+the backend, by parameterizing the runtime of the application using the API. In
+practice, you should always have a feature flag to control any relevant piece of
+code. There is no such thing as "too small code change for a feature flag". What
+you should ask yourself is:
> If the code I'm writing breaks and stays broken for around a month, do I care?
@@ -169,13 +171,12 @@ filesystem/database changes, *etc*.
## Experiment
An experiment is a feature flag where you care about analytical value of the
-flag, and how it might impact user's behaviour. Like a feature flag with
-analytics.
+flag, and how it might impact user's behaviour. A feature flag with analytics.
They are also usually medium-lived, being relevant as long as the new code is
being developed. The most common rule is A/B test.
-On the **backend**, experiment rely on an analytical environment that will
+On the **backend**, an experiment rely on an analytical environment that will
pick the A/B test groups and distributions, which means those can't be held in
memory easily. That also means that you'll need a fallback value in case
fetching the group for a given customer fails.
@@ -185,7 +186,7 @@ On the **frontend** and on **mobile** they are no different from feature flags.
## Operational toggle
An operational toggle is like a system-level manual circuit breaker, where you
-turn on/off a feature, or fail over the load to a different server. They are
+turn on/off a feature, fail over the load to a different server, *etc*. They are
useful switches to have during an incident.
They are usually long-lived, being relevant as long as the code is in
diff --git a/scripts/spelling/en.txt b/scripts/spelling/en.txt
index f7128b1..89af62d 100644
--- a/scripts/spelling/en.txt
+++ b/scripts/spelling/en.txt
@@ -25,6 +25,7 @@ filesystems
isn
maintainence
oday
+parameterizing
portuguese
portuguse
pre