不同的脚本怎么用 about comfy-server

[jinkexue]

没看到不同脚本的用法。文生图和图生图如果不是用不同脚本写的话 那就没有任何价值。comfyui本身的价值就在于工作流。而不是直接暴露功能出来使用。因为需求本身不一样。理论上只需要关心输入和输出。

你是指不同工作流节点中，在客户端用法吗？客户端应该是看不到后端的功能的

测试了下server,有几个地方不知能否简化
1.工作流转化为api有点麻烦
2.前端搞个通用模板
3.云端部署简化

[sun96013]

没看到不同脚本的用法。文生图和图生图如果不是用不同脚本写的话 那就没有任何价值。comfyui本身的价值就在于工作流。而不是直接暴露功能出来使用。因为需求本身不一样。理论上只需要关心输入和输出。

你是指不同工作流节点中，在客户端用法吗？客户端应该是看不到后端的功能的

测试了下server,有几个地方不知能否简化 1.工作流转化为api有点麻烦 2.前端搞个通用模板 3.云端部署简化

因为一般的工作流都是输入一个文字或者图片然后返回一个具体的图片。那么只需要给一个入参和出参就可以了。但是博主给了具体的抠图什么的方法。这个不是应该归为节点功能吗？如果真的好用的server要么直接把脚本细化到每个参数。比如对应一个工作流，可以调整每个参数。要么就是只关注出入参。所有参数内容写死。那也就没有意义了。最好的方式是如何采集到工作流节点的选项然后转换成程序上的选项。然后给到用户去测试。给到api用户去参照。这才是最大的价值所在。也省了文档。比如我上传一个工作流，后台自动把工作量转化成文档或者直接生成可以post测试的页面。然后再高阶一点就是生成对应的语言代码。参照postman code部分的实现。

[bobvinch]

没看到不同脚本的用法。文生图和图生图如果不是用不同脚本写的话 那就没有任何价值。comfyui本身的价值就在于工作流。而不是直接暴露功能出来使用。因为需求本身不一样。理论上只需要关心输入和输出。

你是指不同工作流节点中，在客户端用法吗？客户端应该是看不到后端的功能的
测试了下server,有几个地方不知能否简化 1.工作流转化为api有点麻烦 2.前端搞个通用模板 3.云端部署简化

因为一般的工作流都是输入一个文字或者图片然后返回一个具体的图片。那么只需要给一个入参和出参就可以了。但是博主给了具体的抠图什么的方法。这个不是应该归为节点功能吗？如果真的好用的server要么直接把脚本细化到每个参数。比如对应一个工作流，可以调整每个参数。要么就是只关注出入参。所有参数内容写死。那也就没有意义了。最好的方式是如何采集到工作流节点的选项然后转换成程序上的选项。然后给到用户去测试。给到api用户去参照。这才是最大的价值所在。也省了文档。比如我上传一个工作流，后台自动把工作量转化成文档或者直接生成可以post测试的页面。然后再高阶一点就是生成对应的语言代码。参照postman code部分的实现。
1.对于工作流暴露什么参数取决于自己的API设计，理论上大多数参数都可以保持默认状态，需要修改再去修改
2.前端在很多场景，特别是有复杂的业务需求而不是套壳网站的时候，调用ComfyUI的业务逻辑非常繁琐
3.同时前端调用ComfyUI还需要把工作流打包到前端，对于很多公司存在工作流商业机密外溢的风险，这都是我们实实在在做商业项目的经验
4.顺便提供了很多商业应用的通用接口和能力

[sun96013]

没看到不同脚本的用法。文生图和图生图如果不是用不同脚本写的话 那就没有任何价值。comfyui本身的价值就在于工作流。而不是直接暴露功能出来使用。因为需求本身不一样。理论上只需要关心输入和输出。

你是指不同工作流节点中，在客户端用法吗？客户端应该是看不到后端的功能的
测试了下server,有几个地方不知能否简化 1.工作流转化为api有点麻烦 2.前端搞个通用模板 3.云端部署简化

因为一般的工作流都是输入一个文字或者图片然后返回一个具体的图片。那么只需要给一个入参和出参就可以了。但是博主给了具体的抠图什么的方法。这个不是应该归为节点功能吗？如果真的好用的server要么直接把脚本细化到每个参数。比如对应一个工作流，可以调整每个参数。要么就是只关注出入参。所有参数内容写死。那也就没有意义了。最好的方式是如何采集到工作流节点的选项然后转换成程序上的选项。然后给到用户去测试。给到api用户去参照。这才是最大的价值所在。也省了文档。比如我上传一个工作流，后台自动把工作量转化成文档或者直接生成可以post测试的页面。然后再高阶一点就是生成对应的语言代码。参照postman code部分的实现。
1.对于工作流暴露什么参数取决于自己的API设计，理论上大多数参数都可以保持默认状态，需要修改再去修改
2.前端在很多场景，特别是有复杂的业务需求而不是套壳网站的时候，调用ComfyUI的业务逻辑非常繁琐
3.同时前端调用ComfyUI还需要把工作流打包到前端，对于很多公司存在工作流商业机密外溢的风险，这都是我们实实在在做商业项目的经验
4.顺便提供了很多商业应用的通用接口和能力

既然想要通用那就不存在什么机密问题。这个跟webapi 是一样的。暴露给你的你能用 给你文档。不暴露给你的 不给你文档你也不知道怎么用。首先要想好开源项目做的目的是什么解决什么痛点。只有解决痛点才有意义。而且 comfyui本身就有接口能力。如果不做差异化，那项目侧重点又是什么。

[jinkexue]

现在这个工作流转api非常繁琐，为方便不同的工作流Json，可否参考mixlab的处理方法? 1.可以快速在设计阶段就做好哪些参数需要输入2. 自动生成前端页面

[bobvinch]

现在这个工作流转api非常繁琐，为方便不同的工作流Json，可否参考mixlab的处理方法? 1.可以快速在设计阶段就做好哪些参数需要输入2. 自动生成前端页面

建议很好，新版已经支持，自定义工作流：上传工作流，设置参数就可以转换成API进行调用