Goji: a web microframework for Go

fwiw, I prefer Revel better than Martini.

I agree, I don't see it here, but there are some that have a lot of decent addons, Gorilla being the big one among them.

But yes, short of robust routing, Go handles the micro framework fairly well out of the box.

Great job! It definitely feels like a microframework compared to others. I'm glad that there are so many starting points for Go web services available now of varying levels complexity. To me this feels like it fills the void between Gorilla and Revel/Martini/Beego. Also, the code is very well documented and easy to follow.

Actually, Goji grew out of a single deficiency in "pat": the fact that it does not have a standard way of defining request context.

The big use case here is how you'd write a middleware that did authentication (using API keys, session cookies, ???) and emitted a username for other middleware to consume. With net/http, you end up with a lot of coupling: your end handler needs to know about every layer of middleware above it, and you start losing a lot of the benefit of having middleware in the first place. With an explicit middleware stack and a universal interface for middleware contexts, this is easy: everyone can code to the same single context object, and instead of standardizing on weird bound variables (or a global locked map a la gorilla), you just need to standardize on a single string key and a type.

I think my ideal world would involve Go providing a map[string]interface{} as part of the http.Request struct in order to implement this behavior, but until we get that, I think Goji's web.C ("the context object") is the next best thing.

There's one other thing pat hacks around: the issue of how to pass bound URL variables to the resulting handler. At first I was a little grossed out at how pat did it, but I've sort of come to terms with it. I still think Goji's way is better, but I don't think it's the reason I wrote (or a reason to use) Goji.

I suppose the Go philosophy would discourage developers from tightly coupling Go types and their relational representations through an ORM. The idiomatic way of mapping your objects to a database is by defining a thin interface around a sql.DB, with first-class operations for your concrete types.

    type User struct {
        ID        int
        Permalink string
    }
    
    type Storage sql.DB

Then you can either do

    func (s *Storage) WriteUser(user User) error {
        if _, err := s.Exec(
            "REPLACE INTO users VALUES (?, ?)",
            user.ID,
            user.Permalink,
        ); err != nil {
            return fmt.Errorf("write user failed: %s", err)
        }
        return nil
    }

or

    func (u User) Write(storage Storage) error {
        if _, err := storage.Exec(
            "REPLACE INTO users VALUES (?, ?)",
            u.ID,
            u.Permalink,
        ); err != nil {
            return fmt.Errorf("write user failed: %s", err)
        }
        return nil
    }

It's a bit more laborious in the sense of keystrokes, but it's also more explicit, which is, on balance and over the lifetime of a large software project, a good thing.