You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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. TheprocessArgs
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
orobject
types to be provided as top level properties. This requires treating all parameters asstring
orobject
types. This can be seen in the FFI provided for the PinBatch command which treats thecontexts
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
The text was updated successfully, but these errors were encountered: