Migrate fabric-samples to use Gateway SDKs

[jt-nti]

The following samples should be extended with gateway app samples. We don't need to have a full matrix of all samples in a languages however. Items with a 'P' are initial priorities for this work item. Add your name next to an item if you intend to pick it up.

Higher priority

• asset-transfer-basic (demonstrates transaction submit / evaluate, submit error capture)
  • Typescript - P1 - Saptha
  • Java - P2 - Deepti
  • Go - P2 - Saptha
• asset-transfer-events (demonstrates chaincode events)
  • Typescript - P3 - Saptha
  • Java - P3 - Deepti
  • Go - P3 - Mark
• asset-transfer-private-data (demonstrates auto-magic handling of endorsement with private data collections)
  • Typescript - P4 - Saptha
  • Java - P4
  • Go - P4
• asset-transfer-secured-agreement (demonstrates auto-magic handling of state-based endorsement)
  • Typescript - P4 - Saptha
  • Java
  • Go
• off_chain_data (demonstrates block eventing, checkpointing)
  • TypeScript - Mark
  • Java - Mark
  • Go
• full-stack-asset-transfer-guide trader application
  • Go
  • Java

Lower priority

• asset-transfer-ledger-queries
  • Typescript - P5
  • Java
  • Go
• asset-transfer-sbe
  • Typescript - P5
  • Java
  • Go

What about other samples? For example the old fabcar samples and commercial paper?

[bestbeforetoday]

Unless other samples are demonstrating API usage not already covered by the asset-transfer samples, I vote we skip them. In fact, I think we'd be better actively removing the legacy samples from the main branch and just leave them in the older release branches. They just cause confusion for end users.

[bestbeforetoday]

Should this issue also include removing the samples included in this repository? Maintaining one set of samples seems like a better use of resources and less confusing for users. We would need to be sure that there is still a sample demonstrating features like off-line signing (if there isn't already one in fabric-samples).

[deeptiraom]

@denyeart Could you please assign the issue to me?

[deeptiraom]

Currently I am working on the below:

asset-transfer-basic
Java

[deeptiraom]

I have done the following so far:

• created a directory which mirrors application-java under asset-transfer-basic folder
• made changes to App.java using the samples under fabric-gateway
• Need to make further changes to EnrollAdmin and RegisterUser understanding the code in fabric gateway samples
• as a next step I will build the code with all changes

[denyeart]

@deeptiraom In the typescript sample for gateway, we decided to simply re-use the test-network credentials instead of Enroll/Register new credentials. We could do the same for Java. See https://github.com/hyperledger/fabric-samples/blob/main/asset-transfer-basic/application-gateway-typescript/src/app.ts

[sapthasurendran]

@denyeart I have completed the basic-asset-transfer-basic go samples migration.

[deeptiraom]

I am picking this up again after a weeks training from Dec 13-Dec 16

[denyeart]

@bestbeforetoday To respond to your earlier Sept 22 points, I think this is where we landed:

• Remove the existing samples from fabric-gateway repo (these were used during initial alpha/beta dev only)
• The new asset transfer gateway SDK app samples in fabric-samples will live next to the legacy SDK asset transfer app samples, but all docs, tutorials, etc should point people to the new gateway app samples only.
• Eventually the old asset transfer app samples should be deleted (maybe 1 year co-existence?)
• Other outdated samples such as fabcar and everything in /chaincode directory should be deleted even sooner, since we've already had about 1 year overlap with the newer asset transfer samples.
• Developing Applications doc that utilized Commercial Paper will be removed and/or revamped as part of Refactor Developing Applications documentation fabric#2983 / Update App Developer flow fabric#3157 , but keep Commercial Paper sample itself as a good industry example.

What do you think @bestbeforetoday @lehors ?

[lehors]

Thanks for giving me a chance to chime in on this @denyeart .

I agree with the overall gist of this but rather than having the new gateway samples be added under a new name as in "asset-transfer-basic/application-gateway-go" I would much rather rename the old one to something like "asset-transfer-basic/application-legacy-go" and put the new version under the old name.

This is so that: 1) it is clear what samples people should really follow, 2) when we eventually get to retire the legacy stuff we don't have all these names with "-gateway-" in them.

I realize that some of the new stuff has already been added under the new names but this can easily be fixed. I'm happy to submit a PR if that helps.