决策树

在 n8n 或纯 Python 中检查网站反向链接?

一个包含 25 个节点的画布用于三步任务是一个常见的遗憾。另一个是没人能编辑的脚本。使用决策树。

森林中的木制决策树,具有两条不同的路径

决策树,从上到下

  • 是否有非技术人员编辑流程或查看运行记录?选择 n8n 或 Make。
  • 任务是否在 60 行以内,并且无论如何都存在于仓库中?选择 Python。
  • 你需要发送 Slack 帖子和表格行,但不需要差异对比?选择带有一个 HTTP 请求节点的 n8n。
  • 你需要对比几十个域名、保留历史记录或进行解析单元测试?选择带 SQLite 的 Python。
  • 团队是否已经为 n8n 云执行付费?计算一下:一个 40 个域名的循环可能会消耗掉套餐额度。
  • 以上都不符合?从 shell 脚本中的 curl 开始,看看哪里会出问题。

当可视化流程证明其价值时

在某些任务中,画布的杂乱是值得的。如果非技术人员需要看到每一步及其上次运行结果,可视化流程优于他们永远不会打开的仓库。保持简短。

大多数反向链接任务包括获取、检查和写入。四个节点就能很好地完成这些工作。如果你的任务是为客户每月检查网站反向链接,这种结构适合画布。麻烦始于有人添加分页、重试和差异对比,因为每一个都会带来自己的分支。

为读者选择画布,而不是为作者。

谁阅读流程

营销和销售人员通过输出来阅读流程,他们希望最后运行结果一目了然。画布无需工单即可提供这一点。他们阅读的是输出,而不是代码。脚本给他们一个他们不会打开的日志文件。

给流程一个清晰的名称和一行描述,以便下一个阅读者在打开之前知道它承诺了什么。一个标签模糊的节点比任何缺失的功能都更耗时。

一目了然的分支

基于 ok 的 IF 节点易于遵循。页面上有三个 IF 节点仍然可读,如果每个分支都有清晰的名称。超过这个数量,线条就会交叉,审查者需要十分钟才能确定哪个分支在空结果时触发。

画布成为负担的地方

多个域名的循环、运行之间的共享状态和单元测试是常见的压力点。画布通过变通方法处理每个问题,而每个变通方法都是流程偏离你原意的地方。

如果你发现自己导出 JSON 来修复流程,说明任务已经超出了画布的能力。将逻辑移至代码,保留画布用于通知。

插入木门锁的带有红丝带的黄铜钥匙

四行代码完成 n8n 设置

一个 HTTP 请求节点,方法 GET,URL https://linkzoid.pro/api.php。添加查询参数 action、q、key。任何想以这种方式检查网站反向链接的人都可以复制它,只需五分钟。

将密钥存储在凭据中,而不是节点中。添加一个基于 ok 的 IF 节点,并将 false 分支发送到向你发送通知的错误工作流。

使用“项目列表”或“拆分输出”节点拆分 rows 数组,然后写入 Google Sheets 或 Postgres。注意执行计数,因为在某些计划中,每个项目都可能被计为一步。

这就是整个任务。当分页出现时它会出错:n8n 中的循环可以工作,但在大约十个节点之后阅读起来就很困难。

用五个节点构建 n8n 流程

每个节点只做一件事,并且在添加下一个节点之前可以单独测试每个节点。

01

创建 HTTP 请求节点

方法 GET 和 URL https://linkzoid.pro/api.php。添加 action、q 和 per 作为查询参数,并将密钥留到下一步。

02

将密钥附加为凭据

将其存储在 n8n 凭据中,并从查询中引用。直接输入 URL 字段的密钥最终可能会出现在日志和导出文件中。

03

基于 ok 标志进行门控

添加一个读取 ok 的 IF 节点。将 false 分支发送到错误工作流,将响应体发布到你将会看到的地方。

04

拆分行

对 rows 数组使用“拆分输出”,使每个域名成为自己的项目。将这些项目写入表格或表,而不是将整个响应写入一个单元格。

05

首先测试免费操作

将节点指向 overview,它不需要密钥,并在切换到付费操作之前确认响应的形状。

故障排除表

症状n8n 原因Python 原因
只收到 10 行节点未设置 per 参数同上,检查查询字符串
运行成功,表格为空行未拆分为项目写入了字典而不是 rows
一周后出现 402工作流在触发器上循环Cron 触发两次
密钥泄露到日志中粘贴到 URL 字段打印了完整的 URL
月度差距执行保留删除了旧运行从未存储历史记录

每次运行的成本

在我们这边,成本是一样的:refdomains 页面需要 2 个积分。成本差异在于构建器。

自托管的 n8n 运行免费。云计划计算执行次数。计划任务中的纯脚本无需成本。

无论选择哪种,都要在工具之外保留每次运行的日期副本。Actions 中的每周快照 是一个整洁的存放位置,套件比较 解释了为什么拥有自己的历史记录很有价值。

计算每个域名的执行次数

40 个域名的循环在计算执行次数的计划中就是 40 次运行。在将任务安排到计划之前,检查你的计划如何计算循环,因为账单跟随计数,而不是积分。

在计划旁边写下预期的计数。当估计值已经在文件中时,账单上的意外更容易解释。

自托管也有自己的账单

自托管的 n8n 成本包括服务器、升级和备份。数据库由你负责保持活跃。小机器上的纯脚本有更少的移动部件,这也是选择它用于固定月度任务的原因之一。

天平平衡盆栽植物和一堆散石

通常首先出什么

在 n8n 中是分页和项目计数。在 Python 中是没人测试的东西:空的 rows、超时、字段名称与你假设的不同。

没有哪个工具是错的。根据六个月后维护它的人来选择。如果是你独自一人,代码更容易搜索。如果是已经习惯于画布的营销团队,他们能看到的小流程优于他们害怕的仓库。

混合设置也可以。让 Python 按计划写入 CSV,让 n8n 读取文件并发布到 Slack。每个工具处理它最擅长的部分,并且每个流程都不会超过十个步骤。

保持 Python 版本的可读性

代码的常见情况是六个月后其他人需要更改它。让这变得容易。一个名称清晰、保存了响应的短脚本优于没人敢碰的巧妙单行代码。

在保存的响应上测试解析器

将一次真实响应保存到文件中,并将单元测试指向它。解析器现在可以在不花费积分的情况下运行,并且重命名的字段会在测试运行时失败,而不是在周一早上。

保持保存的响应较小,因为十几行就足够了。记录你获取它的日期,以便知道字段名称上次更改的时间。

将设置放在一个地方

域名、操作和页面大小应属于一个小配置块,而不是分散在脚本中。然后,同事可以更改目标列表,而无需触碰解析行的逻辑。

也将密钥从该块中移除。从环境变量加载它们,加载密钥的方式相同。

在承诺之前进行两周的试用

不要仅在纸上解决这个问题。在每个工具中构建任务的最小版本,每天运行两周,看看哪一个是你不需要被要求就会打开的。

看看什么会出错。计算你手动编辑某物的次数,以及输出错误但没有错误的次数。要求较少手动修复的工具就是应该保留的工具。

记录每次手动修复

保留每次手动触摸流程或脚本的简单笔记。两周后的一份简短列表比任何功能表都能告诉你更多。

记录谁要求了更改

如果请求来自不能阅读代码的人,画布可能会赢。如果来自你,仓库更容易相处。

只要你能指出它,任何答案都可以。在流程或仓库旁边写下原因,并在任务增长时重新审视它。

给构建者的简短答案

Make 或 Zapier 能与此 API 配合使用吗?
可以。任何能发送带有查询参数的 HTTPS GET 的东西都可以,包括 Make、Zapier、Pipedream 和 Apps Script。使用通用 HTTP 模块,将密钥存储在连接中,并在下一步读取 JSON rows 数组。
AI 代理可以代替调用它吗?
从技术上讲可以,因为它是纯 HTTP API。对于固定的月度任务,脚本更便宜且更可预测,而代理会增加模型账单和参数错误的风险。仅对临时问题使用代理。
最便宜的开始方式是什么?
使用 curl 和免费概览操作的 shell 脚本,从 cron 运行。无需密钥,无需成本,你可以了解响应形状。当出现第一个棘手的 JSON 解析时,再转向 Python。