Is Gateway Programming Model the New Normal?

162 Views Asked by At

So I have been trying to find tutorials and examples using packages other than the gateway package from Hyperledger Fabric Client SDK for Go. I only found a couple old ones; before 1.4. Plus, the Hyperledger Fabric documentation is entirely focused on the gateway model.

That brought me to the question in the title. It made sense to me because I can't see the value in creating channels and deploying chaincodes using the SDK. Since we still have administrative tasks to be done on the CLI; preparing channel profile and channel creation transaction, let alone programming the chaincode.

Is there recently a common consensus to do administrative tasks (creating channels, join peers and deploying chaincodes) entirely on the CLI, and dedicate the SDK with the gateway model to chaincode interactions?

1

There are 1 best solutions below

0
On BEST ANSWER

We found that there were many people employing the "bad" practice of trying to mix administrative and runtime tasks in the same client applications. We were also duplicating admin functions in all the SDKs and it simply does not scale well in terms of long term maintenance.

The gateway model was designed to simplify runtime interactions with Fabric networks. There is a lot of repeatable "gorp" required (collect endorsements, send to orderer) which are best wrapped in the gateway for most users (there are low-level APIs available for those who need them).

We do, however, provide a Fabric Config API in Go for those who wish to create custom tools for orderer and channel management.