Fabric-gateway-java vs fabric-gateway(this repo)

[SRiera98]

Hello, i'm starting in the world of Hyperledger Fabric and i don't finish to understand what's the difference between the java alternative of this repository and this other repository: https://github.com/hyperledger/fabric-gateway-java. I about to start a development (MVP), and i need to choose what tool is best for a java dev.

[andrew-coleman]

The APIs in this repository are used to create Fabric v2.4.x client applications. If you are starting a new project, you should use this one. The other repository (fabric-gateway-java) is for older versions of Fabric.
They both support the 'gateway' programming model, but the later one (in this repo) targets the new gateway service in the peer as described in https://hyperledger-fabric.readthedocs.io/en/release-2.4/gateway.html

[SRiera98]

Great, thank you both!. The fabric gateway API is only for interacting with hyperledger fabric ledger, right?. How about setup and configure the blockchain from the beginning?

[bestbeforetoday]

That's correct, this API is aimed at client applications interacting with an established ledger. Some of the legacy SDKs have varying levels of capability for admin operations, and there are some community-developed admin API implementations, like this one. The Fabric command-line tools provide a complete set of admin capability so that is probably what I would recommend using. There has been talk for a long time about reworking these CLI commands, backed by a programmatic API or perhaps RESTful services, but I can't immediately spot a current Fabric issue for that, so it's not something I expect to see appearing soon.

[bh4rtp]

Fabric-gateway-java validates the consistence of the endorsement responses byte by byte from 3 peers and results in failures. While node sdk does not tell any errors. Should we disable this byte level validation procedure? One more question, does fabric-gateway java do the same validation too?

[andrew-coleman]

One more question, does fabric-gateway java do the same validation too?

The gateway service in the peer does this validation as part of the Submit logic on behalf of the client.

[bestbeforetoday]

In the validation phase of the transaction flow, carried out by peers after a transaction has been committed in a block by the orderer, the endorsements will be checked to ensure they are consistent and meet the effective endorsement policy. If this criteria is not met, the transaction will be marked as invalid and will not update the ledger.

The legacy Node SDK implementation elected to skip client-side checking of the endorsements and just submitted the transaction with all successful endorsements to the orderer, accepting that the (hopefully minority) of cases where endorsements were not valid would be caught later in the validation checking, which will happen regardless. The legacy Java SDK elected to do a byte-for-byte comparison of endorsements at the client side and reject transactions before submitting to the orderer. The client side checking means errors are caught earlier in the flow and avoids unnecessary server-side work in the case of transactions that will fail validation due to mismatched endorsements, but imposes some additional overhead at the client end for all transactions.

With the Fabric Gateway client API, the Gateway service running in the peer handles all of this on behalf of the client, including more intelligent selection of the best peers for endorsement, and so is more likely to get a good set of endorsements. The Gateway service also ensures endorsements are consistent.