Don't allow users to create too many saved searches

[cespare]

If a user isn't aware how Barkeep's saved search mechanism works, they can inadvertently add lots of searches. This will degrade the performance of the main page for them (even to the point where it will take too long to load and nginx will kill it).

The long-term fix here probably involves better search caching and/or changing the saved search UX. (See #179, #170, and #75).

However, as a short-term fix, we shouldn't allow people to add saved searches at all past some reasonable number (5? 10? 20?)

[philc]

10 seems like a reasonable cap if it's significantly snappier than 20. 20 is more than enough.

[alekstorm]

Most of those searches are likely exact duplicates. The problem could be mitigated by, when a search is submitted, checking whether that search is already saved, and simply moving it to the top if it is.

[philc]

I'm not sure if that's the root cause of this problem, but it's a good suggestion.

The big caveat is that if we implemented that UX, with the current UI, they would not be able to have two saved searches with the same criteria, but where one covers all commits and another covers only unapproved commits (I have two such searches setup in barkeep right now). Any ideas?

[alekstorm]

Good point, I didn't know anyone used Barkeep like that. You could add another approved: keyword with values yes and no, which makes more sense than exposing that UX through the "Search options" dropdown, since it does "narrow" the search. Of course, keyword bloat must be managed carefully.

Deduplicating saved searches without adding an approved: keyword would still support your workflow, though, since you can just click "Search options", then "Show unapproved" (this is what I do, although I concede it's a bit clunkier). Or do you have email notifications set up differently for approved/unapproved?