6 ms·

Why I wrote gocraft/web

34 points by cypriss 13y ago

druska 13y ago
You never mentioned martini https://github.com/codegangsta/martini https://github.com/codegangsta/martini
- slogsdon 13y ago
  Martini is relatively new, so there's a good chance it was released after he started work on this.
- cypriss 13y ago
  As another commenter mentioned, I learned about Martini midway through writing this. I really like Martini - if it existed a bit earlier, I probably would have just used it and been happy. That being said, there are some differences between the packages. First, Martini has great plugin support because 3rd parties can inject their arbitrary type into handlers. On the other hand, gocraft/web has nested routers and middleware, which are really important for my own projects. This may be temporary, but gocraft/web also has faster performance because it does less reflection, and because it's router is O(log(N)) instead of O(N). (See https://github.com/cypriss/golang-mux-benchmark https://github.com/cypriss/golang-mux-benchmark , especially as you add more routes). Finally, I prefer a more consistent signature to my handlers. Martini optimizes for flexibility. And depending on how much you want to inject into your handlers, your argument list can get really long. Overall, I think Martini is absolutely great and think it's one of the best Go web libs out there.
  - recuter 13y ago
    So Gocraft/web stays around ~4ms no matter how many routes you throw at it essentially but Martini and others are ~20ms and sometimes much more? That can really add up. Most web apps don't have quite so many routes typically but its not unreasonable and I'm surprised routing is allowed to get so expensive in the other frameworks. Kudos to you, I was psyched about Martini so I'm going to see about fixing that for it at least. Edit: D'oh. Need coffee. No wonder it looked really bad to me, up to 70ms to do routing is abhorrent. Carry on. :)
    - cypriss 13y ago
      We're talking microseconds here, not milliseconds
    - druska 13y ago
      Additionally, some of these libs are unoptimized and performance will change with time. Either way, since the performance differences are so small, it's probably best to go with what's easiest to work with.
bicknergseng 13y ago
>>For instance, in Revel you need to put your controllers in a package called ‘controllers’, and models in a package named ‘models’. Nope! I'd love some opinions on this. I prefer separating models/views/controllers, but have recently seen some mvc apps where models/views/controllers are grouped together by function/name. Thoughts on the traditional MVC directory structure vs alternatives?
- bgaluszka 13y ago
  > but have recently seen some mvc apps where models/views/controllers are grouped together by function/name Can you put links to some of those apps that use that approach?
nemothekid 13y ago
I've been using go for some time but I've never seen this: Get("/hello", (*Context).SayHello) What is going on here? How is (*Context).SayHello being called?
- ghayes 13y ago
  I'm new to this syntax too, but I believe it's just a reference to the function `SayHello` as defined on the `Context*` type. That is, if you have: func FuncA() { } // normal function func (int) FuncB() { } // function on an int object You could later reference those functions via: var func1 := FuncA // assign FuncA into func1 var var func2 := (int).FuncB // assign FuncB into func2 var But again, I'm just piecing that together from context and haven't looked at the spec.
  - recuter 13y ago
    So you're (ab?)using this to peg middleware functions on the context object? Why do it like that?
  - nemothekid 13y ago
    I was missing that piece, but how is func2 called? I'm still looking through the code, but if both func2 and a int_variable are interface{}, how does the compiler check these types (or is the "framework" using some reflection?)
- RBerenguel 13y ago
  This is calling the method assigned to a Context, which would be defined as func (c *Context) Something(whatever) {} If you have a w Context variable, you could do w.SayHello, with this you just call the function without an intervening variable, straight from the definition
dreamdu5t 13y ago
Just curious, but why have request be different from context? The request is the context.
- regecks 13y ago
  While using gocraft/web I've slowly come to the realization that it would be very convenient if the Context already knew about the Request and Response (without me having to pass web.ResponseWriter everywhere).

34 points by cypriss 13y ago

druska 13y ago

You never mentioned martini https://github.com/codegangsta/martini https://github.com/codegangsta/martini

slogsdon 13y ago
Martini is relatively new, so there's a good chance it was released after he started work on this.
cypriss 13y ago
As another commenter mentioned, I learned about Martini midway through writing this. I really like Martini - if it existed a bit earlier, I probably would have just used it and been happy. That being said, there are some differences between the packages. First, Martini has great plugin support because 3rd parties can inject their arbitrary type into handlers. On the other hand, gocraft/web has nested routers and middleware, which are really important for my own projects. This may be temporary, but gocraft/web also has faster performance because it does less reflection, and because it's router is O(log(N)) instead of O(N). (See https://github.com/cypriss/golang-mux-benchmark https://github.com/cypriss/golang-mux-benchmark , especially as you add more routes). Finally, I prefer a more consistent signature to my handlers. Martini optimizes for flexibility. And depending on how much you want to inject into your handlers, your argument list can get really long. Overall, I think Martini is absolutely great and think it's one of the best Go web libs out there.
- recuter 13y ago
  So Gocraft/web stays around ~4ms no matter how many routes you throw at it essentially but Martini and others are ~20ms and sometimes much more? That can really add up. Most web apps don't have quite so many routes typically but its not unreasonable and I'm surprised routing is allowed to get so expensive in the other frameworks. Kudos to you, I was psyched about Martini so I'm going to see about fixing that for it at least. Edit: D'oh. Need coffee. No wonder it looked really bad to me, up to 70ms to do routing is abhorrent. Carry on. :)
  - cypriss 13y ago
    We're talking microseconds here, not milliseconds
  - druska 13y ago
    Additionally, some of these libs are unoptimized and performance will change with time. Either way, since the performance differences are so small, it's probably best to go with what's easiest to work with.

bicknergseng 13y ago

>>For instance, in Revel you need to put your controllers in a package called ‘controllers’, and models in a package named ‘models’. Nope! I'd love some opinions on this. I prefer separating models/views/controllers, but have recently seen some mvc apps where models/views/controllers are grouped together by function/name. Thoughts on the traditional MVC directory structure vs alternatives?

bgaluszka 13y ago
> but have recently seen some mvc apps where models/views/controllers are grouped together by function/name Can you put links to some of those apps that use that approach?

nemothekid 13y ago

I've been using go for some time but I've never seen this: Get("/hello", (*Context).SayHello) What is going on here? How is (*Context).SayHello being called?

ghayes 13y ago
I'm new to this syntax too, but I believe it's just a reference to the function `SayHello` as defined on the `Context*` type. That is, if you have: func FuncA() { } // normal function func (int) FuncB() { } // function on an int object You could later reference those functions via: var func1 := FuncA // assign FuncA into func1 var var func2 := (int).FuncB // assign FuncB into func2 var But again, I'm just piecing that together from context and haven't looked at the spec.
- recuter 13y ago
  So you're (ab?)using this to peg middleware functions on the context object? Why do it like that?
- nemothekid 13y ago
  I was missing that piece, but how is func2 called? I'm still looking through the code, but if both func2 and a int_variable are interface{}, how does the compiler check these types (or is the "framework" using some reflection?)
RBerenguel 13y ago
This is calling the method assigned to a Context, which would be defined as func (c *Context) Something(whatever) {} If you have a w Context variable, you could do w.SayHello, with this you just call the function without an intervening variable, straight from the definition

dreamdu5t 13y ago

Just curious, but why have request be different from context? The request is the context.

regecks 13y ago
While using gocraft/web I've slowly come to the realization that it would be very convenient if the Context already knew about the Request and Response (without me having to pass web.ResponseWriter everywhere).