<p>Hello,
I'm more or less following <a href="http://goa.design/learn/guide.html" rel="nofollow">this guide</a> but with my own API, just starting simple to learn the framework.</p>
<p>I have one mediatype with the following type: ID (string) Name (string), and Href (string).</p>
<p>I generated my code and went to modify the code of my resource to obtain a dummy example when I want to GET from an id: /myRessource/:id"</p>
<pre><code>// Show runs the show action.
func (c *FactionController) Show(ctx *app.ShowFactionContext) error {
// FactionController_Show: start_implement
if ctx.FactionID == "0" {
return ctx.NotFound()
}
faction := app.MyapiFaction{
ID: ctx.FactionID,
Name: fmt.Sprintf("Faction %s", ctx.FactionID),
Href: app.FactionHref(ctx.FactionID),
}
// FactionController_Show: end_implement
return ctx.OK(&faction)
}
</code></pre>
<p>Problem is when I went to build my application, it complained on the name of ID, name, and Href that it cannot use type string as type *string. I tried to reference them, but it only worked for ID, name and href kept complaining about the same error.</p>
<p>I went into the code and found that the generated code for my mediaType was using pointers for the 3 data fields. I removed that and now it compiles.</p>
<p>The question remain, is it an error with the generator and I have to do that for every mediatype that it generates or am I making a mistake? </p>
<p>I have another question regarding the bytes length shown on the terminal, what exactly is it counting? It doesn't seems to be counting the length of the bytes being sent to the client. I've tested on multiple compression level of gzip and it stays the same.</p>
<hr/>**评论：**<br/><br/>bketelsen: <pre><p>goa uses pointers because it makes it easy to determine if you're given an empty string vs a zero value. "" is different from an unitialized (and un provided) string, so a pointer will let you determine whether you were provided that field, or whether it came empty. To fix your problem, declare your strings before your struct. </p>
<p>See this simple example:</p>
<p><a href="https://play.golang.org/p/UynBuUKaEM" rel="nofollow">https://play.golang.org/p/UynBuUKaEM</a></p>
<p>goa is doing the right thing here by protecting you from deserialization problems with Go and zero values. </p></pre>Kraigius: <pre><p>Thank you very much!</p></pre>raphaelsb: <pre><p>goa generates pointers because the attributes are not defined as required in the design so could be nil at runtime. If that's not the case and you know they will never be nil then change the design and add a Required statement, something like:</p>
<pre><code>Attributes(func() {
Attribute("id", UUID, "Unique identifier")
Attribute("href", String, "User API href")
Attribute("email", String, "User email", func() {
Format("email")
})
Required("id", "href", "email")
})
</code></pre>
<p>This will cause the generated data structures to not use pointers for the corresponding fields.</p></pre>Kraigius: <pre><p>Thanks for the help!</p></pre>raphaelsb: <pre><p>Ah and the "bytes" value is the number of bytes encoded by the application encoder before any higher level processing (such as compression).</p></pre>Kraigius: <pre><p>Thank you.</p></pre>shovelpost: <pre><p>Is it really necessary to use a framework with special DSL to write microservices in Go?</p></pre>Kraigius: <pre><p>Absolutely not. The language have all the standard packages necessary to write microservices.</p>
<p>I do know how the community feel about using frameworks and I appreciate the concerns to keep complexity and speed to a minimum.</p>
<p>However, my time is limited. When I evaluated my options Goa came at the top because it's one of the only framework out there focused on developing a RESTFUL API.</p>
<p>Let's be honest here, I don't know enough about HTTP and the related RFC to do all of this by myself.</p></pre>interactiv_: <pre><blockquote>
<p>I do know how the community feel about using frameworks</p>
</blockquote>
<p>Only a vocal minority complains about other people using frameworks. Unfortunately this minority makes the whole Go community look really shitty, pedantic and close minded.</p>
<p>The fact is the default server mux is useless on its own for anything serious. You can't write a maintainable application with it, you have to come up with a way to support url parameters , match handlers by methods ,a middle-ware stack, a way to inject dependencies into your handlers to make them testable and co ... And no ,the solutions involving a bunch of closures , or global variables like the gorilla-toolkit do not lead to maintainable code.</p>
<p>I'm pretty sure the OP questioning your choices don't even use that on its own. He is just doing some virtue signaling and think he can get away with that attitude because that's the community mindset. </p>
<p>Ignore that, and think about your requirements, if a library fits your requirements then go for it.</p>
<p>.you don't owe that person anything, his opinion doesn't matter.</p></pre>paddie: <pre><p>Also, GOA gives you automatic swagger specification for your API to document and auto-generate clients. Try doing that with the standard library, I dare you.</p></pre>interactiv_: <pre><p>Are you questioning his choice because you don't like Frameworks ? why do you care ? it's not like http.ServerMux is going to get anyone very far . Are you a go core library purist ? you never used a single library that you didn't write in all your life ? </p></pre>
