~euandreh/website

ee4a894a5be2ebabeccd7a3dd4b8e87f1396ad73 — EuAndreh 16 days ago f33cb06
feature flag article: proofreading
M _articles/2020-10-14-feature-flags-differences-between-backend-frontent-and-mobile.md => _articles/2020-10-14-feature-flags-differences-between-backend-frontent-and-mobile.md +20 -19
@@ 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

M scripts/spelling/en.txt => scripts/spelling/en.txt +1 -0
@@ 25,6 25,7 @@ filesystems
isn
maintainence
oday
parameterizing
portuguese
portuguse
pre