Why not use Goweb?

[matryer]

Please leave a comment and tell us:

• Why you chose not to use Goweb
• Did it lack something you needed?
• Do you think the project would benefit from an additional capability?

[tgulacsi]

Unscalable codecs - see stretchr/codecs#21

[matryer]

Thanks for the feedback.

On 3 Sep 2013, at 20:10, Islan Dberry [email protected] wrote:

I did not use goweb because I thought it would take longer to learn and understand goweb than it would to just write some code.

—
Reply to this email directly or view it on GitHub.

[oleksandr]

We tried to use net/http directly but ended up thinking again on generalizing response functions (read "controllers" used the same in different places), mapping requests and parameters to functions and keeping them the right RESTful way. It's an overhead from a project to project (not talking about small projects to roll out quicklt a bunch of resources). With Goweb we had to focus only on the following:

• configuration (solved using custom yml/ini files)
• dealing with database (we use goose for migrations there had to fork it to avoid hardcoded location of files/confs)
• dev/live environments (used python's experience and relied on Buildout/Supervisord to create reproducable dev/live environments with single processes management tool)

[oleksandr]

Such a relief :-) Even though Goweb put some constraints they are hackable. We didn't wont to end with Gorilla-based mambo-jumbo in Go ;-)

[an2deg]

I don't like a way how Goweb works with variables in mapping paths. It uses ugly github.com/stretchr/stew/objects (compare it with github.com/bitly/go-simplejson)
All Get* methods except GetString() return interface{} and I have to manually convert each value into proper type.
go-simplejson works in different way: Get() method returns Json object which has Int(), String(), Array() and e.t.c. methods. For example: js.Get("top_level").Get("array").GetIndex(1).Get("key").Int()

[matryer]

@an2deg we agree actually - so have tweaked the way Goweb deals with data by introducing the Objx package.

[an2deg]

@matryer Great!

[lukescott]

As a new user to goweb, these were my initial thoughts, right or wrong:

• Several external dependencies. Why stewstrings.MergeStrings("foo", "bar") and not "foo" + "bar"?
• Why Map(...anything...)? It's cool, but it's doesn't self document very well. Magical functions never do. Version 1 had more specific mapping functions. Why the change?
• Returning an error from a controller function, such as Before, returns an html page instead of a json object. Some pages need an error html page, others need a json object. For example, I have /api/* for my API, but /* is for the website.
• Default error handler advertises goweb. Pages like this should never say what is being used nor a version number.
• How do I add /invoices/[id]/pay and have my controllers Before/After methods work?
• [id] and {id} seem to be the same thing, at least in the context of /invoices/{id}/pay. /invoices//pay doesn't cause any errors when using {id}, so {id} seems to be optional as well. Still am not sure what the difference is.

[jaredbischof]

I would like to use Goweb to run a server application on port 80 as a non-root user. Is this possible with Goweb 2? Currently I'm using Goweb version 1 and I found that if I use setgid and setuid after starting a server as root with Goweb the new threads that Goweb serves are still owned by root. This leads me to believe if did setgid and setuid inside Goweb that I could fix this, but I was wondering if this could be handled more gracefully with Goweb 2.

[lukescott]

@jaredbischof You can do this without root using setcap. setcap 'cap_net_bind_service=+ep' /path/to/program

[jaredbischof]

That's actually precisely what I'm doing right now. :) I was just curious if there was a way to handle this inside golang for all threads.

[lukescott]

@jaredbischof Currently, not easily. That's a Go limitation though. It's difficult to ensure every thread does setuid/setgid (https://code.google.com/p/go/issues/detail?id=1435). setcap is actually safer because binding to port <1024 is all the program can do. privbind is another option.

[jaredbischof]

Yeah, I saw that issue. Noticed it was pretty old, so I thought it might
have been fixed. But, thanks for confirming I'm taking the correct
approach!

On Tue, Nov 19, 2013 at 1:45 PM, Luke Scott [email protected]:

@jaredbischof https://github.com/jaredbischof Currently, not easily.
That's a Go limitation though. It's difficult to ensure every thread does
setuid/setgid (https://code.google.com/p/go/issues/detail?id=1435).
setcap is actually safer because binding to port <1024 is all the program
can do. privbind is another option.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/49#issuecomment-28825776
.

[oleksandr]

Goweb mentioned on TheChangeLog:

http://lists.thechangelog.com/t/t-FB36C550D1F6B9A7