Allow for browserWSEndpoint in connect

[joelgriffith]

Thanks so much for building this out, lots of work 🙂

To get symmetry with how puppeteers interface works it’d be awesome to allow for a fully-qualified URL vs host/port. This allows for other systems to better integrate (in my selfish case, browserless).

I’d be more than happy to submit a PR if this sounds good. Thanks again!

[deepsweet]

Thanks so much for building this out, lots of work 🙂

Glad you find it useful :)

fully-qualified URL vs host/port

I'm afraid that it's not possible: browserWSEndpoint in Puppeteer is a WebSocket, but Marionette behind Foxr opens an arbitrary TCP socket which means only host and port. I believe that this could be done in 2 parts: 1) serve WebSocket as URL on "backend" side and proxy Marionette TCP socket to it 2) proxy Foxr to WebSocket URL on a "client" side.

I can help with the second one, but separately from Foxr, because such functionality doesn't make sense without a "backend".

What do you think? Please correct me if I'm wrong.

[deepsweet]

Also:

With WebSockets, the data that is passed to the send method is always either sent as a whole "message" or not at all.

from here, which is not so true in case of TCP and Marionette protocol in particular – at least from a receiver side messages can arrive in multiple chunks through the so called "json-wire protocol". I'm going to decouple and publish my re-implementation separately soon.

[joelgriffith]

Thanks for the context, that makes a lot of sense. Let me say it another way to make sure I follow, because the project I work on essentially acts a WebSocket server with more bells and whistles.

1. A reverse-proxy server exists and listens for HTTP upgrade requests (websockets), but when requests are received it reverse-proxies to a TCP connection.

2. Foxr will have an interface for connecting to a WebSocket-based service that eventually gets proxied into a TCP connection.

Does that roughly sound correct?

[joelgriffith]

We could keep it purely TCP based since that seems to be the lowest-common-denominator here, and would make the most sense from a maintenance perspective. Let me snoop around the NodeJS docs for a bit.

[deepsweet]

I believe that the 2 in your list should be done outside of Foxr as some kind of TCP<->WS proxy, so Foxr will know nothing about it. At the end it's just streams on both sides, you just need to buffer chunked Marionette messages.

[deepsweet]

If only I have time I'd implement this as marionette-to-ws and ws-to-marionette packages :)

[joelgriffith]

Thanks for the info, I wouldn't worry about more packages at the moment. I'm going to toy with this and report back to this issue with findings! Thanks!

[deepsweet]

Feel free to ping me here again if something new appears.