Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Browser #13

Open
hacdias opened this issue Dec 11, 2020 · 5 comments
Open

Support Browser #13

hacdias opened this issue Dec 11, 2020 · 5 comments

Comments

@hacdias
Copy link
Member

hacdias commented Dec 11, 2020

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
Copy link
Member Author

hacdias commented Dec 18, 2020

@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 hacdias mentioned this issue Dec 18, 2020
8 tasks
@hacdias
Copy link
Member Author

hacdias commented Jan 8, 2021

@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
Copy link
Member

nonsense commented Jan 8, 2021

@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
Copy link
Member Author

hacdias commented Feb 2, 2021

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
Copy link
Member Author

hacdias commented Mar 2, 2021

Ref.: testground/sync-service#4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Development

No branches or pull requests

2 participants