Draft client interface

[bergundy]

No description provided.

[mjameswh]

isSync: Why a method rather than a readonly field? And how would you generally expect this to be implemented by the framework or library providing the client?

[bergundy]

E  77 ▎ isSync: this is ClientStartOperationResultSync<T>;     ■ A type predicate is only allowed in return type position for functions and methods.

[mjameswh]

Yeah, but it could have been just a bool property, hardcoded to either true or false in the variants. That would make it a type determinant by itself, so no need for a type predicate.

I don't really mind, but the problem with current approach is that tsc can't assert that function creating a ClientStartOperationResult(Sync|Async) is self-coherent, whereas a boolean property would implicitly assert that.

[bergundy]

Ah, good point, I can just change to isSync: false and isSync: true.

[mjameswh]

Here, it's called inboundLinks, but in Result, it is only links.

[bergundy]

Good point, we should be consistent. Thanks.

[mjameswh]

outboundLinks?

[mjameswh]

Given the current design, I think it would make more sense for this property to be optional.

I mean, if having Client only as abstraction, that means implementers will be responsible for producing objects of this interface. And therefore, adding new required properties to this interface at a later time would be breaking. So we'll instead make new properties be optional, and links will therefore adhere to a different semantic than other properties added later.

[bergundy]

Making this optional would put the burden of null checks on the consumer and I'd rather avoid that.

[mjameswh]

Making this optional would put the burden of null checks on the consumer and I'd rather avoid that.

I know, and so would I. Yet, this is what we'll have to do for all other properties added going forward if we don't want to break existing Client implementations in the future.

That is, unless we make the Nexus RPC library itself ensure normalization of the return value.

[bergundy]

Agree, but at least for now it's part of the established contract. This concern will come into play if this contract is extended though.

I would consider introducing a transport abstraction and wrapping the transport's results in the client as you suggested.