Creating this ticket to track discussion/prioritization around whether we want to enable TRAPI input to our python client.
The node.js client that accepts TRAPI created in #136 is good, but support in our python client could be an easier way to use for some. Our hosted version of the node.js client at https://api.bte.ncats.io conveniently accepts TRAPI input, but as noted at the ongoing Translator Relay, heavy usage can lead to 50x errors. Efficiently scaling any centralized query resource to heavy usage will be a challenge for any hosted solution. The fact that BTE can be run in a completely decentralized way is a somewhat unique feature of BTE relative to other ARA solutions, so we might want to highlight this more by accepting TRAPI.
(Also noting that another advantage of the python client is the ability to see a running log of execution status via the verbose tag. I don't see an easy way to do this via the node.js app...)
Obviously we need to weigh the benefit vs the cost of implementation...
Creating this ticket to track discussion/prioritization around whether we want to enable TRAPI input to our python client.
The node.js client that accepts TRAPI created in #136 is good, but support in our python client could be an easier way to use for some. Our hosted version of the node.js client at https://api.bte.ncats.io conveniently accepts TRAPI input, but as noted at the ongoing Translator Relay, heavy usage can lead to 50x errors. Efficiently scaling any centralized query resource to heavy usage will be a challenge for any hosted solution. The fact that BTE can be run in a completely decentralized way is a somewhat unique feature of BTE relative to other ARA solutions, so we might want to highlight this more by accepting TRAPI.
(Also noting that another advantage of the python client is the ability to see a running log of execution status via the
verbosetag. I don't see an easy way to do this via the node.js app...)Obviously we need to weigh the benefit vs the cost of implementation...