sample output from websocket subscribed to blocks and a single address:

ws open
msg {
  type: 'Tx',
  msgType: 'AddedToMempool',
  txid: 'ef1b7ec808e1fc287147ec50bf7faa5440e84bc008b77cfbbe4355222b373c6e'
}
msg {
  type: 'Block',
  msgType: 'Connected',
  blockHash: '00000000000000000024ec7b6cc66b9881dde1fe678865ef0bd1212573200e31',
  blockHeight: 817693
}
msg {
  type: 'Tx',
  msgType: 'Confirmed',
  txid: 'ef1b7ec808e1fc287147ec50bf7faa5440e84bc008b77cfbbe4355222b373c6e'
}
msg {
  type: 'Tx',
  msgType: 'Finalized',
  txid: 'ef1b7ec808e1fc287147ec50bf7faa5440e84bc008b77cfbbe4355222b373c6e'
}
msg {
  type: 'Block',
  msgType: 'Finalized',
  blockHash: '00000000000000000024ec7b6cc66b9881dde1fe678865ef0bd1212573200e31',
  blockHeight: 817693
}
msg {
  type: 'Block',
  msgType: 'Connected',
  blockHash: '00000000000000001275d86bc1db7ca84c27ec8e8e00d3d4ff26c37cfab4c191',
  blockHeight: 817694
}
msg {
  type: 'Block',
  msgType: 'Finalized',
  blockHash: '00000000000000001275d86bc1db7ca84c27ec8e8e00d3d4ff26c37cfab4c191',
  blockHeight: 817694
}
msg {
  type: 'Block',
  msgType: 'Connected',
  blockHash: '00000000000000000b16da75478a2af65e9a984864fa328038dc0260488ccee2',
  blockHeight: 817695
}
msg {
  type: 'Block',
  msgType: 'Finalized',
  blockHash: '00000000000000000b16da75478a2af65e9a984864fa328038dc0260488ccee2',
  blockHeight: 817695
}
msg {
  type: 'Block',
  msgType: 'Connected',
  blockHash: '00000000000000000827c8bd306c259c1f79803102346fdfba48fac8e38ca5e8',
  blockHeight: 817696
}
msg {
  type: 'Block',
  msgType: 'Finalized',
  blockHash: '00000000000000000827c8bd306c259c1f79803102346fdfba48fac8e38ca5e8',
  blockHeight: 817696
}

update: draft up for review.

It would be possible to do a more compact approach, for example having only one ChronikClient object that checks the version-info endpoint and then offers different methods depending on nng or in-node server. However,

1. This requires a good deal of complexity in terms of managing the slightly-similar-but-not-the-same types for shared methods
2. Also complicates deprecation
3. app developers should not write an app for either type of chronik instance

The approach here is backwards compatible, with anyone wishing to use an in-node chronik server needing to specifically instantiate the ChronikClientNode object. It's not the minimum amount of code -- but, as we do not anticipate adding new features to NNG, it will be more straightforward to work with ChronikClientNode class until we are ready to deprecate NNG.

This could be split into several diffs, for example file/var renames could be their own diffs. Same for the @generated mark on the proto ts file. This makes it easier to spot the where the changes are.

In D14758#332748, @Fabien wrote:

This could be split into several diffs, for example file/var renames could be their own diffs. Same for the @generated mark on the proto ts file. This makes it easier to spot the where the changes are.

tentative plan here:

• Update the proto script in package.json + generate the new proto file D14814
• Repo organization, proto and src folders, with index.js exporting everything D14823

Rename NNG types that will conflict with ChronikClientNode (even though these types are in separate files, bc they are used by ChronikClient and ChronikClientNode, and both objects are exported, ts will not allow them to have the same name)

• Add keepAlive method to websocket D14831
• Add in-node ChronikClientNode class and unit tests D14840
• README update, include dev section for proto script and usage section for in-node

edit:

• Make sure ws msg strings are not mixed case, just do lowercase
• no need to rename nng types, if that file is unchanged, don't change it. Use new type names for in-node

Rename NNG types that will conflict with ChronikClientNode (even though these types are in separate files, bc they are used by ChronikClient and ChronikClientNode, and both objects are exported, ts will not allow them to have the same name)

Is there no kind of namespace ? Or maybe make it a member of the ChronikClient

In D14758#332754, @Fabien wrote:

Rename NNG types that will conflict with ChronikClientNode (even though these types are in separate files, bc they are used by ChronikClient and ChronikClientNode, and both objects are exported, ts will not allow them to have the same name)

Is there no kind of namespace ? Or maybe make it a member of the ChronikClient

I can just use new type names for the in-node version, which makes sense as they are the new types that are slightly distinct from the old ones. My original thinking was that it would be nice to have cleaner types in the in-node file as NNG will probably be unmaintained, but since NNG is the only version that supports non-eCash chains, it will prob always be maintained in some way.