Basic SDK version

[hacdias]

For the first iteration, we should go for a very basic version of a JS SDK that has the smallest feature set in order to make simpler tests work. After having a functional version, we can iterate and improve by adding new features to match the feature set of the Go SDK. In terms of API, we should follow the same generic API that we're using on the GO SDK in order to make it easy for developers.

So, the TODOs are:

• Sync Primitives: barriers, publish, subscribe, sugar methods, etc.
• Outputs
• Initialization of data network: this is done by the sidecar, but we need to listen to the same topics on Redis and emit signals with the sync primitives.
• docker:js builder for testground

cc @nonsense @jacobheun

[hacdias]

So, after 22 days, I should give a bigger update about what's going on. I spent most of yesterday updating sdk-js to match the new changes made to Testground related to the events we now emit on the sync package. Besides that, I can say that we finally have the following:

• Sync Primitives: barriers, publish, subscribe, sugar methods, etc.
  • They are all working, but since JavaScript is not a typed language, I think I should add some JSDoc comments for autocomplete systems and user documentation.
• Initialization of data network: this almost came alongside with the sync primitives. We contact sidecar, we're connected to the same topics on Redis and everything seems to be working.
• docker:node builder: the changes on Testground side are being made on this PR, in which you can find a basic builder. I decided to call it docker:node and not docker:js to make the underlying more obvious.
• Example tests: I build a few example tests, such as pingpong, sync and failure to check if everything was working.

The @testground/sdk package is not yet released because I feel there are still a few things to do. The perhaps the most important:

• Ignore node_modules when sending the plan files to the daemon because... well... the size and it's useless, right? @nonsense what do you think about a .testgroundignore file? Or can we simply ignore node_modules generally?

In addition, there are features that the Go SDK has that this one doesn't have yet. I'd like both of you to give me feedback on how important you think they are and if I should focus on something else right now instead (such as building actual test plans):

• Metrics API: the metrics API that uses InfluxDB for diagnostics and results.
• I also haven't build the assets API. The directory exists and the path is accessible through the runenv variable so it can be used.
• Docs!

[jacobheun]

I'd like both of you to give me feedback on how important you think they are and if I should focus on something else right now instead (such as building actual test plans):

I think the metrics API will be necessary for us to be able to get value out of the test plans. Once that's in place having a test plan in place for us to be able to use as a starting point would be very helpful. As we are looking to make improvements to the JS DHT this quarter, having existing test plans for findProviders, findPeer, and provide would enable us to get those comparisons to evaluate performance changes.

[nonsense]

Ignore node_modules when sending the plan files to the daemon because... well... the size and it's useless, right? @nonsense what do you think about a .testgroundignore file? Or can we simply ignore node_modules generally?

We considered this a while back, but didn't have the capacity to implement properly - at the moment only _compositions directory is ignored, I think because it starts with a _. I don't like this solution, it certainly doesn't work for node_modules.

I think node_modules is a good example why a .testgroundignore file would be useful.

[nonsense]

I'd like both of you to give me feedback on how important you think they are and if I should focus on something else right now instead (such as building actual test plans):

I think the assets API is a low-hanging fruit, and looking back it has been the tool used by go-ipfs and gossipsub, versus the Metrics API. Their plans would generate outputs which would then be visualised with custom scripts (bash scripts, jupyter notebooks, etc.).

Having the Metrics API would also be very handy as folks could just create a dashboard in Grafana and use InfluxDB's capabilities.

[jacobheun]

Their plans would generate outputs which would then be visualised with custom scripts (bash scripts, jupyter notebooks, etc.).

This is a good point, we also caught several bugs in the DHT query logic because we used the assets to graph the query timeline.

[hacdias]

I am closing this issue as most things here are already implemented. The package is not yet released. I will do that after addressing #7 and #8! The Metrics are, indeed, important, but I will implement them after releasing 1.0. In addition, testground/testground#1158 should be ready for review soon.