FishHawk
[WIP] feat(web+server+addon): 实现用户侧爬虫
这个是 Pixiv 用户侧爬虫 POC
[!caution] WIP：请勿直接合入。
目前拟定：
- 用户在 pixiv 页面手动触发更新。（对于首次更新怎么处理）。
- 维护 server 端和 web 端两套爬虫。
Depends on #286
目前进度： pixiv 可用，但是有一些边界需要讨论一下：
前情提要：
- 进入 novel 页面会触发一次 metadata 加载。
- 进入任何章节页面会触发一次章节 chapter 加载。
问题： 在目前架构下，任何 getMetadata / getChapter 都会产生副作用：server 会在发现没有数据的情况下去主动发起爬虫请求。 因此就有矛盾，你需要提供一个无副作用的 api endpoint，让用户侧 addon 知道自己该不该去爬数据。
目前的设计是 metadata 在用户侧每次都会爬取（aka 刷新机翻站 novel 页面等于访问一次对应的 pixiv） 之后 metadata 会上报给 server 用户更新 metadata（这部分可以在 storage 中加一个 ratelimit，防止过量请求，已经加了）
chapter 数据必须由用户手动点击页面的「更新」按钮才会爬取并上报。
还有一个矛盾，由于 Addon 是动态加载的，导致异步加载情况下， vue 页面加载的时候，没办法知道 Addon 是否存在。
目前，在 env 中存在 window.Addon 的情况下才会显示「更新」按钮，用的 computed，不知道会不会有临界问题。
- 进入
/novel/pixiv/noveld的时候会触发 Addon metadata 更新（localStorage 中每 1h 允许一次） - 点击更新按钮，Addon 会自动爬取 metadata + 全部章节内容
TODO
- 考虑是否对 getChapter aka， 进入 chapter 的时候也触发更新，但是感觉会有一些问题。
分开合并是很正常的，不是说一个feature就必须端到端合并，不如说限制pr大小是惯例了，不管是公司还是开源项目。分开合并的意义，是减少review的负担。现在根本没有testcase，但如果要写的话，我上面说的三个拆分，每个都可以写testcase
u1s1，分开合并还是很麻烦的，每个部分都没办法很好的去测，单独写 testcase 对于敏捷开发的开源项目来说也不太现实。
另外统一写到一个 pr 里面就是因为这个 pr 涉及多个模块。丢一个 pr 里面就是有个地方讨论各个模块和模块之间的接口。 尤其是现在没有明确需求，到时候很可能就是写着写着发现之前 crawler pr 的功能不够或者不充分，你写 server 端的时候还要附带上 crawler 相关的返工修改。
你就当这个 pr 是一个计划书就行了，用代码的形式说明我这边的 web crawler 的设计方案。如果通过了的话，这个 pr close 了重新拆出来其他 pr 也行。
拆pr就是为了review，700行代码神仙来了也难受。没事，我来拆吧，我可以测。
不是，目前的代码本来就不是为了 code review 的，只是让你看一下实现的思路，以及遇到的问题。作为讨论的 base，不是真的要把这坨代码合进去。