PoC: trying papi #118
PoC: trying papi #118
Conversation
| @@ -54,6 +55,9 @@ export async function setIdentityThenRequestAndProvideJudgement< | |||
| >(peopleChain: Chain<TCustom, TInitStorages>) { | |||
| const [peopleClient] = await setupNetworks(peopleChain) | |||
There was a problem hiding this comment.
When considering using PAPI in tests, in general, will we also want to keep this kind of call alongside the ones you introduce below? We will effectively have 2 clients available during testing.
There was a problem hiding this comment.
people can choose pjs or papi to use when writing a test and in the unlikely case, they can write tests using both.
There was a problem hiding this comment.
From what I understand, <pjs_client_name>.dev.{newBlock, setStorage, timeTravel, setHead} are wrappers over WebSocket calls to RPC endpoints that chopsticks-utils layers on top of the "real" node.
- Do you think it makes sense to offer the same functionality for PAPI clients in
chopsticks, - Or is it extraneous work, and for the time being this can remain available via PJS clients? E.g. tests using PAPI may rely on PJS clients for
chopsticks-specific endpoints (new block, set storage, etc).
There was a problem hiding this comment.
Do you think it makes sense to offer the same functionality for PAPI clients in chopsticks,
No. It wouldn't make any difference.
Or is it extraneous work, and for the time being this can remain available via PJS clients? E.g. tests using PAPI may rely on PJS clients for chopsticks-specific endpoints (new block, set storage, etc).
The usage is completely hidden and shouldn't matter at all. People can use them and yes it may indirectly depends on pjs but who cares?
In fact, it will be a good idea to write those to invoke the chain API directly, instead of using websocket calls (AcalaNetwork/chopsticks#861)
No description provided.