Where do we stand on outsourcing the scraping backend?

[port19x]

riimu's consument api looks like a good candidate and is a spiritual successor to gogoanime api.
This would fit with our philosophy of avoiding duplication of effort.
With our frontend interface pretty stable, aside from the switch to fzf-only, this could make provider breakage a non-issue, due to several providers being supported upstream at consument.
This would likely readd the jq dependency, since it's a rest api with regular json responses.
In return, we may be able to get rid off grep and sed dependencies entirely.

Really this is a question of philosophy and I'm sure you can see any further implications yourself.
Would outsourcing the scraping be something worthwhile in your opinion?
Or do we continue to make @CoolnsX fix the occasional breakage?

[justchokingaround]

i like this, and json can easily be parsed with sed without jq

[port19x]

In a well readable way?
If we can make sed parsing of json readable through some consistent convention I'd be fine with that too

[justchokingaround]

ye could be done reasonabily, ill try abusing the api for lobster first then i'll see if sed is reliable enough

[port19x]

I'll have a chat with riimu later this evening if our timezones allow for it

[Derisis13]

I'm still thinking about this, but so far no breakage has happened since the change to animixplay. Not even the providers.
I consider less (and more basic) dependencies better than less code, for this project at least.
Reliance on an api doesn't sit well for me. I don't consider duplication of effort bad, it leads to redundancy, decentralization and different approaches with different goals. If the api closes for whatever reason (and since it needs to be hosted somewhere it's a matter of if, not when) whereas the script works as long as we'd like to maintain it.
The stability of the api also needs to be considered. What if it breaks overnight? We can always tell our users to roll back a version, this is impossible with an api. I'm not too worried about fixing it fast, but it could be better or worse than what we're able to do.
Also our track record with big overhauls is quite bad, usually many revisions needed to fix uncaught bugs. Changing to the api would mean new bugs, bringing short term issues.
So yeah, I'm against it so far, because I don't see any benefit as of now, but I'm open to reconsider.

[port19x]

Since it didn't break in the past two months since your comment either I'll agree to not mess with ani-cli in the foreseeable future