Fast full-text searching in Python (job for Whoosh?)

[Thomas Passin]

On 3/7/2023 7:33 AM, Dino wrote:
>> It must be nice to have a server or two...
> 
> No kidding
> 
> About everything else you wrote, it makes a ton of sense, in fact it's a 
> dilemma I am facing now. My back-end returns 10 entries (I am limiting 
> to max 10 matches server side for reasons you can imagine).
> As the user keeps typing, should I restrict the existing result set 
> based on the new information or re-issue a API call to the server?
> Things get confusing pretty fast for the user. You don't want too many 
> cooks in kitchen, I guess.
> Played a little bit with both approaches in my little application. 
> Re-requesting from the server seems to win hands down in my case.
> I am sure that them google engineers reached spectacular levels of UI 
> finesse with stuff like this.

Subject of course to trying this out, I would be inclined to send a much 
larger list of responses to the client, and let the client reduce the 
number to be displayed.  The latency for sending a longer list will be 
smaller than establishing a new connection or even reusing an old one to 
send a new, short list of responses.  When the client types more, it can 
only reduce the number of possibilities - among the (possibly imaginary) 
larger original number of them. After the next round of user typing, the 
client can check and see if there are enough surviving responses to 
list.  If not, it can then request a new list from the server.

Using this in reverse, if the user deletes some characters from the end, 
there should be no need to go back to the server.  The possible 
responses would already have been sent to the client.  They could be 
interned in an associative array keyed by the string the client had 
typed to get those responses.