I'm working on a project which focuses on simple HTTP-related actions (to get my feet wet really). I'm using the net/http package, which I thought was very convenient for almost all requirements except that it seems a http.Server gives instructions to http.Client if and only if the client has established a connection.

I have learnt that

  1. I can use x/net/websocket to solve this problem.
  2. I can choose to use some long polling technique(I guess).
  3. I have also considered spawning a routine by my client to connect to the server repeatedly to simulate the notifications, like every 200 milliseconds.

I have implemented most of the functions using net/http, so I'm not sure if I should really move to websocket.

My question is: what is the common paradigm that Go engineers will use in this situation? Which is the most doable idea, or is there a better solution?

1 Answer 1


After some research, I have decided to stick to the http package and use strategy 3. With that being said, I will post what I found, just in case anyone finds them helpful:

  1. The WebSocket is a VERY good choice for similar problems, when both the clients and servers need to write/read the connection. However, the github.com/gorilla/websocket seems to be a better library compared to x/net/websocket, and some helpful examples using gorilla can be found here.
  2. The long-polling is another commonly used technique (according to the blogs I studied). But this requires more attention for errors, like when the client crashed and the tcp connection is closed by one side. The server must have some functions for such scenarios to handle requests gracefully.
  3. Using a constantly called http.Get is NOT a good choice! If a server using this technique has too many on-list clients, all the requests and connections from the clients may cause the server to crash, not mentioning some OS may limit the number of tcp connections a machine can hold. The reason I choose this idea is that I know I will never publish my server, so basically my server does not have to worry about performance. Obviously I will choose the easiest one.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.