Enable v3-Style Stoplist Specification in /parallels

[jeffkinnison]

Currently, the /parallels endpoint only supports submitting a list of stopwords, and the stoplist cannot be parameterized with a number and a stopword basis. For ease of use, both methods should be exposed.

[nOkuda]

I had intentionally designed the /parallels/ endpoint to decouple stopword list generation from search results. This makes for easier cache lookup on repeated searches of the same parameters.

However, I also intended the user experience on the new website to be the same as v3, where a number and stopword basis could be chosen via the UI. I imagined that under the hood, that action simply hits the /stopwords/ endpoint for the lookup and then submits the stopwords it found to the /parallels/ endpoint.

Do you find my vision acceptable?

[jeffkinnison]

Right, that's what I figured you intended.

From a practical standpoint in the frontend, the separate endpoint introduces a lot of extra complexity, particularly in the case that the stoplist hasn't populated before someone initiates a search. I can work around that, but it would be much easier to be able to compute it on-the-fly when parallels is pinged and store that list for later use.

[nOkuda]

I had thought it would be relatively straightforward to wire in the separate endpoint, but I guess it is not as I had hoped. (Is async the culprit?)

I suppose we could have a check on the API server whether a list of strings or a JSON object got associated with the 'stopwords' field for the input at /parallels/ and then generate the stopwords list before passing the search job onto the job queue. That doesn't sound too bad. If that sounds good to you, I can roll that onto #11, which is waiting approval on tesserae/tesserae-v5#42.

Do you like that plan?

[jeffkinnison]

Making the request isn't the issue so much as handling the side effects. Let's table this for now and see if I can't get something reasonable worked out.