共计 5147 个字符，预计需要花费 13 分钟才能阅读完成。
逻辑编排是用可视化形式形容逻辑，在个别搭建场景中用于代替逻辑形容局部。
更进一步的逻辑编排是前后端逻辑混排，个别呈现在一站式 paas 平台，明天就介绍一个全面实现了逻辑编排的 paas 工具 node-red，本周精读的内容是其介绍视频：How To Create Your First Flow In Node-RED，介绍了如果利用纯逻辑编排实现一个天气查问利用，以及部署与利用迁徙。
概述
想要在本地运行 Node-RED 很简略，只有上面两条命令：
npm install -g --unsafe-perm node-red
node-red之后你就能够看到这个逻辑编排界面了：
咱们能够利用这些逻辑节点构建前端网站、后端服务，以及大部分开发工作。光这么说还比拟形象，咱们接下来会具体介绍每个逻辑节点的作用，让你理解这些逻辑节点是如何规划设计的，以及逻辑编排到底是怎么管制研发标准来进步研发效率的。
Node-RED 截止目前共有 42 个逻辑节点，依照通用、性能、网络、序列、解析、存储分为六大类。
所有节点都可能有左右连接点，左连接点是输出，右连接点是输入，非凡节点可能有多个输出或多个输入，其实对应代码也不难理解，就是入参和出参。
上面顺次介绍每个节点的性能。
通用
通用节点解决通用逻辑，比方手动输出数据、调试、谬误捕捉、正文等。
inject
手动输出节点。能够定期产生一些输出，由下一个节点生产。
举个例子，比方能够定期产生一些固定值，如这样一个这个对象：
return {payload: new Date(),
topic: "abc",
};当然这里是用 UI 表单配置的：
之后就是生产，简直前面任何节点都能够生产，比方利用 change 节点来设置一些环境变量时，或者利用 template 节点设置 html 模版时，都能够拿到这里输出的变量。如果在模版里，变量通过 {{msg.payload}} 拜访，如果是其它表单，甚至能够通过下拉框间接枚举抉择。
然而这个节点往往用来设置动态变量，更多的输出状况是来自其它程序或者用户的，比方 http in，这个前面会讲到。其实通过这种组合关系，咱们能够把任意节点的输出从生产节点替换为 inject 节点，从而实现一些 mock 成果，而 inject 节点也反对配置定时主动触发：
debug
用来调试的，当任何输入节点连贯到 debug 的输出后，将会在控制台打印出输入信息，不便调试。
比方咱们将 inject 的输出连上 debug 的输出，就能够在触发数据后在控制台看到打印后果：
当然如果你把输出连贯到 debug，那么原有逻辑就中断了，然而任何输入节点都能够无限度的输入给其它节点，你只有同时把输入连贯到 debug 与性能节点就行了：
complete
监听某些节点触发实现动作。通过这个节点，咱们能够捕捉任意节点触发的动作，能够接入 debug 节点打印日志，或者 function 节点解决一下逻辑。
能够监听全副节点，也能够用可视化形式抉择要监听哪些节点：
catch
谬误捕捉节点，当任何或指定节点触发谬误时输入，输入的格局为：
error.message 字符串
谬误音讯。error.source.id 字符串
引发谬误的节点的 ID。error.source.type 字符串
引发谬误的节点的类型。error.source.name 字符串
引发谬误的节点的名称。（如果已设置）其实每个节点都有固定输入格局，这些固定格局限度了开发灵便度，但熟练掌握后能够大大晋升开发效率，因为所有同类型节点格局都是一样的，这是逻辑编排带来规定束缚的益处。
status
监听节点状态变动。
link in
只能连贯 link out。link in、link out 就像一个传送门，用来整顿逻辑编排节点，使之看上去易于保护。
比方上面的例子，在一个天气 http in 服务后，交叉了许多逻辑解决节点，有解决响应 html 内容的 template 节点，也有解决申请查问城市天气的 http request 服务，整体逻辑尽管聚合，但比拟芜杂：
较好的形式是分类，即相似代码开发中的模块化行为，将天气服务导出，其余任何用到的模块间接导入，这个导入动作就是通过 link in 实现的，link out -> link in 只是一个空间地位的变换，传输值是不会变的：
这样模块看起来清晰了许多，如果要晓得各个“传送门”见连贯关系，只有鼠标点击其中一个就能够给出提醒，看起来非常不便：
link out
和 link in 成对呈现，用来导出输出值，前面对接 link out 能够像传送门一样将值传送过来，在视觉上不会造成连接线。
comment
正文，配合 link 系列应用，能够让逻辑编排 UI 更易于保护。
联合原视频的例子，对于天气服务，有创立环境变量逻辑，有查问逻辑，其中查问天气还分为查问以后天气、间断 5 天天气、查问国家信息，咱们能够在 UI 上讲每块逻辑分组，并利用 comment 组件标记好正文，不便浏览：
性能
功能型节点，个别用于解决业务逻辑，所以蕴含了根底的 if else、js 代码、模版解决等等功能模块。
function
最外围的 js 函数模块，你能够用它做任何事：
其输出会传导到 msg 对象，能够通过代码批改 msg 对象后再通过输入节点传导进来。
当然也能够拜访和批改节点、流程、全局变量，这个在 change 节点里介绍。
switch
对应代码的 switch，只是用起来更加不便，因为咱们能够依据不同 case 导出不同的节点：
留神看上图，因为有三条分支，所以节点的导出项也变成了三个，咱们能够依据不同逻辑走不同的连贯：
change
用来扭转环境变量。环境变量分为三种，别离是以后节点、流程（画布）、全局（跨利用）。也就是说，变量能够存储在某个节点上，也能够存储在整个画布上，也能够跨画布存储在全局。
拜访参数别离为 msg.、flow.、global.，设置这些参数后，就像全局变量一样，任何节点都能够在任何中央应用，比拟不便。
比方利用固定了一些 URL 地址，间接把一串字符串写死在某个 http in 节点里并不明智，因为前面的 html 或者其它节点里可能会拜访它，一旦你进行批改，影响面会十分广，因而最好将其设置为全局变量，在节点中通过变量形式拜访：
其实在控制台，能够看到这三种变量的值：
当咱们利用 change 节点赋值后，能够通过调试面板查看不同作用域全局变量的值：
range
区间映射，将一个范畴的值映射到另一个范畴。其实通过 function 模块也能实现，只是因为比拟罕用所以封装了一个非凡节点。其实用户也能够本人封装节点，具体形式能够参考 官网文档。
上图很容易了解，比方数据分析中归一化就能够用这个节点实现。
template
以模版形式生成字符串或 json。
其实实质上也能够被 function 代替，只是用来写模版的话有高亮，保护起来比拟不便。
内置了 mustache 模版语法，通过 {{}} 形式应用变量。
比方咱们通过 inject 注入一个变量给 template，并通过 debug 打印，流程是这样的：
其中 inject 是这么配置的：
能够看到，将 msg.name 设置为一个字符串，而后通过 template 拜访 name:
delay
提早发消息，一个快捷的工具，能够放在任何输出与输入两头，比方让下面的例子中，inject 触发后 5s 再打印后果，能够这么配置：
trigger
一个音讯触发器，相比 inject，能够更灵便的设置何时从新触发。
从配置能够看出，首先和 inject 一样发送一条音讯，而后能够期待，或者期待被重置，或者周期性触发（这样就和 inject 一样），其中“发送第二条音讯到独自的输入”和 switch 一样会多一个输入口。
而后有重置条件，即 payload 为什么值时重置。
通过这个组件能够看进去，其实每个节点都能够用 function 节点实现，只不过通过定制一个节点，能够用 UI 而非代码的形式配置，应用起来更不便。
exec
执行系统命令，比方 ls 等，这个在零碎后盾执行而非前端，所以是一个相当危险的节点。
咱们能够在配置中写入任何命令：
rbe
异样报告节点（Report by Exception），比如说当输出变动时进行阻塞。
网络
用于创立网络服务，比方 http、socket、tcp、udp 等等，因为其它都不罕用，这次仅介绍 http 服务。
http in
创立一个 http 服务，能够是任何接口或者 web 服务。
当你把 Method 设置为 post，连贯到 http response 就创立了后端接口；当设置为 get 申请，并连贯 template 写上 html 模版，并连贯到 http response 就创立了 web 服务。
尽管这种形式创立 web 服务难以使用 react 或 vue 框架，不过自定义节点还是为其发明了可能性，或者真的能够把前端模块化文件定义为节点互相串联。
http response
http 返回，只能对接 http in 的输入，总是与 http in 成对应用。
如果只用了 http in 但没有用 http response，就相当于后端代码里解决了申请，但没有调用相似：
res.send("hello word");来向客户端发送内容。
http request
与 http in 创立一个 http 服务不同，http request 间接发送一个网络申请并将返回值导入到输入节点。
视频中获取天气的例子，就用了 http request 发动申请获取天气信息：
不难看出，发送申请后，又应用了 function 节点解决返回后果。不过在逻辑编排中还是冀望少应用 function 节点，因为除非有很好的命名，否则难以看进去节点含意，如果 function 解决内容过多或者 function 区块过多，就失去了逻辑编排的意义。
序列
序列是对数组进行解决的节点。
split
对应代码的 split，将字符串变为数组。
join
对应代码的 join，个别与 split 配合应用，不便解决字符串。
sort
对应代码 sort，只能依据 key 做简略的升序降序解决，对于简略场景比拟不便，但对于简单场景可能还会应用 function 节点代替。
batch
批量接管输出流后，依据数量进行打包后对立输入，等于批量打包，能够依照数量或者工夫距离进行分组：
解析
很容易了解，专门解决上述格局的数据，并依照数据特色输入，比方 csv 数据，能够每行一条音讯的形式输入，或者打包为一个大数组以一条音讯输入。
当然也能够被 function 节点代替，那么解析形式与输入形式都能够自定义。
存储
长久化存储，个别存储为文件。
file
输入为文件。
file in
以文件作为输出，并将文件后果作为输入。
watch
监听目录或文件的批改。
精读
看了下面 node-red 性能后，置信你对逻辑编排曾经有较为体系化的意识了。
逻辑编排的目标是为了让非研发人群也能够疾速上手研发工作，因而注定是为 paas 工具服务的，而逻辑编排到底好不好用，取决于节点性能是否齐备，以及各节点之间通信是否顺畅，像 node-red 逻辑编排计划，在齐备性上做的较为成熟，能够说只有熟练掌握了几个外围节点规定，应用起来还是十分提效的。
逻辑编排也有人造毛病，就是当所有节点都进化为 function 节点后，会存在两个问题：
- 所有节点都是
function节点，即使有阐明，但外部实现逻辑十分自在，导致逻辑编排无奈起到束缚输入输出的作用。 - 进化到代码函数式调用，实质上与写代码无异。逻辑编排之所以提效，很大水平上是我要的业务逻辑刚好与节点性能匹配，以低成本 UI 配置的形式实现效率才高。
然而这也是有解决办法的，如果你的业务无奈被现有的逻辑编排节点满足，你能够尝试形象一下，本人梳理出业务罕用的节点，并用正当的配置封装，只有罕用业务逻辑能够被封装为逻辑节点，逻辑编排就还有为业务提效的空间。
总结
逻辑编排是一种极其，即用 UI 形式形容通用业务逻辑，升高非专业开发人员的上手门槛。通过对 node-red 的剖析能够发现，一个较为齐备的逻辑编排零碎还是能带来价值的。
然而针对非专业开发人员降本提效还有一种极其，就是齐全代码化，然而把代码模块化、函数库、工具链甚至低代码平台建设的十分齐备，以至于写代码的效率基本不低，这条路走到极致也不错，因为既然要深刻开发零碎，同样是投入工夫学习，为什么学习写代码就肯定比学习拖拽 UI 效率低呢？如果有高度封装的函数与工具辅助，效率不见得比 UI 拖拽来的低。
然而 node-red 在创立前端 UI 的模版上还能够再加强一下，把 template 从节点降级为 UI 搭建画布，逻辑编排仅用来解决逻辑，这样对大型全栈我的项目的前端开发体验会更好。
探讨地址是：精读《低代码逻辑编排》· Issue #319 · dt-fe/weekly
如果你想参加探讨，请 点击这里 ，每周都有新的主题，周末或周一公布。前端精读 – 帮你筛选靠谱的内容。
关注 前端精读微信公众号
版权申明：自在转载 - 非商用 - 非衍生 - 放弃署名（创意共享 3.0 许可证）
