21–28 of 28 posts
I've been using go-json-rest, which is by way of "just enough on top of net/http to make APIs easier." https://ant0ine.github.io/go-json-rest/ Gorilla is useful, but more for its range of standalone components than as a framework. https://github.com/gorilla Then you'll want database-related packages like redigo and gorp. https://github.com/garyburd/redigo https://github.com/go-gorp/gorp
Gorp is nice, although I prefer the sqlx-based flavor, Modl ( https://github.com/jmoiron/modl ).
I've been using go-json-rest, which is by way of "just enough on top of net/http to make APIs easier." https://ant0ine.github.io/go-json-rest/ Gorilla is useful, but more for its range of standalone components than as a framework. https://github.com/gorilla Then you'll want database-related packages like redigo and gorp. https://github.com/garyburd/redigo https://github.com/go-gorp/gorp
Gorp is nice, although I prefer the sqlx-based flavor, Modl ( https://github.com/jmoiron/modl ).
Gorilla does include a "context" library: http://www.gorillatoolkit.org/pkg/context
Earlier quoted context omitted.
It's not entirely that simple. The problem isn't that net/http is so amazing that it's silly to replace it; it's that the replacements aren't yet up to the challenge --- by which I mean, none of them are yet so much of a win that the cost of losing compatibility with net/http outweighs the benefits. Writing full-featured web apps in Golang in 2015 is still a lot like writing a Sinatra app was 8 years ago. It feels gr…
An alternative way to look at it would be "you are only building the 20% of Rails you actually need." I've never been a fan of full-fledged frameworks and prefer the more pragmatic method of only pulling in components that I need though.
Gorilla does include a "context" library: http://www.gorillatoolkit.org/pkg/context
Moving forward, of course, it's preferable to use the official context package: http://godoc.org/golang.org/x/net/context
Earlier quoted context omitted.
An alternative way to look at it would be "you are only building the 20% of Rails you actually need." I've never been a fan of full-fledged frameworks and prefer the more pragmatic method of only pulling in components that I need though.
https://github.com/rails-api/rails-api#why-use-rails-for-jso...
Earlier quoted context omitted.
https://github.com/rails-api/rails-api#why-use-rails-for-jso...
http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2...
Earlier quoted context omitted.
https://github.com/rails-api/rails-api#why-use-rails-for-jso...
http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2...
They probably would have drastically reduced the number of servers even if the rewrite was still in ruby, having much better understanding around the runtime requirements.
Ruby also seems like a questionable choice in the first place for such a service. Perhaps a prototype.
Nobody is pretending that MRI Ruby is the most performant runtime you can find, but that's just not an issue for 99% of web stacks.