Replies: 4 comments
-
@schalkneethling @Gregoor @escattone ? |
Beta Was this translation helpful? Give feedback.
-
I'm all in! 😄 |
Beta Was this translation helpful? Give feedback.
-
Wheels are in motion! mdn/kuma#7883 yari/client/src/user-context.tsx Line 20 in ab63390 |
Beta Was this translation helpful? Give feedback.
-
IT WORKED! mdn/kuma#7883 (comment) I'm just going to copy the same screenshot here because it's so pretty: |
Beta Was this translation helpful? Give feedback.
-
Right now we don't use any waffle flags for anything. ...outside of Kuma.
We do use a waffle Switch for
welcome_email
which determines whether we send a welcome email or not here and here. But let's not let that distract us.There is, today, no active uses of any of the
waffle
struct we get from Kuma to Yari in the/api/v1/whoami
.Suppose that we want to launch another Developer Needs-like survey in a near future, what we probably would do is to manually "hardcode" it into Yari. Because we re-do this a bit it could be as simple as commenting in or out some existing code.
Suppose our partners want the survey to go online on Febjuni 32nd, we can simply time it with a PR on Yari and wait for the next Yari release. Or if they want it to go out at exactly 16:00GMT we can simply kick off a Yari prod build at 15:00GMT and it'll be perfectly time. (or even better, land it in advance but put a
if (new Date().getTime() > TIME_TO_SHOW) {
snippet into the code (assuming we can trust the client timestamp)).Suppose we want to do a thing where we only want it for 25% of the signed in population>? Easy, you just write (
if (userData.isAuthenticated && Math.random() > 0.75) { localStorage('enrolled_experiment', 'true') }
. And when you're done with that you delete the code from Yari (could be as simple as reverting a PR).The only thing Kuma's waffle Flag can do that Yari can't is to store your enrollment centrally for signed-in people.
The other reason for removing it from Kuma is because it's probably just there because it couldn't be done in any other way back in the day when we didn't move nearly as fast. These days we can have a new version of Yari out in a matter of 1-2h. And equally, if it's on the Kuma side where we just land a PR and Ryan rolls out a release which is nearly all automated now.
Last but not least, we have our users hit
/api/v1/whoami
a LOT.233M times in the last month. The, by far, most expensive thing in the
/api/v1/whoami
is to wake up the Elasticache to make 2 queries to see if the waffle flags apply to each and every single anonymous request.It does slow down the endpoint. That waffle flag "induced" part is the slowest part of the Django view for anonymous users. If we can remove that we can more quickly return on the XHR request that Yari does on every request.
Who's with me?
I propose we leave waffle flags entirely as they are in all Kuma code, except within the
whoami
Django view function (and its tests). Then we remove it from Yari here and review any existing old (inactive) Banner components that might refer to it.Beta Was this translation helpful? Give feedback.
All reactions