A simple and effective Golang web framework

[Tom]

Hi,

I started meddling around with Go and I realized I really want to use it as a server language. However there's no easy way to create a seamless setup like you can with PHP and Apache or Ruby on Rails etc. Now I know that Go is different because it's compiled and it's not a scripting language but is there any good way to get a setup similar to that. Where I could have server side .go files that get executed? For now I came up with a hackish solution that puts together the code on compile: https://github.com/tombousso/GoServe. It's definitely not an ideal solution. Any better ideas or ideas for improving what I have?

Thanks.

[Robert Melton]

Tom--

Go is used to write server applications all the time. I might be
speaking out of turn, but I think that is its dominant use at the
moment. It seems like deconstructing an application into individual
source .go files that have to be on the server is a step backwards. I
quite like the ability to deploy a single binary and have a working
server.

What is the advantage of having a bunch of .go files on your server?
If you just want dynamic compiling, there are easier ways.

--
Robert Melton

[Tom]

Hi Robert,

I think that it's cumbersome to have all of our routes in one file. It's easier to manage, organize, and understand the flow when .go files can be placed separately. I mean lets take the simple login form example. Instead of using our main server Go code creating a virtual login.go file that has to be referenced in our HTML, it would be better if you could actually see the file and modify it on it's own. You shouldn't have to modify the main server file just to change one part of it. 

[Kyle Lemons]

On Sat, Aug 24, 2013 at 1:25 PM, Tom <tomb...@gmail.com> wrote:

Hi Robert,

I think that it's cumbersome to have all of our routes in one file.

 

You don't.

You can register your routes with http.Handle and friends in the init() for each file.

 

It's easier to manage, organize, and understand the flow when .go files can be placed separately. I mean lets take the simple login form example. Instead of using our main server Go code creating a virtual login.go file that has to be referenced in our HTML,

Why is your HTML referencing Go files?

 

it would be better if you could actually see the file and modify it on it's own. You shouldn't have to modify the main server file just to change one part of it. 

On Saturday, August 24, 2013 1:07:56 PM UTC-7, Robert Melton wrote:

Tom--

Go is used to write server applications all the time.  I might be
speaking out of turn, but I think that is its dominant use at the
moment.  It seems like deconstructing an application into individual
source .go files that have to be on the server is a step backwards.  I
quite like the ability to deploy a single binary and have a working
server.

What is the advantage of having a bunch of .go files on your server?
If you just want dynamic compiling, there are easier ways.

--
Robert Melton

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Tom]

Well the HTML is referencing Go files or routes in the <form> tag. And even if I had an init() function in the Go files how would I import them into the main server Go file? And if it's possible would they have to be in the $GOPATH directory?

[Justin Israel]

Don't you still need to rebuild the server every time you add a .go file to your public_html? So then what is the benefit at that point? Just that you have some tiny snippet of Go code that designates its route automatically when the application is built? How does your solution handle more dynamic routes that don't directly map to a single location in the public_html structure?

I've been messing around with Revel (http://robfig.github.io/revel/) lately, and it seems really straight forward to create as many controllers as you want, in as many individual files as you want, and just add more routes to the plain text routes file. And Revel has hot code reload, so that new connections just pick up the new version of the server. 

[Kyle Lemons]

I feel that there must be some misunderstanding here.  If you have a number of .go files in a directory, they are (or at least must be for the `go` tool to work) in the same package.  Thus, if you have a main.go that all it does is ListenAndServe, you can have a number of other files that all have an init() that register local functions with the http package.  When the binary runs, all of the routes are registered in init() and then served from main.

[Tom]

Ok that makes sense. And Revel seems like quite a mature and complete framework so I'll play around with it.

Thanks guys.

[Kevin Gillette]

On Saturday, August 24, 2013 5:22:26 PM UTC-6, Tom wrote:

Ok that makes sense. And Revel seems like quite a mature and complete framework so I'll play around with it.

I'd recommend at least writing a does-something toy app using only the standard library, to give you some perspective when you evaluate the strengths and weaknesses of any frameworks you come across. Unlike most other languages (and their standard libraries) used for web development, the invention of Go postdates the rise of the modern web (so Go's design has benefited from the clear hindsight of successes and mistakes that other languages have made, and what choices evolved with the web well, and which did not); PHP, Python, Ruby, etc all predate the popularization of the framework concept, and most or all of those languages' standard libraries are very unwieldy for web development. Go's net/http package and its standard library, on its own, is fully capable of handling all common (and most uncommon) aspects of http, including streamlined integration with related technologies, thus unlike with other languages, frameworks don't fulfill a technical "need" in Go, they may only lend some convenience (so it would be incorrect to assume that because other languages "need" frameworks to be effective at web development, Go or some other language X must also need frameworks). Frameworks often have a steeper learning curve then the stdlib -- net/http makes the delegation of responsibilities very clear, but "do everything for you" frameworks can sometimes involve a lot of research or expertise to resolve the question of whether doing something by hand will break the framework, or if there's some hidden way to make the framework do something that it wasn't quite designed for.

Several of the frameworks I've seen made for Go seem to be direct ports of frameworks from other languages, possibly made due to lack of understanding of the Go way of doing things (they like the Go syntax, but don't understand the Go semantics and style) -- frameworks aren't "good" in and of themselves, but can only be good when well coupled with the host language. A general lesson is that a good idea in one language often isn't the best idea in another language, and may often actually be an ineffective solution if blindly carried over (e.g. automatic routing, or script-level page serving may be a good idea in php, but is much less effective in Go, not to say that Go is any less effective as a web-serving language).

To this end, if and when you find the stdlib insufficient for your needs, http://www.gorillatoolkit.org/, as a "toolkit", is designed to enhance the standard library by adding some convenience functionality, without limiting your flexibility in the name of convenience like most "frameworks" do.  That said, I have never personally been inconvenienced by the standard library, and thus have had little reason to use third party solutions (so at least some of us are ecstatic to use just the included batteries) -- if you're going to use anything effectively, though, you should probably know how to do it using only the stdlib -- at that point you can effectively make an informed decision about what flexibility/convenience tradeoffs are worth the effort, and where, if at all, a given framework will be too limiting.

[Kevin Gillette]

PS: I'm not discounting the value of any particular Go web framework -- they just must be evaluated from the perspective that any increase in convenience upon an already well designed foundation can only come from being purposely designed to solve a specific task at the expense of unrelated tasks. If a framework's purpose precisely aligns with your needs, then it's a perfect solution -- otherwise, the 50% effort saving for 90% of tasks could incur as much or more than a 300% effort increase (compared to using the stdlib directly) to work around the 10% of cases for which a framework wasn't designed.

[Tony Worm]

++1 for Revel (http://robfig.github.io/revel/)

[Yunge]

I agree!

[Devashish Ghosh]

https://github.com/jabong/florest-core A lightweight workflow based REST API framework with features customized workflow, logging, monitoring, a/b test, dynamic config, profiling, swagger, database adapters, cache adapter.