search

testground / sdk-js

Other
1 stars 3 forks source link

Support Browser #13

Open hacdias opened 3 years ago

hacdias commented 3 years ago

Testground using JavaScript on browsers can be a very powerful tool to test any browser related software, such as js-ipfs. However, there are some challenges we need to overcome to successfully implement this SDK in order for it to work on the browser.

Right now, I'm using the builtin Node.js os package to obtain the network interfaces, as well as the hostname. Both of those can be easily injected externally and it is being tracked on #12.

On the other hand, we have Redis. There are no browser-compatible Redis clients I can find and that is probably related to the strict server-side nature of Redis. All JavaScript clients require Node.js builtins.

I found webdis but I have some concerns. Either way, this would need to be implemented on Testground side.

What if part of the Testground daemon run a small HTTP server dedicated to proxying calls to Redis, tailored for our purpose, with specific endpoints for publish, subscribe, etc? Then, both sdk-js and sdk-go could simply leverage that.

hacdias commented 3 years ago

@nonsense pinging you because I am pretty sure you have more feelings and information about this than me. What do you think? How should we proceed?

hacdias commented 3 years ago

@hugormdias said:

ah right, the only solution i found for browser connection is to use https://webd.is/ but you can split by env and target browser like and bundlers with an http client to webdis and node > with a node native redis-client. if you need help ping me

I have some concerns about using webdis as it's simply an HTTP server and would need to run separately from the test. I had the idea of letting Testground daemon leverage that by having its own small HTTP server for the interactions we need.

Ping @nonsense

nonsense commented 3 years ago

@hacdias right, as discussed, we can translate the sync library into a sync service that is compatible with browsers - we don't need a full-fledged Redis proxy, and we also don't really want to give full access to Redis to every test plan ran on Testground. This has been the case so far for simplicity, but further isolation would be good.

We only need to support the sync service interface and all the sync primitives, which is simpler that supporting all of Redis, which we don't really need.

hacdias commented 3 years ago

A quick update on this post: further developments of the JavaScript SDK are blocked by the development of the Sync Service, which needs to be implemented and tested on both Testground main repository and the Go SDK.

hacdias commented 3 years ago

Ref.: https://github.com/testground/sync-service/issues/4