Comment by fixermark | Hacker News Reader

Comment by fixermark | Hacker News Reader

I recently implemented a RESTful resource mapper in go, which just accepts some basic parameters and an exemplar of a storable structure and wires up all the HTTP endpoints necessary to give users CRUD access to the resource.

I'm honestly very happy with how straightforward it was, even lacking generics---I solved the problem of no generics by basing the resource creation and management on JSON and a "Storable" interface that just defines key() and newEmpty() methods (so I have to write five lines of boilerplate for every struct that will be a resource... shrug). I didn't parameterize the storage logic, basing it on only a single NoSQL backend (BoltDB); however, parameterizing that side shouldn't be harder than wrapping the database access behind another interface.

I like the ability to switch between tight static typechecking and freer runtime typechecking on-the-fly, without having to build a large, complicated framework for either within the language. It may not be the most innovative language of the decade, but I think it's a pretty good combination of features for practical, high-performance web server development.

Would you care to share some code example?

Happy to; I'll share the whole thing.

http://pastebin.com/qBh6NRXc

It's not cleaned up for easy reading (hell, I haven't even run `go fmt` on it ;) ). But it has unit tests and seems to work. ;)

One thing worth noting is that it relies on the Storables to also be tagged with necessary JSON. It occurs to me that I could also have used tags instead of the key() function in the interface to specify which field in the Storable should be the resource name; key() is a bit more flexible in that the function could calculate the name using any method though.

Just for you, I did a code review. The code review has two revisions, one where I gofmt'd it because I can't read non-go-fmt'd code anymore, and a second where I added comments expressing some concerns. I'll be honest, I gave up on a few bits just because it wasn't fun to do; I strongly suggest rethinking the use of a storable interface vs taking an 'interface{}' value for both gets and puts akin to how the json stdlib does it.

You can see the comments here: https://gist.github.com/TheDong/ce1d7b86b88c86d972b6/revisio...

You should never post code without a copyright license or disclaimer attached and I'd appreciate if you rectified that forthwith.

Thanks for the review! I appreciate the feedback. One key piece that might have been unclear: since this code is part of a larger module (note package main), some of its parts live elsewhere. If I were to publish this, I'd consolidate those parts and build some proper module isolation here. OnStore is there purely because one of my resources needs to notify another part of the program that it has been stored; if I ever clean this up for public consumption, I'd probably want to add both pre- and post-handler hooks (along with the ability to add more rules and change the defaults, as Angular's $resource gives the client).

The advantage to the Storable is that other parts of the program can create and store those resources without needing knowledge of how keys are constructed. I also can't think of a way to do what empty() does without making it an interface function; "I need another copy of this unknown interface type" isn't something go has a clear solution for. Hypothetically, I could make empty() into a function that returns interface{}, take the key() suggestions you've given (though that leaks key-making knowledge), and then the whole thing would operate on interface{} type... Doable and more flexible, but not quite as clear on what resource will actually be stored and retrieved. Good tradeoffs.

A bit of feedback on feedback: avoid adjectives like "dumb" and "stupid." The signal-to-noise ratio is too low on them, and it makes for a harsher community (as other commenters in this topic have mentioned on their experiences trying to get help).

Reply on news.ycombinator.com