soroban-cli: typescript bindings and client modularity

[leighmcculloch]

This issue was originally discussed in Slack (slack thread) and started by @tomerweller. Moving some snippets of discussion captured over into GitHub issue for more async and further discussion.

@tomerweller: I wonder if there’s a modularity (or lack-thereof) issue with the current build/simulate/sign/send flow in ts-bindings. What if I want to skip simulate? For example if I want to manually fill in footprint/fees/auth? Or use a cached version of these from a similar past invocation?

@leighmcculloch: There's a break up of actions at the layer below the generated code. The SorobanClient can be used to build a tx for an invocation, to do simulation, and submit, and those three actions are independent.

At some point we talked about there being a variety of flows for the CLI such as:

1. Only simulate
2. Only submit
3. Simulate and submit
4. Simulate and maybe submit (if footprint is write, or if events written)

The same principles would apply in the JS/TS.
But it's helpful for us to have some good default behavior, which I think is (4).
It looks like the generated TS bindings have support for (1) and (4) at the moment via the responseType field.

@leighmcculloch: I think once the tx is built, the logic no longer needs to be part of the generated bindings. The specialty of the generated bindings is really focused on knowing what fn to call, and needing to turn that into a tx. And beyond that we could build all those other flows on a tx. So that all workflows operate around the build tx step. Something like:

My comment above is a little too simplified, as @chadoh has pointed out in the slack there there's other logic currently tied up in the assembled transaction like automatic backoff for sending, rebuilding and resimulating for resending. But I think across both the CLI and the TS bindings, and in general the way the JS and other clients are structured, we need to maintain some modularity so that folks can do all of the things above, and modify state between any of them.

This was originally discussed at the end of November, so if we've already moved on from here and this is out-of-date I can close it. I'm opening this issue to capture the need for us to evaluate if we have sufficient modularity, and if we provide the above different ways to interact with the network/soroban, and to dig into this further if we aren't quite there yet.

I think this issue belongs to the soroban-cli, typescript bindings, and the JS SDK.

cc @chadoh @willemneal @piyalbasu @jeesunikim @Shaptic

[piyalbasu]

I tend to agree with allowing more modularity. One benefit is allowing easier integration with other wallets. Right now, TS bindings are expecting a very Freighter-like API for wallets to sign, which could be limiting in the future.

However, as someone who was just tinkering, I did also like having the option of just being able to simply call (as an example from the docs) incrementor.increment() to simulate and then incrementor.signAndSend() to sign with Freighter and send it off. As someone who was just trying to get a demo working, I liked being able to already have both the freighter-api integration as well as the rebuild/resimulate/resend "out of the box." I think there's value in having both the fast and easy, we'll-do-it-all-for-you path for newbies, while also having a more modular approach when you're ready to graduate to doing things one piece at a time.

Related: maybe it's worth building an option for the rebuild/resimulate/resend logic into stellar-sdk so users aren't relying on the TS bindings to do that for them. It would make it easier for a dev to move from Option 4 above to a more modular approach if they had fewer pieces of retry logic to worry about.

[leighmcculloch]

maybe it's worth building an option for the rebuild/resimulate/resend logic into stellar-sdk so users aren't relying on the TS bindings to do that for them

I believe this issue is doing that 🥳 :

• Add generation of contract clients and an AssembledTransaction abstraction js-stellar-sdk#891 (comment)

(cc @chadoh please correct me if I'm wrong about that)