说说前几天给rill flow合的一个3万多行diff的pull request。
这个pr的功能很明确，就是给开源版的rill flow增加“通过界面拖拽生成一个流程”的功能。
用当下时髦的大模型应用举例，比如在后台里点一点，就能生成从某个网页获取文本，通过gpt总结成中文，检索相关图片，再发条微博这种流程。
已经有不少大模型编排系统都实现了类似的功能，我们作为一个流程编排框架，更加不可能不支持可视化的流程编辑。
但是这个功能为什么延期了这么久呢，很大一个原因是代码集成的问题。
目前的rill flow项目大部分功能（包括绝大多数大厂开源项目），维护的方式都是开源核心项目，内部再对应一个适配项目，来保证开源项目能用更低的成本适配内网。
但是rill flow的前端之前没有用这套机制，因为内网前端跟业务深度耦合，所以开源的时候没有共用，而是选择了重写，内外网的前端模块基本没什么关系。
初期几个简单功能还问题不大，到了流程编辑这样的复杂模块的时候，重写的工作就变得异常艰难：内外网的前端甚至没有用相同的技术栈（他们之间隔了四年，对前端来说，已经换了无数代框架）。
而最痛苦的是，原先我们用的流程图框架已经不维护了，没有适配到新的这套基础组件上，要从基础的画图功能重新开发。
在我们意识到“我们没有能力同时维护两个复杂的前端模块”的时候，我们决定做一轮技术改造，用微前端的方式复用流程编辑功能。
“有点类似iframe，但是数据通信和限制（比如说跨域）比iframe好很多”，最初的时候我们是这么以为的。
但是微前端毕竟不是一个广泛应用的标准，集成的过程中出现了很多意想不到的情况，几乎每天项目都会被集成过程中的新问题block掉。以至于我们最后已经放弃自己解决问题了，专门给公司的前端同学买了好几杯咖啡，才把这次改造落地。
因为迭代时间过长，中间的改造点过多，在不增加工作量的前提下很难单独拆分某个子功能提pr，所以最后看到的，就是这么个几万行的超级大pr。
希望以后都不要再有人跟我提这种pr了……
这个pr的功能很明确，就是给开源版的rill flow增加“通过界面拖拽生成一个流程”的功能。
用当下时髦的大模型应用举例，比如在后台里点一点，就能生成从某个网页获取文本，通过gpt总结成中文，检索相关图片，再发条微博这种流程。
已经有不少大模型编排系统都实现了类似的功能，我们作为一个流程编排框架，更加不可能不支持可视化的流程编辑。
但是这个功能为什么延期了这么久呢，很大一个原因是代码集成的问题。
目前的rill flow项目大部分功能（包括绝大多数大厂开源项目），维护的方式都是开源核心项目，内部再对应一个适配项目，来保证开源项目能用更低的成本适配内网。
但是rill flow的前端之前没有用这套机制，因为内网前端跟业务深度耦合，所以开源的时候没有共用，而是选择了重写，内外网的前端模块基本没什么关系。
初期几个简单功能还问题不大，到了流程编辑这样的复杂模块的时候，重写的工作就变得异常艰难：内外网的前端甚至没有用相同的技术栈（他们之间隔了四年，对前端来说，已经换了无数代框架）。
而最痛苦的是，原先我们用的流程图框架已经不维护了，没有适配到新的这套基础组件上，要从基础的画图功能重新开发。
在我们意识到“我们没有能力同时维护两个复杂的前端模块”的时候，我们决定做一轮技术改造，用微前端的方式复用流程编辑功能。
“有点类似iframe，但是数据通信和限制（比如说跨域）比iframe好很多”，最初的时候我们是这么以为的。
但是微前端毕竟不是一个广泛应用的标准，集成的过程中出现了很多意想不到的情况，几乎每天项目都会被集成过程中的新问题block掉。以至于我们最后已经放弃自己解决问题了，专门给公司的前端同学买了好几杯咖啡，才把这次改造落地。
因为迭代时间过长，中间的改造点过多，在不增加工作量的前提下很难单独拆分某个子功能提pr，所以最后看到的，就是这么个几万行的超级大pr。
希望以后都不要再有人跟我提这种pr了……
