We have gone live and don't need any of the waffle switches on /api.
Assignee: nobody → peterbe
Status: NEW → ASSIGNED
We need to keep this. Waffle lets us kill the API quickly in case someone accidentally pushes PII exposing code in the future.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
Good thinking! I think of waffle as a dev tool, not as a configuration tool. Still having wafffle does mean an extra database query each time now which is kind of annoying.
Perhaps the solution to that problem is to extend django-waffle to read from memcache instead to reduce the excess PG usage.
How big is the hit? I suspect there are other places we should go after first.
(In reply to Chris Lonnen :lonnen from comment #5) > How big is the hit? I suspect there are other places we should go after > first. I agree, we should measure before cutting. Keep in mind that Postgres does fairly sophisticated caching of its own so it's likely to be competitive w/ memcached for tables like this that see very few updates. The benefit of being able to easily and quickly switch things off/on is probably worth a minor performance regression in any case, especially if the risk we're assessing is "OMG PII is exposed turn it off turn it off" type of scenario.
I'm less concerned about the number of milliseconds it takes to talk to PG. More concerned with the fact that sometimes it just can't connect and we get odd TCP related errors on Errormill. Having said that, suppose we don't have waffle causing an extra PG read, I'm sure we'd have some other auth thing doing a read too. Also, PII leakage bugs can happen anywhere and we don't have waffle everywhere. Switch off entire chunks of functionality might be more embarrassing than to just fail forward quickly. Let's leave this as WONTFIX for now but keep it in mind some time in the future when we try to reduce excessive stuff we can live without.
You need to log in before you can comment on or make changes to this bug.