小编The*_*ter的帖子

我在 Gitlab 上真正喜欢的一件事是他们的网络图

有没有办法在 Github 中获得类似的外观/感觉？

我发现 gitlab 版本更容易使用

最初的计划是将其写成一篇博客文章，标题为“Spotify 元数据 API 中的低效率：或者，Jackson 5 如何杀死我的浏览器”，但在最后一刻改变了我的想法，因为我习惯于错过文档，也许我遗漏了一个未记录的功能，或者其他人已经解决了这个问题 - 因此这个问题有一定的博客文章语气！

我正在开发一个小型网络应用程序，主要面向一小群人，它允许任何人更新 Spotify 播放列表。由于不是每个人都有 Spotify（虽然我不知道为什么！），该页面将更新包含歌曲的数据库，因为在我的笔记本电脑上的 Spotify 中运行的应用程序轮询数据库以获取更新，然后使用 Spotify 应用程序 API，更新播放列表，订阅播放列表的任何人都会收到更新。没关系，虽然我想使用推送而不是投票，但这是另一天的话题。

我四处寻找与 Spotify 元数据 API 一起使用的 Javascript 库，并找到了一个（https://github.com/palmerj3/SpotifyJS），尽管它基本上是一个包装器，并且仍然需要您自己解析 JSON。我想我可以做得更好，并对最常见的字段（标题、艺术家、专辑、Spotify URI）进行一些基本的解析，我开始开发我自己的库/JQuery 插件。

按曲目搜索不是问题，它是对 Spotify 元数据 API 的一次调用，结果很容易解析，将返回的艺术家与请求的艺术家（如果存在）进行匹配，以便按标题/艺术家轻松搜索。

但是，按艺术家搜索（获取特定艺术家的所有歌曲列表）似乎很麻烦- * *！尽我所能从文档中得知，这就是过程。

1. 搜索艺术家：这将返回与查询匹配的艺术家列表
2. 对于每个艺术家，查找他们的专辑：这将返回一个列表专辑
3. 查找每个专辑并检索曲目列表
4. 如果匹配输出，则将每个曲目的艺术家与搜索艺术家进行比较

第一步将返回一个艺术家匹配的小列表，Foo Fighters 有 2 个，Silverchair 1，而 The Jackson 5 有 4 个。这个小列表变成了更多的专辑匹配 - 从记忆中 Foo Fighters 返回了 112，然后变成甚至更多的曲目列表。从 Javascript/JQuery 的角度来看，这会导致菊花链 AJAX 请求，对于每个步骤，以及在每个步骤中，针对 Spotify 服务器的大量几乎并发的 GET 请求。

我写的初始版本作弊并使用同步 AJAX，并且工作正常，因为每个请求必须在下一个请求开始之前完成，但是，这会锁定浏览器一段时间，并消除使用反馈给用户的可能性系统正在运行。然后我切换到异步请求，一切都崩溃了！您立即遇到了 Spotify 端的速率限制问题，它返回响应为 502 错误网关（顺便说一下，未在 Spotify 文档中作为状态列出）或 503 - 这两个 JQuery 都解释为状态代码 …