网关编程模型是新常态吗？
Is Gateway Programming Model the New Normal?
所以我一直在尝试使用 Hyperledger Fabric Client SDK for Go 中的网关包以外的包查找教程和示例。我只找到了几个旧的； 1.4 之前。此外，Hyperledger Fabric 文档完全专注于网关模型。
这让我想到了标题中的问题。这对我来说很有意义，因为我看不到使用 SDK 创建通道和部署链代码的价值。因为我们仍然有管理任务要在 CLI 上完成；准备通道配置文件和通道创建交易，更不用说编写链代码了。
最近是否达成共识，完全在 CLI 上执行管理任务（创建通道、加入节点和部署链代码），并将带有网关模型的 SDK 专用于链代码交互？
我们发现有很多人采用“不良”做法，试图在同一个客户端应用程序中混合管理和运行时任务。我们还在所有 SDK 中复制了管理功能，它在长期维护方面根本无法很好地扩展。
网关模型旨在简化与 Fabric 网络的运行时交互。需要大量可重复的“gorp”（收集背书，发送给订购者），对于大多数用户来说最好包装在网关中（有低级 API 可供需要的人使用）。
但是，我们确实为那些希望为订购者和渠道管理创建自定义工具的人提供 Fabric Config API in Go。
所以我一直在尝试使用 Hyperledger Fabric Client SDK for Go 中的网关包以外的包查找教程和示例。我只找到了几个旧的； 1.4 之前。此外，Hyperledger Fabric 文档完全专注于网关模型。
这让我想到了标题中的问题。这对我来说很有意义，因为我看不到使用 SDK 创建通道和部署链代码的价值。因为我们仍然有管理任务要在 CLI 上完成；准备通道配置文件和通道创建交易，更不用说编写链代码了。
最近是否达成共识，完全在 CLI 上执行管理任务（创建通道、加入节点和部署链代码），并将带有网关模型的 SDK 专用于链代码交互？
我们发现有很多人采用“不良”做法，试图在同一个客户端应用程序中混合管理和运行时任务。我们还在所有 SDK 中复制了管理功能，它在长期维护方面根本无法很好地扩展。
网关模型旨在简化与 Fabric 网络的运行时交互。需要大量可重复的“gorp”（收集背书，发送给订购者），对于大多数用户来说最好包装在网关中（有低级 API 可供需要的人使用）。
但是，我们确实为那些希望为订购者和渠道管理创建自定义工具的人提供 Fabric Config API in Go。