support for golang wasm and and non wasm apps.

[gedw99]

Is your feature request related to a problem? Please describe.

I build applications using golang and compile them to wasm.
I also compile them to run on Desktop and Mobile apps too.

High perf apps need the GUI rendering "thread" / go routine separated from the many background IO, computation layers, so that the rendering gui is never blocked.

In web apps this is typically done by using workers and Service workers. Message passing is used in WEB
In Desktop and Mobile, most use goroutines. There is NO formal message passing like there is for web.

Describe the solution you'd like

I just wanted to know if Transport supports or wants to support making the above easy.

Almost feel what is needed is an an abstraction and util, helpers.
JUst like you are abstracting for NATS and Kafka.

Describe alternatives you've considered

No response

Additional context

Demonstration code.

https://github.com/npillmayer/giocomp

Has the scheduler that ALL components use: https://github.com/npillmayer/giocomp/blob/main/components/comp.go#L9

[gedw99]

Hey @jooskim I spoke too early, as It looks like you have a PR that is aiming to do something similar in #46

It looks like a nice solution. I feel that the trick is being able to make it work with WASM and NON WASM golang apps, such that we are using the same API everywhere for clients. Even Servers too.
I use NATS to do these things and so am quite interested in what Transport's goal is.

One idea i had is to support the Service worker API for WASM and NON WASM apps. Almost like a lowest common denominator approach.
https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API

• this is because it formalises the proxy concept and message passing.
• so then with that API abstraction, you can build WASM and NON WASM golang apps that work with "transport" aspects.

Also, in terms of conditional compilation, here is a example with gio here:
https://github.com/gioui/gio-x/tree/main/notify

• its just using a common interface and at compile time, using the build tags to do conditional compilation.

[daveshanley]

I absolutely love that we're discussing this. WASM has been a goal for a while. @jooskim, thoughts?

[jooskim]

Hi @gedw99 , thanks for the issue, greatly appreciate your suggestion. I am 100% on board with the direction you are suggesting. I had given a bit of thought before, and as Dave said, this is a perfect time to discuss how we can make it happen!

TL;DR:
For native apps, you can continue to use the same Transport Go API by creating services, or channels manually yourself.
For web apps, we have the TypeScript version of Transport that provides the same API as Go, and #46 will enable passing messages back and forth between the Transport Go in WASM and the JavaScript. Instead of consuming the response from WASM directly, you can relay it to client side bus channels using Transport TypeScript for more sophisticated control flows. As part of #46 I will make sure to build out examples to test out yourself.

The idea of #46 is exactly so web apps can talk directly to Go Transport and vice versa. I'm not sure if you checked out Transport TypeScript yet but it is the TS/JS version of Transport, providing the same API with mostly the same function signatures. The purpose of the PR is to provide a bridge that makes talking across the TS/Go boundary one smooth experience, and without Service Worker or Web Workers involved, as Transport provides a scalable mechanism for extending local bus channels to brokers like NATS, RabbitMQ, etc. although external brokers are not the focus in this thread here.

To tell you the gist of the PoC work, it exposes a few wrapper methods for the client side JS to call. These call directly call into Transport Go APIs, and their results are passed back as a JS callback, like so:

const handler = window.goBusInterface.listenStream('test'); // opening a subscription on Transport Go
handler.handle((payload) => {
    // client side handling of payload

    // or you can pass it to Transport TypeScript channels like this!
    AppEventBus.sendResponseMessage('js-only-channel', payload);
});

The current experiment I'm doing in #46 is done is to prove reasonable operations between Transport Bus API and Transport Go API, and on the JavaScript side this main interfacing is done in the main thread not in the Web Worker. Granted, given how synchronous blocking calls in the Go routine called by JS will pause the JS's event loop, we have to ensure the payload we send to WASM will not block the WASM main thread. And Transport Go's messaging mechanism actually works in a way that these operations happen indeed in separate goroutines. I'm simplifying a bit here but here's what's happening in the PoC demo:

1) On the WASM instance, Transport Go has created a channel called "test", and set up a handler for processing incoming requests.
2) JS client sends a request to the "test" channel in the WASM instance using the bridge API (what PoC PR is implementing). JS client also starts waiting for a response on the same channel.
3) Transport Go relays the payload from JS to its the "test" channel. 
4) The channel process the request and sends back the response to the same "test" channel.
5) JS client receives the response.

Of the five steps above, steps 3 and 4 are happening on separate goroutines, so WASM's main thread remains hardly impacted no matter how heavy the workload may be, and the JS thread will not freeze. Now, I've talked as if I want to avoid Web Workers at all costs, but the reality is that we didn't have a need to move the messaging mechanism to a separate thread by means of Web Workers in VMware's enterprise cloud web apps. That is to say we have been running Transport TypeScript as part of the main app bundle for our messaging needs, and almost 100% of the times the bottlenecks were from slow APIs or expensive DOM rendering. That said, my experience may not be the same as how you view it, so I may be overlooking some potential bottleneck risks. So please share your perspective!

If you have legitimate use cases for Workers APIs in JS other than the concern for blocking the JS main thread, I'm more than happy to discuss them here. Or if you have more general questions around the TypeScript version of Transport in the context of interoperability feel free to lay them onto us!

[jooskim]

I tried to put too much thought into one comment, but let's start from your question/concern and we'll take it from there. And @daveshanley will provide excellent details where I'm lacking :)

[gedw99]

Hey @jooskim @daveshanley

Thanks for the thorough explanation.

No worries about the density of your comment. I know its a big subject area - i have the same problem. It seems we are both crazy enough to be interested in this area.....

Because its such a massive area i started https://github.com/gedw99/gio-transport. It goes into the transport and bus aspects for golang and non golang apps and servers.

Because this area is so huge i would love to do a video conf / chat on this with you and others... my telegram is on my profile, and we could organise a zoom ?

I have yet to pull your PR, but can see what it's meant to do from the code. I will get to it though...

[jooskim]

@gedw99 Absolutely. We are thrilled to continue the conversation with likeminded folks like you! I'm currently traveling abroad but will back home in the US at the end of this week. (Though I'll first go get myself a Telegram account :D)

Also I'll update the PR to include an out-of-the-box example that you can just go run main.go and open up the browser to see it in action. I'm thinking of implementing a X509 certificate parser using the mechanism being implemented in the PR. In the meantime, please feel free to ask any questions about anything.

[gedw99]

Ok - looking forward to chatting.

Have a good break ! No rush