Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On Go’s Web Application Ecosystem

thechangelog.com

Post reply on HN
Print view View original

11–20 of 50 posts

Re: On Go’s Web Application Ecosystem

#11

Post by elithrar »

throwmeaway2525 wrote: post #8
valevk wrote: post #2

I think Go is still missing its killer-web-app-framework. But maybe it's better that way. Keeps out the people who don't like think before they code.

This article seems to be pushing Martini, which at first glance looks interesting (though it doesn't appear to have been mentioned on the mailing list even once, so there may be some boosting involved). There is Revel, but it seems to be getting a bad rap ("non-idiomatic" label used as a stick).

I mentioned Martini as I like its approach. It hit HN a few days ago and was on the go-nuts ML around the same time.

I don't expect everyone to agree with me surrounding Revel, but I certainly think it's lack of modularity is a negative.

Re: On Go’s Web Application Ecosystem

#13

Post by elithrar »

INTPenis wrote: post #6

What about web.go? I never tried it but it seemed promising.

As touched on in another HN thread: web.go isn't "actively" maintained by the author. Whilst any of the packages mentioned in the article could succumb to the same fate, I made an effort to highlight some of the longer running projects. Gorilla is probably the cornerstone here.

Re: On Go’s Web Application Ecosystem

#14

Post by taude »

I'm curious as to why everyone wants a web-framework in Go. Wasn't it primarily designed for back end service-type-of-stuff? Seems like there's plenty of full-stack and micro-web frameworks out there in what ever language you desire, that are in a more web-dev friendly syntax.

I guess I don't picture a company saying, we're going to use GO through-and-through for our dev platform. I picture it more as a "well, we now have a custom messaging service that needs to scale better" or something, much like when people choose to drop into C or C++. It also seems that there's more dev-friendly languages to build the web layer in.... I also don't see many web-dev types thinking in GO very well.

So, why GO at the web-layer?

Re: On Go’s Web Application Ecosystem

#15

Post by jws »

buro9 wrote: post #7

One thing I'd like to see in Go is a way to sanitise HTML based on a whitelist. This is to accompany blackfriday (Markdown) and text/template (templating). Markdown permits HTML, and this allows some scope for nasty stuff to get in, or for bugs that may exist in blackfriday to be exploited leading to HTML that could be the source of a XSS attack. We're currently running our user generated content through this: https:…

In moving a site from PHP to go in a rewrite, I'm about to head down that same road. The plan is to use the HTML parser from the "not quite in the real distribution but kind of official" net repository:

http://godoc.org/code.google.com/p/go.net/html

Parse the HTML, walk the result, write that which is acceptable.

I have to restrict by tag, url scheme, and url server name in various contexts.

Re: On Go’s Web Application Ecosystem

#16

Post by buro9 »

jws wrote: post #15
buro9 wrote: post #7

One thing I'd like to see in Go is a way to sanitise HTML based on a whitelist. This is to accompany blackfriday (Markdown) and text/template (templating). Markdown permits HTML, and this allows some scope for nasty stuff to get in, or for bugs that may exist in blackfriday to be exploited leading to HTML that could be the source of a XSS attack. We're currently running our user generated content through this: https:…

In moving a site from PHP to go in a rewrite, I'm about to head down that same road. The plan is to use the HTML parser from the "not quite in the real distribution but kind of official" net repository: http://godoc.org/code.google.com/p/go.net/html Parse the HTML, walk the result, write that which is acceptable. I have to restrict by tag, url scheme, and url server name in various contexts.

I looked at that myself, and decided that it wasn't the path I should go down.

ParseFragment throws an error on bad input, but actually I just want that stripped and to carry on processing things. If a user has put in a mostly usable piece of HTML and then got something wrong as an error rather than bad intent then permissiveness in how we handle that should rule.

And then I wondered about the wisdom of creating a potentially large security library on a not quite nailed down API.

Ultimately, given that this is a security thing, I figured it's best to go with the proven many-eyeballed solution that was had widespread acceptance.

Feel free to use the package we've provided, the bit of go code you need for it is:

    import (
    	"os/exec"
    )
    
    func SanitiseHTML(html string) (string, error) {
    	cleanse := exec.Command("java", "-jar", "/usr/sbin/cleanse.jar", "--permissive")
    
    	writer, err := cleanse.StdinPipe()
    	if err != nil {
    		return "", err
    	}
    
    	_, err = writer.Write([]byte(html))
    	if err != nil {
    		return "", err
    	}
    
    	err = writer.Close()
    	if err != nil {
    		return "", err
    	}
    
    	buff, err := cleanse.Output()
    	if err != nil {
    		return "", err
    	}
    
    	cleanse.Start()
    
    	return string(buff), nil
    }

Re: On Go’s Web Application Ecosystem

#17

Post by pstuart »

taude wrote: post #14

I'm curious as to why everyone wants a web-framework in Go. Wasn't it primarily designed for back end service-type-of-stuff? Seems like there's plenty of full-stack and micro-web frameworks out there in what ever language you desire, that are in a more web-dev friendly syntax. I guess I don't picture a company saying, we're going to use GO through-and-through for our dev platform. I picture it more as a "well, we now…

Because it's fast, a pleasure to code in, and simple to distribute.

Re: On Go’s Web Application Ecosystem

#18

Post by throwmeaway2525 »

elithrar wrote: post #11
throwmeaway2525 wrote: post #8

Earlier quoted context omitted.

This article seems to be pushing Martini, which at first glance looks interesting (though it doesn't appear to have been mentioned on the mailing list even once, so there may be some boosting involved). There is Revel, but it seems to be getting a bad rap ("non-idiomatic" label used as a stick).

I mentioned Martini as I like its approach. It hit HN a few days ago and was on the go-nuts ML around the same time. I don't expect everyone to agree with me surrounding Revel, but I certainly think it's lack of modularity is a negative.

I had searched for it to see what kind of feedback it was getting but came up empty:

https://groups.google.com/forum/#!searchin/golang-nuts/marti...

The Revel comment was more about a criticism I've read several times now.

I liked and bookmarked the article. :)

Re: On Go’s Web Application Ecosystem

#19

Post by jws »

taude wrote: post #14

I'm curious as to why everyone wants a web-framework in Go. Wasn't it primarily designed for back end service-type-of-stuff? Seems like there's plenty of full-stack and micro-web frameworks out there in what ever language you desire, that are in a more web-dev friendly syntax. I guess I don't picture a company saying, we're going to use GO through-and-through for our dev platform. I picture it more as a "well, we now…

For me:

• I prefer to find my errors at compile time. Consider the time to find and fix a missing method in a go compile (one 'make' and all the info is still in the developer's brain cache) versus eventually having a user drive the website into that method and having a mystery occur on a duck typed language. (hope you have good stack trace logging on the back end)

• I prefer a language that doesn't repeatedly break all my code. When I write and deploy a site, it should stay written. (Looking at you PHP. Granted, this was over a period of 15+ years, but all the more reason I don't want to go back and look at that code.)

• Efficiency is nice if you are ever going to hit a performance bottleneck. To elaborate: you get to defer the "OMG I need to map this load over more than one machine!" crisis for a while, and if you end up in a "I need N machines!", then making N smaller is good for your well being.

• Builds are fast enough that I don't care. I generally have a makefile for a website anyway to get everything organized and encoded, one more rule to build the go is no burden.

The weakest spot I'm finding is the html/template end. My strong typing evaporates at that boundary. I'd rather have the template get precompiled into go code and then compiled into functions with nicely defined interfaces on its parameters; faster to run and catch all those typos in field names. The current go mindset of a "go only", non-extendable, build command forecloses experimentation in this direction. (Unless you are a barbarian from the olden days, like me, and wrap everything in a Makefile.)

Re: On Go’s Web Application Ecosystem

#20

Post by rjknight »

taude wrote: post #14

I'm curious as to why everyone wants a web-framework in Go. Wasn't it primarily designed for back end service-type-of-stuff? Seems like there's plenty of full-stack and micro-web frameworks out there in what ever language you desire, that are in a more web-dev friendly syntax. I guess I don't picture a company saying, we're going to use GO through-and-through for our dev platform. I picture it more as a "well, we now…

Web servers aren't back end service-type-of-stuff?
Post reply on HN