4 ms·

> With Go the only "possible" way is to write a server and open a tab in your browser. That split model isn't limited to browser tabs. You can write a nice GU

> With Go the only "possible" way is to write a server and open a tab in your browser. That split model isn't limited to browser tabs. You can write a nice GUI (native, or tooling of your choice) that communicates with your go back-end via API bindings. This model is well proven (dockerd/docker cli; various crypto wallets and their front-end UIs, etc), though attention needs to be given to security concerns. Running a local service means malicious software that knows about the service could access it without the user's knowledge if you're not careful, exposing private or sensitive data that the service has access to.

fileeditview 6y ago
I agree that can be a viable solution. Mainly if the backend is also used without GUI. However what I meant is that the Go part of the application will be only the server part. Can you clarify these security concerns? If the server is only listening on localhost I don't see a difference to "the classic desktop application". If the malicious software has access to your system the data is always endangered right? Or were you talking about services that are exposed to the outside?
- GrinningFool 6y ago
  > However what I meant is that the Go part of the application will be only the server part. That's what I meant as well. You have a go daemon/service running that does the heavy lifting; and your front end (whatever it may be) knows how to talk to it. The UI elements remain separated from the work of the daemon. The browser-based/localhost approach works well for this too, but you can also take the same approach for rich/native client apps without having to make the daemon platform-specific. > If the malicious software has access to your system the data is always endangered right? This is what I was referring to - nothing new, but IMO worth mentioning in the context of setting up a new service to run on someone's system.

fileeditview 6y ago

I agree that can be a viable solution. Mainly if the backend is also used without GUI. However what I meant is that the Go part of the application will be only the server part. Can you clarify these security concerns? If the server is only listening on localhost I don't see a difference to "the classic desktop application". If the malicious software has access to your system the data is always endangered right? Or were you talking about services that are exposed to the outside?

GrinningFool 6y ago
> However what I meant is that the Go part of the application will be only the server part. That's what I meant as well. You have a go daemon/service running that does the heavy lifting; and your front end (whatever it may be) knows how to talk to it. The UI elements remain separated from the work of the daemon. The browser-based/localhost approach works well for this too, but you can also take the same approach for rich/native client apps without having to make the daemon platform-specific. > If the malicious software has access to your system the data is always endangered right? This is what I was referring to - nothing new, but IMO worth mentioning in the context of setting up a new service to run on someone's system.