Recommended project structure for bundled web app?

<p>I&#39;m new to Go, but not to web development generally. I&#39;ve already read the Go website&#39;s <a href="https://golang.org/doc/code.html">recommended project structure</a>. I have an idea for a web app that I&#39;d like to try to implement in Go, but I&#39;m not sure how to structure the project.</p> <p>The server-side code and executable code is explained adequately in the link above. However, the app&#39;s frontend will be written in Javascript and packaged into release form with <a href="https://webpack.github.io/">webpack</a>/<a href="http://gulpjs.com/">gulp</a>/<a href="https://nodejs.org/">node</a>/whatever and then packaged into the Go executable with <a href="https://github.com/jteeuwen/go-bindata">go-bindata</a>. There will also be html/css/images and whatever else.</p> <p>How should I organize this project? Do I make the Go backend and the Javascript frontend two different git repos? Do they live together in one git repo? How do I reconcile the &#34;go get&#34; way of doing things with the Makefile I&#39;ll probably need to build the frontend, pack it into Go files, then bundle the final executable? I&#39;d really appreciate some advice from someone who has tackled this kind of project before.</p> <hr/>**评论：**<br/><br/>AirborneArie: <pre><p>I&#39;m working on something similar (golang + emberjs). I have a <code>server</code> and <code>client</code> dir in my project (guess what goes where). And I&#39;m no in the process of writing a Makefile that will a) compile the golang app b) compile the emberjs app c) put it all together in a dist/ directory for release. </p></pre>Jamo008: <pre><p>Depends on the size of the project. Here&#39;s a small project which embeds a simple Angular frontend: <a href="https://github.com/jpillora/cloud-torrent" rel="nofollow">https://github.com/jpillora/cloud-torrent</a>. I would start with everything in one repo and then grow out. So in this example, <code>static/</code> is the frontend package and then we generate (<code>go generate ./...</code>) the <code>static/files.go</code> file which is made from compiling <code>static/files/*</code> using go-bindata. Go makes it really easy to refactor packages so as your project grows you can move the <code>static</code> package out to its own repo which would be <code>go get</code>able. You could even <code>.gitignore</code> the <code>files.go</code> and <code>go generate</code> on build using CI - this ensures you&#39;ll never forget to to recompile any frontend changes. As for a Makefile/Gruntfile etc., you easily include those in the frontend root (<code>static/files/</code>) and then exclude them from static compilation.</p></pre>calebdoxsey: <pre><p>I like to use one repo, with the go files in the root and the js/css files in an <code>app</code> folder that gets compiled into a <code>public</code> folder.</p> <p>The root go project is usually mostly routing and web-specific. If it grows to big I break it into sub-packages (but all still in the same git repo).</p> <p>An example is here: <a href="https://github.com/golang-book/www" rel="nofollow">https://github.com/golang-book/www</a>. I use ninja to do the build (which can also do go build, but since I&#39;m using app engine that&#39;s not as needed)</p> <p>I would avoid the go-bindata route because files are easier to debug. Unless this is an installed application... but if you control the server a folder is not really any harder to deploy than a file. Once again app engine does this bit for me, but there&#39;s always rsync.</p> <p>A simple deploy script is probably good enough, but to really do this right can be quite a bit of work. (zero-downtime restarts, rollback capabilities, using CI to do the builds, maybe running docker containers, etc...) Is this a VM server you are planning to run on? You might take a look at nomad: <a href="https://nomadproject.io/docs/index.html" rel="nofollow">https://nomadproject.io/docs/index.html</a>. Probably overkill for one server, but if you were planning on running multiple things it might be worthwhile.</p></pre>xordord: <pre><p>Actually, my plan isn&#39;t to run my server on the internet at large. I plan to bundle everything into an executable that can then be passed around and any one person can run it. Then other people on the same LAN can connect to it.</p> <p>The ultimate plan for deployment is a single distributable file.</p></pre>xordord: <pre><p><a href="http://stackoverflow.com/a/33511331/457586" rel="nofollow">http://stackoverflow.com/a/33511331/457586</a></p></pre>zenista: <pre><p>It depends. If you are the only developer working on it, single repo is best. But if the project is large and has dedicated team for ui and server, its good idea to split them up into two repos and ui guys should compile and push updated go-bindata file to the server repo, whenever ui changes. While server team is totally focused on backend part. I usually use single repo with two folders - server and ui, for backend and frontend. I use react for frontend.</p></pre>