<p>In the old days, I wrote desktop applications in Java using the Swing library for the graphical user interface.</p>
<p>I've now wised up and am writing most of my software in Go (:-)).</p>
<p>I have a couple of "desktop" applications in mind, but I do not want to go back to the days of using a UI library. I would prefer to write them as client-server apps where the server only responds to localhost. When the server starts (via a double-click on the icon), it will open an <code>index.html</code> in the default browser, and use CSS and React (using GopherJS) as the front-end of a single-page app. The server will connect to a local database (probably <a href="https://github.com/boltdb/bolt" rel="nofollow">BoltDB</a>) and will serve information to the front-end using a REST API.</p>
<p>The dilemma that I am struggling with is the best way to shut down the server when the user is finished. I am using Go 1.8, so I can call the <a href="https://golang.org/pkg/net/http/#Server.Shutdown" rel="nofollow">Server.Shutdown()</a> function. I can include a REST call that invokes this function (e.g. <code>/shutdown</code>). Two possibilities for calling this are</p>
<ul>
<li>An "Exit" button in the UI</li>
<li>Catch the "close tab" event in the browser</li>
</ul>
<p>Either of these can then use a <code>fetch</code> call to invoke the <code>/shutdown</code> API.</p>
<p>Are there other alternatives that might be better? I guess I could also just leave the serve running in the background, but there might be valid reasons for shutting it down when not in use.</p>
<hr/>**评论：**<br/><br/>mixedCase_: <pre><p>It's likely you'll want to have real-time bidirectional communication between your frontend and backend, so you can just keep a websocket open to do so and kill the backend when the frontend closes the conncetion.</p></pre>grkuntzmd: <pre><p>I might be able to use a web socket as a "close-me" sentinel, without actually sending anything down the socket. I've used Go channels for the same thing.</p></pre>brokedown: <pre><p>This is the obvious answer, there are other ways to do it but they won't be as good.</p></pre>jerf: <pre><p>An exit button in the UI is probably necessary, because users are going to want to be able to shut it down.</p>
<p>Catching the close event would require more careful engineering; if you don't control the browser window you can't stop users from opening your app in a second tab, and you don't want to terminate if that tab closes. You can try to play games to deal with this but it would be fragile.</p>
<p>One thing I'd suggest is documenting that the "exit" button shuts the app down and that this is the official mechanism for terminating it, but also implement something like "If I haven't seen a request for $SOME_TIME, I shut down." You can wrap a bit of middleware around the top-level router to track "the last time I saw a request of any kind" pretty easily, and if you do go with a websocket or something you can easily write something that refreshes that too.</p>
<p>I'd also suggest doing something like having the program manually count seconds rather than using the system time and just setting an alarm for an hour in the future. If you, say, want to shut down after an hour of not being used, by using a channel to ping you every second and counting those, the time that a computer may be suspended or hibernated won't count against that time, which is what you want. (Normally this is a bad idea precisely because it misses out on suspend/hibernate time.) You probably ought to set that timer to something like every 10 seconds or something, too, to avoid getting scheduled too often while idle, which eats battery.</p>
<p>That just leaves making sure that the app itself can detect shut downs and handle them gracefully, giving the user clear instructions on how to restart the app.</p>
<p>Unfortunately, there just isn't a way to fully bind these two elements together without embedding a full browser under your control, but if you can live without that, these things will be "good enough".</p>
<p>I wouldn't particularly recommend trying to use the presence of a websocket to determine whether the app is open; in addition to the challenges if a user opens your app in a second tab, in extreme situations such as memory deprivation I can't guarantee it'll do what you want.</p></pre>dinkumator: <pre><p>I've been planning out an app with a similar setup, I was thinking about just building a "lightweight" native webkit wrapper that points at the localhost server. This way I can still make a mac bundle and get expected menu/shutdown semantics.</p>
<p>It'd be sorta like <a href="https://en.wikipedia.org/wiki/Adobe_AIR" rel="nofollow">Adobe AIR</a> or <a href="https://electron.atom.io/" rel="nofollow">Electron</a> but for Go apps.</p></pre>grkuntzmd: <pre><p>I had thought to use a webkit wrapper, but I'm not sure if I would then need to have users install it before using/installing my server app. One thing I like about Go is that the executable is completely self-contained. I just need to send one file.</p></pre>dinkumator: <pre><p>The wrapper can call the Go executable as a child process. On mac it's fairly straightforward to make an .app bundle so it's still self-contained. I'm not as experienced at .NET / windows but I'm sure there's a similar method for modern windows apps.</p>
<p>If you're concerned about users not being able to install things, I'd be more concerned about doing the separate server process actually!</p></pre>grkuntzmd: <pre><p>Installation of the app is its own can of worms... :-)</p></pre>asticode: <pre><p>You can embed whatever you need for the installation in your self-contained GO executable using <a href="https://github.com/jteeuwen/go-bindata" rel="nofollow">https://github.com/jteeuwen/go-bindata</a> if you wish</p></pre>dinkumator: <pre><p>I ran across this project a while back, it could be useful too: <a href="https://github.com/alexflint/gallium" rel="nofollow">https://github.com/alexflint/gallium</a></p></pre>grkuntzmd: <pre><p>I looked at gallium. It currently only supports MacOS. I develop in Linux.</p></pre>asticode: <pre><p>This solution is cross platform : <a href="https://github.com/asticode/go-astilectron" rel="nofollow">https://github.com/asticode/go-astilectron</a> (<em>Disclaimer: I'm the author</em>)</p>
<p>It relies on Electron and I've released it 2 days ago so feel free to test it and let me know what you think about it.</p></pre>
