3 ms·

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

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.