REST application folder structure in golang

<p>I&#39;m just getting started with Go and as a first project I decided to make a simple REST API server. Unfortunately, I&#39;ve hit a problem as I can&#39;t seem to find the best way to structure my project.</p> <p>So far, I&#39;m using the same structure as a Rails project meaning having controllers and models in their own folders, but it doesn&#39;t as idiomatic as go code should be.</p> <p>Does anyone have any advice on how to properly structure a project?</p> <p>Thanks!</p> <hr/>**评论：**<br/><br/>pedronasser: <pre><p>Try this way to structure: <a href="https://github.com/weSolution/gapi-example" rel="nofollow">https://github.com/weSolution/gapi-example</a>. </p> <p>Built using this command-line tool: <a href="https://github.com/weSolution/gapi" rel="nofollow">https://github.com/weSolution/gapi</a></p></pre>nuunien: <pre><p><a href="https://github.com/sourcegraph/thesrc" rel="nofollow">https://github.com/sourcegraph/thesrc</a></p></pre>gchain: <pre><p>I really like drone&#39;s[1] code organization.</p> <p>[1] <a href="https://github.com/drone/drone/" rel="nofollow">https://github.com/drone/drone/</a></p></pre>kjk: <pre><p>Do the simplest thing possible first. You can always restructure into packages (directories) later.</p> <p>Here&#39;s how my simple forum software is structured: <a href="https://github.com/kjk/fofou" rel="nofollow">https://github.com/kjk/fofou</a></p> <p>Everything is in one directory. </p> <p>I don&#39;t even split things into models and controllers because I don&#39;t like to create lots of small files. A model is just a struct in Go and controller is just the http handler and I would rather have the struct next to code using it rather than having to jump back and forth between 2 files.</p></pre>laika_muttnik: <pre><p>Thank you, I think I will follow this route. However how do you handle the model relation to the database? Do you use an ORM or do you write your own queries and then construct your models around that ?</p></pre>dewey4iv: <pre><p>+1 -- you are doing roughly the same thing I do with prefixing some of the file types. How do you like that approach so far?</p> <p>I do something similar to having &#34;a struct near the handler&#34; but it usually isn&#39;t the model itself. I will usually describe a struct that is the structure of my expected request and expected response. This makes it really easy to handle son or xml etc.. (anything that you marshal). It&#39;s done in an easy single step. Now, in that struct is where I usually place my models. This is especially true given that a lot of my apps don&#39;t work with a single model type in a request. Do your &#34;models&#34; (the structs themselves) usually not have a few methods attached? </p></pre>dewey4iv: <pre><p>Usually, I keep all the files in the same directory and prefix the file names with the kind of code they contain (i.e. handler, config, model, etc...)</p></pre>laika_muttnik: <pre><p>Thank you. Do you mean that for a book tracking application you would have a <code>model_book.go</code>, a <code>controller_book.go</code>, etc. ?</p></pre>dewey4iv: <pre><p>You could do that. I usually organize it by doing the following:</p> <p>handler.signup.go, repo.user.go, routes.go etc.. periods (.) make it prettier. This also organizes them typically in alphabetical order and makes it easy to pull them up. </p> <p>Also, per some of your other questions above: I typically don&#39;t use an ORM with my go code but <em>sometimes</em> I create a model where the database integration is abstracted to meet the requirements of a &#34;Model&#34; interface. I can then pass a pointer to an instance of a particular object (like a user struct) to a Find method [signature: Find(user *Repo, id int64) error]. It means a bit of extra work to write all of the methods for that type but I&#39;ve found that for larger, ever-changing code bases it makes it REALLY easy. I&#39;ve also been experimenting with go generate to do a lot of the heavy lifting here for me automagically. </p></pre>