Improve /predict response for consistency and flexibility

[diessica]

The /predict endpoint returns a sentence based on the score instead of the score itself, although it is documented otherwise. https://github.com/malteserteresa/stop-it/blob/master/deploy.py#L21

I suggest that we return the score, as per documentation. Some reasons I can think of:

1. easier to reason about a number than a language-specific string. If the string changes, then we'd keep up with it, since we are relying on the sentence result. Seems non-standard.
2. flexibility on what to show based on different scores looks like a front-end's responsibility, while the back-end returns only a score within a meaningful and documented scale (0 to 1). (I might be wrong here though, I don't think I have enough context.)
3. logic can be tested in the front-end accordingly.

Example

Current front-end.

   // replace.js

   if (apiResponse === "That's not very nice.") {
     // modify website content
   }

Front-end after proposed API change.

   // replace.js

   if (score > 0.25) {
   // modify website content 
   } else if (score > 0.5) {
   // modify website content
   }

   [...]

I believe this is leads to a more scalable and mature design for the API, providing flexibility, purity and with no language bias.

Let me know if there is something I am missing, especially context regarding the decision made for the current API design.

[malteserteresa]

Hi @diessica ,

You're 100% right, it was left like that just for the fancy demos ^^

Tune back in Monday and hopefully the project will be microserviced and ready for a fab ass front-end. Also are you elm aware?

[diessica]

Great that it makes sense!

Yes, I am Elm aware and would love to play with it. However, giving my 20 cents here: I don't think there is an explicit use case for it here. Plain JavaScript will do, for ease of access (for anyone to contribute) and it would perform obviously better for a simple extension - this is not an app, at least not yet. I would only adopt a library or framework given a reasonable problem statement - same for a microservice architecture.

[malteserteresa]

Sure I hear you, I was more thinking Elm architecture. Your right in terms of simplicity and its pretty boiler platey but I am also keen to focus on maintainability as soon as possible.

The backend now returns a 1 or a 0 (1 being nasty, 0 being nice) so....go front-end loco ;)

[malteserteresa]

Also send me an email and I'll add you to the slack group

[malteserteresa]

Now returns json with score: 0 or 1