For information on using the Fabric Gateway, including client API documentation, please visit the Fabric Gateway documentation.
For information on reporting issues, suggesting enhancements and contributing code, please review the contributing guide.
The original proposal is described in the Fabric Gateway RFC. Adding a gateway component to the Fabric peer provides a single entry point to a Fabric network, and removes much of the transaction submission logic from the client application.
The Gateway component in the Fabric Peer exposes a simple gRPC interface to client applications and manages the lifecycle of transaction invocation on behalf of the client. This minimises the network traffic passing between the client and the blockchain network, as well as minimising the number of network ports that need to be opened.
See the gateway.proto file for details of the gRPC interface.
This repository comprises three functionally equivalent client APIs, written in Go, Typescript, and Java. In order to build these components, the following need to be installed and available in the PATH:
In order to run any of the Hardware Security Module (HSM) tests, SoftHSM v2 is required. This can either be:
- installed using the package manager for your host system:
- Ubuntu:
sudo apt install softhsm2
- macOS:
brew install softhsm
- Windows: unsupported
- Ubuntu:
- or compiled and installed from source, following the SoftHSM2 install instructions
- It is recommended to use the
--disable-gost
option unless you need gost algorithm support for the Russian market, since it requires additional libraries.
- It is recommended to use the
This project includes a Dev Container configuration that includes all of the pre-requisite software described above in a Docker container, avoiding the need to install them locally. The only requirement is that Docker is installed and available.
Opening the project folder in an IDE such as VS Code (with the Dev Containers extention) should offer the option of opening in the Dev Container. Alternatively, VS Code allows the remote repository to opened directly in an isolated Dev Container.
Note: When the repository is first cloned, some mock implementations used for testing will not be present and the Go code will show compile errors. These will be generated when the
unit-test
target is run, or can be generated explicitly by runningmake generate
.
The following Makefile targets are available:
make generate
- generate mock implementations used by unit testsmake lint
- run linting checks for the Go codemake unit-test-go
- run unit tests for the Go client API, excluding HSM testsmake unit-test-go-pkcs11
- run unit tests for the Go client API, including HSM testsmake unit-test-node
- run unit tests for the Node client APImake unit-test-java
- run unit tests for the Java client APImake unit-test
- run unit tests for all client language implementationsmake pull-latest-peer
- fetch the latest peer docker image containing the gateway servermake scenario-test-go
- run the scenario (end to end integration) tests for Go client API, including HSM testsmake scenario-test-go-no-hsm
- run the scenario (end to end integration) tests for Go client API, excluding HSM testsmake scenario-test-node
- run the scenario tests for Node client API, including HSM testsmake scenario-test-node-no-hsm
- run the scenario tests for Node client API, excluding HSM testsmake scenario-test-java
- run the scenario tests for Java client APImake scenario-test
- run the scenario tests for all client language implementationsmake scenario-test-no-hsm
- run the scenario tests for all client language implementations, excluding HSM testsmake shellcheck
- check for script errorsmake test
- run all testsmake format
- fix all code formatting
The scenario tests create a Fabric network comprising two orgs (one peer in each org) and a single gateway within a set of docker containers. The clients connect to the gateway to submit transactions and query the ledger state.
The tests are defined as feature files using the Cucumber BDD framework. The same set of feature files is used across all three client language implementations to ensure consistency of behaviour.
The documentation site is built using Material for MkDocs. Documentation build configuration is in mkdocs.yml, and the site content is in the docs folder.