Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FFI supported types incomplete #94

Open
DerekJarvis opened this issue Aug 4, 2022 · 0 comments
Open

FFI supported types incomplete #94

DerekJarvis opened this issue Aug 4, 2022 · 0 comments

Comments

@DerekJarvis
Copy link
Contributor

Target State:

Firefly utilizes a proprietary interface format (FFI) for exposing smart contracts through swagger web APIs. The FFI contains information to allow the API to self-document the parameters needed for contract calls and validate them before sending the contract.

Current State:

The buildFabconnectRequestBody function in the core firefly repository serializes the request as JSON and provides the metadata from the FFI to fabconnect. The processArgs function utilizes the https://github.com/xeipuuv/gojsonschema library to perform validation of a go object against a schema (from FFI).

Problem:

The current implementation only allows string or object types to be provided as top level properties. This requires treating all parameters as string or object types. This can be seen in the FFI provided for the PinBatch command which treats the contexts property which is actually a string array as just a string. This validation is successful, because the array is passed as stringified JSON.

Also consider that the Fabric Go SDK will automatically manage converting the stringified JSON into the correct parameters types for a function. This means that if the stringified JSON is valid, then there will be no issues and the contract will execute correctly. If the stringified JSON is invalid, the error will be thrown by the contract, and not by the API itself.

This results in a bad user experience because a user may expect more detailed information to be given by the API if input is malformed. The user needs to fetch the results of the transaction from firefly in order to see the error thrown by the contract, or even inspect the chaincode container logs to see the detailed error message - which may not be available to the user.

This also results in a performance hit with chaincode execution cycles being spent on transactions that could have been rejected at the API level instead of the chaincode level.

Suggested Solution:

Fully utilize the JSON validation provided by the gojsonschema library to perform detailed validation of data being passed through the API.

Justification for Solution:

This would provide a smoother user experience, and potentially improve network performance by prevent bad calls from getting into the pipeline at all.

Also, this would allow code generation tools to generate strongly typed FFI definitions from fabric contracts to avoid duplicated effort.

Attempted Solution:

See Pull Request: #93

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant