fabric-sdk-go vs fabric-gateway. When to use each one?

Nikos Karamolegkos

Hello, I am using HLF 2.2 or 2.3 and I have seen that are two types of SDK. The first one is the high level SDK (fabric-gateway, fabric-gateway-java etc) and the second one is the low level SDK (fabric-sdk-go, fabric-sdk-java). I know that the gateway functionality can be used to invoke transactions to ledger and the low level SDK is useful for making management operation to the network (add channel, create user, join channel etc). Is that absolutely correct?

Also, in this example I can see that the RegisterUser is using the low level SDK too (i.e import org.hyperledger.fabric.sdk.Enrollment,
import org.hyperledger.fabric.sdk.User) and an fabric_ca (i.e import org.hyperledger.fabric_ca.sdk.HFCAClient) related SDK (but I can not find anywhere). Is that correct?

Nikos Karamolegkos
R & D engineer at ICS-FORTH
Telecommunications and Networks Lab (TNL)

Mark Lewis

Fabric started out with what are often now called the "low-level" SDKs, like fabric-sdk-java (for Java) and fabric-client (for Node). These have a lot of code and complexity in them but really don't provide an application developer with a whole lot more than a language-specific implementation of the gRPC network calls. The application developer still has to understand quite a lot about how endorsement and transaction submission works in Fabric, and to orchestrate a lot of that flow themselves through the low-level APIs. I would set fabric-sdk-go a little apart from the Java and Node low-level SDKs as it does have higher level abstractions that place less burden on the application developer. The Go SDK is just different in style and implementation to the other language SDKs.

The high-level APIs were introduced to provide a simpler API focused on the needs of a business application to update and query the ledger (by submitting and evaluating transactions) and to respond to events, rather than just exposing the nuts and bolts of Fabric implementation. This reduces the burden on application developers by removing the need for large amounts of boiler-plate code, that could easily (and frequently is) the source of application bugs. This Fabric programming model also provides a more consistent API across programming languages, based on the "Gateway", and is implemented in Node, Java and Go SDKs on top of the existing "low-level" SDKs. The new Fabric Gateway API for Fabric v2.4 takes this further by moving much of the common logic to a Gateway service within the peer, leaving much thinner (and even more consistent) language-specific client APIs in Go, Node and Java.

With the high-level APIs came in a shift in focus for the SDKs to supporting runtime business applications, and a shift away from trying to provide multiple language bindings for admin operations. Admin operations only exist in the old low-level APIs, but continue to be well supported and actively maintained as CLI commands.

The samples you point to are using the low-level SDKs for admin operations, including enrollment with the CA. The HFCAClient you mention is part of fabric-sdk-java. You absolutely don't need to (and really shouldn't) create identities and enroll users every time you run your client application, despite may of the samples doing this. You don't need to use the SDKs to do enrollment either. You may be better using the CLIs or, if using your own CAs, whatever tooling it provides for enrollment.

Nikos Karamolegkos

Nice, thank you. I conclude that for admin operation I have to use the low level SDKs only.