Love the corrections, and I agree that it is weird that this tutorial uses Gin of all libraries to show of writing APIs with Go - Gin doesn’t even conform to the standard library’s net/http interfaces, you have to wrap any middleware that does conform.
One small nit-pick around the IDs, and it’s not even your improvements, but when you’re writing an API you should never (seriously can’t think of one reason why you should) let the user set record IDs. Ideally that should all be in the database (which is why using an in-memory database is an…odd choice).
Overall, Russ’s comments about the tutorial irk me a bit - if you want something narrow in scope, don’t choose to do something like a full-on RESTful API. Sure, it’s basic and common like spaghetti and meatballs, but like spaghetti and meatballs it takes a lot of work and a surprising amount of complexity to make it truly good. Like, auth is integral to how APIs work, interacting with a database is a key part of the API. Either give a disclaimer that those parts are going to be glossed over, or change the tutorial title to reflect that you’re focusing on RESTful endpoints or something.
I’m probably coming off overly grumpy about this, but I really love Go and I think we can do better when it comes to teaching aspects of the language. The rest of the documentation and (official) tutorials are incredibly good, no reason this can’t be as well.
I agree about the caller not having to generate the ID: I should have made that change too. :-) I’ve added a comment pointing this out and linking here at the bottom of the Unique album IDs section.
Agreed. As a nice contrast, I appreciate that The Go Programming Language almost always includes a comment when it ignores potentially important errors, even very early in the book.
Also, to focus on the positive, I agree with the OP that in general Go has “excellent documentation.” The blog posts about particular features of the language are also generally outstanding.
Love the corrections, and I agree that it is weird that this tutorial uses Gin of all libraries to show of writing APIs with Go - Gin doesn’t even conform to the standard library’s
net/httpinterfaces, you have to wrap any middleware that does conform.One small nit-pick around the IDs, and it’s not even your improvements, but when you’re writing an API you should never (seriously can’t think of one reason why you should) let the user set record IDs. Ideally that should all be in the database (which is why using an in-memory database is an…odd choice).
Overall, Russ’s comments about the tutorial irk me a bit - if you want something narrow in scope, don’t choose to do something like a full-on RESTful API. Sure, it’s basic and common like spaghetti and meatballs, but like spaghetti and meatballs it takes a lot of work and a surprising amount of complexity to make it truly good. Like, auth is integral to how APIs work, interacting with a database is a key part of the API. Either give a disclaimer that those parts are going to be glossed over, or change the tutorial title to reflect that you’re focusing on RESTful endpoints or something.
I’m probably coming off overly grumpy about this, but I really love Go and I think we can do better when it comes to teaching aspects of the language. The rest of the documentation and (official) tutorials are incredibly good, no reason this can’t be as well.
These comments resonate with me – thanks.
I agree about the caller not having to generate the ID: I should have made that change too. :-) I’ve added a comment pointing this out and linking here at the bottom of the Unique album IDs section.
I’ve been quite happy with using chi.
Me too. All new Go work I’ve done that justifies using something beyond the standard library has used Chi.
I strongly believe tutorials should never follow poor practices without at least identify them as poor practices.
Agreed. As a nice contrast, I appreciate that The Go Programming Language almost always includes a comment when it ignores potentially important errors, even very early in the book.
Also, to focus on the positive, I agree with the OP that in general Go has “excellent documentation.” The blog posts about particular features of the language are also generally outstanding.
I still don’t understand why people write rest APIs . They should be a code-gen
Can you expand on this sentiment?
Most probably, the parent comment relates to using some form of OpenAPI spec which can be done using the oapi-codegen for golang.
Oh ok, so kind of like gRPC.
Maybe they meant something like Apache Thrift and similar tools.