<p>Hey!</p>
<p>I'm an experienced PHP/Ruby-programmer learning Go by building a REST API to serve as backend to a simple AngularJS app and I have a few scattered issues.</p>
<ul>
<li>Is the decorator pattern bigger in Go compared to other languages duo to the cool implementation of interfaces?</li>
<li>Would you consider it to be a good idea to have a 'check-http-header-for-a-token-auth' function be put in a decorator around the routes?</li>
<li>When I'm programming the server app I constantly have to run <code>go install</code> followed by <code><binary-name-or-project></code> on more or less every file save. Any tools to solve that? What do you do? I know they are built into the App Engine package, but any stand-alone wrappers?</li>
<li>What is the de-facto ORM used in Go? <a href="https://github.com/jinzhu/gorm">Gorm</a>? </li>
<li>Are all ORMs automagically compatible with MySQL on App Engine (since the common sql-interface in std lib)?</li>
<li>I want to put my http handlers on one directory, my models in one etc. And I know that Go uses packages, but would you put models in an entirely different package? And handlers in another? It's the same application and it feels plain wrong to have them all in one directory. How do you do it?</li>
</ul>
<p>Thank you!</p>
<p> </p>
<p>EDIT: I found <a href="https://github.com/codegangsta/gin">gin</a>. Wonderful!</p>
<hr/>**评论：**<br/><br/>Ainar-G: <pre><p>1 and 2: I'm not quite sure what're you talking about here, because "decorator pattern" is not something you hear often in the Go lingo. If you mean <a href="http://golang.org/doc/effective_go.html#embedding">embedding</a>, then it's just the way Go does composition. If by "be put in a decorator around the routes" you mean creating an <code>http.Handler</code> wrapper (aka middleware) to handle authorisation, then yes, a lot of people do it this way.</p>
<p>3: <code>go run</code>? <code>go install && my-thingy</code>?</p>
<p>4: I don't think there is a de-facto ORM. From what I know, people tend to choose between Gorm, Gorp, and hand-written SQL/an SQL builder depending on the kind of functionality they need.</p>
<p>5: Haven't worked with App Engine or MySQL, so can't answer that, sorry.</p>
<p>6: This is a trap I myself, being a Rails developer, got myself into at first. In this case the thing that "feels plain wrong" is actually fine, and will spare you of a lot of headaches. As <a href="/u/davecheney">/u/davecheney</a> put it <a href="http://dotgo.sourcegraph.com/post/99652344343/go-team-qa-dependency-management-language">when speaking about anti-patterns in Go code</a>,</p>
<blockquote>
<p>Packages should be at the granularity of an idea. HTTP is an idea; an HTTP client is not an idea. (…) If you have a utility package, that’s OK, but it should have a name that’s not just “utils.”</p>
</blockquote></pre>lannor: <pre><p>1 and 2: That was what I was looking for, the word <code>middleware</code> explains it much better. </p>
<p>3: I found gin. Was what I was looking for</p>
<p>4: I'll try Gorm.</p>
<p>5: Ait</p>
<p>6: TBH, I don't get this. "Should" I have many small packages (models, handlers etc) for my app? Those packages will feel so out of context. </p>
<p>Thank you for your reply!</p></pre>jerf: <pre><p>Decorator pattern in Go is: One, create an interface <code>interfaceX</code>. To create an "<code>interfaceX</code> decorator", you would:</p>
<pre><code>type DecoratedX struct {
internal interfaceX
// whatever else you may need
}
// override interfaceX methods at will
</code></pre>
<p>Middleware is a specific case. Decorator is the general case; middleware is a decorator on <code>http.Handler</code>.</p>
<p>Since it's so simple, you don't see much discussion about it here. It occasionally also comes up in the context of decorating <code>io.Writer</code> or <code>io.Reader</code>. For some simple cases, see the several functions in <a href="http://golang.org/pkg/testing/iotest/" rel="nofollow">iotest</a> that take in one or the other and return a modified version. (Consider also clicking through to the <a href="http://golang.org/src/testing/iotest/reader.go?s=381:422#L5" rel="nofollow">source code</a> to see it in action.)</p></pre>PsyWolf: <pre><p>There's nothing wrong with splitting your code into subpackages. You'll just want to use their full name when you import them. Check out this example.</p>
<p><a href="https://github.com/cznic/dns/blob/master/xfr/xfr.go" rel="nofollow">https://github.com/cznic/dns/blob/master/xfr/xfr.go</a></p></pre>robertbieber: <pre><p>I found this to be pretty helpful to get started building web apps in Go: <a href="http://nicolasmerouze.com/build-web-framework-golang/" rel="nofollow">http://nicolasmerouze.com/build-web-framework-golang/</a></p>
<p>It's not anything extraordinarily great, but here's a small-ish web app I threw together a little while ago: <a href="https://github.com/bieber/mixer" rel="nofollow">https://github.com/bieber/mixer</a></p>
<p>I think I use much more granular packages than a lot of people would suggest for Go projects, but I'm pretty happy with the way it works out, so eh :p</p></pre>
