something i also have been thinking about

[joeblew99]

this is pretty useful. I have been thinking about the best way to do mobile apps with the web GUI, and some backend written in go. There are some working examples on the web by the gomobile team, where the backend(mobile) and the frontend(mobile Web gui) communicate via standard http.

But i think what you want to do is essentially not use IFF or http but just pure IPC between the GUI and the backend on a phone or dekstop ?

[xenoscopic]

Glad to hear I'm not the only one trying to do this sort of thing. I'm working on an application at the moment that is going to be built this way, i.e. a web technology based UI driven by Go compiled to JS. To be honest though, I've given up on the IPC approach for a few reasons.

My original motivation was security, which is reasonably attainable on POSIX systems, but using Windows named pipes actually exposes the IPC endpoint to the network, and there's no way to prevent it, and even though other users can only do read-only connections by default, it's difficult to configure and get right. Chromium uses these mechanisms (well, actually they use a socketpair() on POSIX), but they've also built their own IPC security on top of that, and they've got thousands of engineers to do it.

Also, the performance with the approach I've taken in this repository is horrible. Well, not unusable, but the round-trip Go RPC invocation time was something like 10ms. This is comparable to using WebViewJavascriptBridge, but it's clear that the JS <-> ObjC/C#/Java bridge is the limiting factor, and it's a pain to work around because they are all different, and now things like WKWebView actually host the Javascript engine out-of-process, so it's double IPC. It could be done better in Electron or NW.js, where the native IPC support wouldn't have this overhead, but then you're stuck shipping 150 MB binaries - I wanted to be able to use the system webview.

My current plan is to use gRPC over websockets with a shared secret for authentication. Then I can use system webviews, get reasonable performance, and decent security. I may do a standalone demo like this one if it works.

I really don't like this trend of using TCP for IPC, but a lot of applications do it now. Exposing a TCP port, even locally, just seems like a recipe for disaster. It might not be so bad if TLS were easier to set up, but the performance of a GopherJS-compiled TLS stack in Javascript? Yikes...

I'll leave this issue open for other ideas in the future.

[joeblew99]

Thanks for the thorough review of your own work.

Btw I worked in Ukraine many years ago and had a team there. It's a cool place :) What are you doing there anyway ?

I was curious and admittedly sceptical. I used grocery for Io between GUI and back end on desktop but did not try mobile yet. By mobile I mean with gomobile.

For web I am using gophers too and polymer. So far it's OK. Polymer is a funny beast though. I am looking at using MDL with gophers. MDL is super lite, and has just enough controls I need. On the gophers bits I am looking at using go-humble.

I got very sick of the latest thing changing so much in the front end every 2 months.

There is also go-wade which builds on top of humble too.

All this stuff you can Google and going pretty easy.

The reason I moved away from grocery is in my case because I have to do a ton of code gen from a DSL, and it was best to keep things simple.

Also for security reasons I need to use relay servers in the cloud to hook up hidden servers in NAT remote environments to desktop and mobile. So websockets are much easier to use when you have to matchup remote servers and clients calling in.

The new protocol buffers support for web browsers is pretty useful so I might use that as the Io data format though.

On Sat, 18 Jun 2016, 16:05 Jacob Howard, notifications@github.com wrote:

Glad to hear I'm not the only one trying to do this sort of thing. I'm working on an application at the moment that is going to be built this way, i.e. a web technology based UI driven by Go compiled to JS. To be honest though, I've given up on the IPC approach for a few reasons.

My original motivation was security, which is reasonably attainable on POSIX systems, but using Windows named pipes actually exposes the IPC endpoint to the network, and there's no way to prevent it, and even though other users can only do read-only connections by default, it's difficult to configure and get right. Chromium uses these mechanisms (well, actually they use a socketpair() on POSIX), but they've also built their own IPC security on top of that, and they've got thousands of engineers to do it.

Also, the performance with the approach I've taken in this repository is horrible. Well, not unusable, but the round-trip Go RPC invocation time was something like 10ms. This is comparable to using WebViewJavascriptBridge, but it's clear that the JS <-> ObjC/C#/Java bridge is the limiting factor, and it's a pain to work around because they are all different. It could be done better in Electron or NW.js, where the native IPC support wouldn't have this overhead, but then you're stuck shipping 150 MB binaries - I wanted to be able to use the system webview.

My current plan is to use gRPC over websockets with a shared secret for authentication. Then I can use system webviews, get reasonable performance, and decent security. I may do a standalone demo like this one if it works.

I really don't like this trend of using TCP for IPC, but a lot of applications do it now. Exposing a TCP port, even locally, just seems like a recipe for disaster. It might not be so bad if TLS were easier to set up, but the performance of a GopherJS-compiled TLS stack in Javascript? Yikes...

I'll leave this issue open for other ideas in the future.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/havoc-io/gopherjsipcbridge/issues/1#issuecomment-226944282, or mute the thread https://github.com/notifications/unsubscribe/ALcacz_ycYnJk8pL_T6cunV1aAaHRN8dks5qM_skgaJpZM4I48Jq .