Show HN: Goatee – Redis, WebSocket notifications in Go (github.com)

40 points by johnernaut ↗ HN
Hey guys and gals! I'm learning Go at the moment and LOVING it. I was hoping to get constructive feedback on a project I'm working on - goatee - which is a notification server that utilizes Redis pub/sub and WebSockets. It's fairly bare-bones at the moment but I'm hoping to add in a lot more features as time goes on such as queueing and WebSocket channel subscriptions (via Go Socketio possibly).

29 comments

[ 0.22 ms ] story [ 62.9 ms ] thread
Hey guys and gals! This is a project I'm undertaking to help myself learn Go - which I think is AWESOME so far. Any suggestions or criticisms would be appreciated. I hope to add more features as time goes on (and possibly swap out the generic WebSocket implementation with go-socketio).
That name almost made me not click on the link...
It's hard to come up with good names for software projects. I agree, some are silly, but goatee seems pretty OK.

I have an unreleased template system, also written in Go, named goatee.

I choose it because I thought it was a nice riff on moustache.

Yeah it's cool, just reminded me of goatse
English is not my first language, so it might be because of that, but... I can't see any connection between "goatee" and "moustache", neither in spelling nor pronunciation. With "goatse", on the other hand...
(The connection there is that mustache is an existing templating system, and goatee is another kind of facial hair)
I can't see any connection between "goatee" and "moustache"

A goatee is a style of facial hair.

Ah, ok, now I got it, thanks :).
For me, it made this link stand out. I was thinking "am I so tired, or did Goatse-inspired something just got to the frontpage of HN?".

With dogecoins being all the craze this days, I wouldn't even be much surprised...

Where's the license?
Why does this have zero tests?
I have noticed that there are generally three kinds of software releases.

1. No code, just vaporware.

2. Some code, no to few tests, very little documentation.

3. Well written code, lots of tests, lots of documentation.

The first is annoying. The second sometimes contains interesting snippets if you're willing to dig. I read the code but am unlikely to use it. The last kind, when I find it, is gold. I use it, read the code, and refer back to it.

I have a theory that these kinds of code correspond to intent. Some people want to get something out (sometimes just words) and others want to provide something useful.

My zen koan is: if it were not for the chaff, you might not have wheat.

Thanks for checking out the repo! I'm hoping to have tests up in the next couple of days. This started out as a fool-around project and I wasn't actually anticipating it getting any attention. Tests are the top priority at the moment.
I don't understand, you've submitted the project here yourself?
I while ago I wrote something similar with a friend for fun. Redis, ServerSentEvents and Go: https://github.com/vivienschilis/eddy/

It's not so well documented but it's practically the same except that it uses ServerSentEvents on the client and has buffers so no message is ever dropped. Each messages contains the payload, a TTL and a channel size. The TTL is used to expire a channel automatically and the channel size can be used for example to create 1-deep channels for updating values like progress.

This is really great - thanks for sharing! I'll definitely check it out more when I have some time.
Feel free to PM me if you want to discuss the architecture/code/... @zimbatm on twitter
Shameless plug, but I also have a Go module named Goatee. However, it's a testing package: https://github.com/jprichardson/goatee-go It's too bad that discoverability of modules in Go sucks.
I'm not a Go developer (...yet), so I was wondering what about the discoverability of it sucks. I ask because I'm working on package management tooling for JavaScript and it's always interesting to see what is done well and poorly in other ecosystems.
If you're only pushing data realtime to down the client and don't need realtime upload, then consider Server-Sent Events (http://www.w3.org/TR/eventsource/) as an option.

SSE is HTTP-compatible, so for example works on mobile networks that force port 80 to go through "transparent" WebSocket-disconnecting HTTP proxy.

Additionally you get Flash-free polyfills for IE7+ and automatic reconnection on error built into browsers.