Bayle Shanks's website: notes-computer-programming-goWebDev

dev Go gin

ilozinski 12 hours ago [-]

Gorilla mux is way overrated and overused. I'm not sure why it's the first choice for so many people. There are much better alternatives such as https://github.com/julienschmidt/httprouter or https://github.com/gin-gonic/gin.

mmgutz 1 hour ago [-]

Along the same tone, httprouter doesn't allow defining these routes simultaneously

    users/:id
    users/watching

Was kind of surprised as we have many routes like that. Like gorilla/mux, I think it was just first (trie-based mux). Isn't gin based on httprouter?

There are even better muxes now. `pressly/chi` is used by heavy hitters in production and takes advantage of Go 1.7 HTTP context. `labstack/echo` is another highly recommended by others but I don't like the non-idiomatic echo.Context in handler signatures.

Back on topic, I hope the go web examples only imports built-in packages. The gorilla/mux example could easily be written to use built-in packages.

sethammons 5 hours ago [-]

I avoid httprouter because it doesn't adhere to the standard library interface for http handlers. I've not used gin, but it looks to also not follow the standard library interface here. Also, it does not appear to make use of newer developments in Go such as the context package (it imports the x/pkg version but does nothing with it I think).

AsyncAwait? 8 hours ago [-]

Part of the reason is that gorilla/mux uses identical API to the standard library.

more on pressly/chi

https://github.com/pressly/chi https://news.ycombinator.com/item?id=13106683 chi is similar to kami? [1] https://devhub.io/repos/diyan-go-web-framework-comparsion http://libs.club/golang/web/http-routers

---

dev

bogomipz 3 hours ago [-]

>"It's client-side sessions versus server-side sessions, and JWT is just one (bad) option among many for client-side sessions."

What you recommend then instead of JWT in a non-Rails environment?

tptacek 3 hours ago [-]

The equivalent of ActiveSupport::MessageEncryptor?. Virtually every platform has something. Go has crypto/cipher.AEAD. Python has fernet. Most platforms have access to Nacl's "secretbox". All of these things are simpler, safer, and just as effective as JWT.

tptacek 5 minutes ago [-]

JWT is popular with application developers. I think that's because it's cross-stack. Rails developers already have solutions for 95% of the problems JWT solves in the real world. So do Django developers, and so do Go developers, and so do PHP developers. But there's no lingua franca for this problem.

Developers would like there to be one. Unfortunately, they've chosen a terrible standard --- just really, really bad --- to run with. You are better off doing something by hand than using JWT. If you're at all familiar with my ouvre on HN: that's how bad JWT is. I think you might seriously be better off DIY.

---

bitexploder 3 hours ago [-]

Sort of funny, that is more or less exactly the stuff we needed for our internal candidate assessment app built on go/http. It just makes sense and is stuff you will want in any app, even a mostly CRUD one.

FWIW, gophish is a very clean app built using Gorilla packages that implements these patterns in a comprehensible way and I found it very helpful as I was implementing things.

---

https://github.com/thewhitetulip/web-dev-golang-anti-textbook/

---

adamnemecek 12 hours ago [-]

I know this isn't a book but if you need a go development environment, cloud9 (https://c9.io) ended up being a surprisingly productive environment. Like for go development, it's been better than anything I've tried to setup locally and the IDE even has go autocomplete.

---

omginternets 4 hours ago [-]

Anybody have experience with Echo? [0]

[0] https://echo.labstack.com/

nathancahill 3 hours ago [-]

Yes, I use it for several microservices, running for about a year now in prod. It's excellent.

---

Spiritus 6 hours ago [-]

Something like this will hopefully get the point across on how to handle "multipart/form-data" forms. It will print the content of the upload to the server's stdout.

https://play.golang.org/p/DiNGdl27kE

You can use curl to test it out (it assumes a file called "foobar.txt" is available):

    curl -v -F upload=@foobar.txt localhost:8080/upload

---

dev go

brightball 4 hours ago [-]

Totally agree. It's because of stuff like this that I find Go to be fairly tedious for full stack web. JSON microservice that's blazing fast is great. High concurrency workload, great.

Full stack website that reuses template parts with live data, manages sessions and logins, images, JavaScript? and CSS...not so much.

grey-area 4 hours ago [-]

Just curious, what were the worst gaps in functionality and have you looked at it recently? I'm pretty happy with Go for full stack web apps, but it did take a little while to get up to speed and a few years ago there were fewer solutions for common problems available. A few areas where it required some more work:

Authentication - there are a few good examples out there, I think gorilla secure cookie is good, CSRF protection too.

Authorisation - had to write my own version of the ruby lib cancan, am now happy with the solution

Images - stdlib is pretty good but it'd be nice if it handled resizing images and exif orientation tags.

Javascript and CSS - there are some ports of minifiers in go so an asset pipeline is pretty easy.

ORM - I use a query builder and use the map columns->fields in code, not keen on the orms using reflection and/or struct tags to do so. This doesn't have to be complex though.

Migrations - there are a few libraries out there now, so this isn't bad, I prefer sql migrations.

Templates - love the context-sensitive escaping, would be nice if it handled layout/partial but this is doable with some tweaks.

Forms - generation of views with text/template is pretty handy to handle things like CRUD forms for models.

This is where frameworks are useful - they present best-practices for the above details and more that you have to handle in a full-scale webapp.

I think those are the areas I'd like to see more tutorials on for beginners coming to Go, but there are solutions out there nowadays (far more than even a few years ago).Most of the things you mention are not in the std library so I guess people feel a little lost when they first arrive in Go land, but there are a few libraries out there like gorilla which cover most of this stuff or you can write your own, and once you have it's a really pleasant language to write traditional server-side apps with.

So with the above caveats I'm really happy with it for full stack web development.

christophilus 3 hours ago [-]

I'd love to see some blog posts about this. The lack of any good resources on full-stack web frameworks is what has kept me from really diving deep into Go. I still believe (pretty strongly) in traditional, server-rendered, low JS overhead websites / app.

brightball 3 hours ago [-]

My biggest issue was with server rendered applications. I think it's a good fit for SPA's where each piece is rendered to the browser independently.

Just as an example, my go to test for most programming languages is to rebuild my personal site with it (http://brightball.com/). Just provides me with a good exercise in running through a simple project that I've done in multiple languages and provides a good basis for comparison without getting too fancy.

If you'll look at the page layout, you'll see the main content area with a list of articles, some sidebar elements that are loaded from the database and a list of primary tags in the footer (also pulled from the database).

The biggest pain point was the reusable elements (sidebar and footer) with the template system. In most other template systems it's pretty trivial to write parts that have code attached to them and tell a layout to call those pieces with some arguments. With Go, that was a bit of a pain requiring all of the data that that would appear on the page to be retrieved before starting the rendering process. That led to a lot of repetition to pull in that data on every path to the layout.

So the layout/partial system would be my biggest pain point. My first instinct was to go and reach for a framework but so much stuff that I read on Go boards gave the impression that the community seemed to have a very negative impression there.

Additionally, there wasn't a clear winner among frameworks which made me hesitate. That's a problem you see in languages that have so much stuff for the web built in like PHP and Javascript. It becomes so easy to do-it-yourself on the framework front that there are a million different flavors and no clear path.

With Ruby, Python, Elixir, Groovy, etc there are clear and dominant frameworks for the language. If you learn this language, you should know framework "X". When there isn't that clear winner, it's hard to justify investing in developing around it.

To try to get around that issue and the sense that with Go you were supposed to sort of assemble your own parts, not commit to a framework, etc I tried https://github.com/runemadsen/ok-go since it's basically a framework of assembled and replaceable parts.

After a while I just gave up on it and started looking at porting to Hugo before I found out about Elixir and gave it a shot. Ultimately, that was exactly what I was looking for (http://brightball.com/articles/insanity-with-elixir-phoenix-...).

Most of the issues I describe are non-issues if Go is backing a React/Angular app instead. I just found it to be a huge pain for entirely server side applications.

grey-area 2 hours ago [-]

My biggest issue was with server rendered applications.

Thanks, this is what I'm talking about too (server-side web apps), I've found it a good fit, but do understand the initial difficulties with html/template - it is not very user friendly and was not designed for the sort of layout/partial arrangement that almost every web framework uses, however it can be used in that way with a little tweaking. That data has to be retrieved somehow though for the sidebar say, so I don't mind having to pass it in explicitly - it at least makes all the work being done explicit.

Agreed on the frameworks issue, frankly I find the hostility to frameworks on places like /r/golang tiresome and cultish - there is the kernel of a good idea in rejecting frameworks (they can after all straightjacket your code and invert control), but there can be many benefits to them and they provide essential pointers for those new to the language. I think for Go to grow it does need people to start to coalesce around solutions so that beginners don't have to reinvent rails again for every app or (worse IMO) start using JS for frontend and Go for backend - then you have two problems (or 400,000 if you use npm). I prefer server-side only and am happy with Go for that.

Elixir is on my list to check out, thanks for the link.

irq-1 1 hour ago [-]

The templating is fast and safe but a pain to use. For example, an HTML Select needs a 3-value list: id,text,selected bool. You can't evaluate a comparison (if...) or call a function in the template. It's unpleasant.

grey-area 1 hour ago [-]

You can call functions and methods in templates, and you can use if else, they actually have all the tools you need to do things like provide helper functions and produce a full html select with something like:

    {{ select "Order" "form_name" .value .options }}

Granted those helper functions don't exist in the base templates, but the tools are there to build them.

---

Simple Golang HTTPS/TLS Examples

https://gist.github.com/denji/12b3a568f092ab951456

sethammons 5 hours ago [-]

I would replace gorp with https://github.com/vattle/sqlboiler. Granted, I've not used either, but I like the philosophy behind sqlboiler. I feel it is more in line with Go principles. I also believe gorp will have issues with the new DB context stuff (though I'm not positive on that).

---