Hacker News Reader

Comment by tekstar | Hacker News Reader

Nice demo. A few things you could add to make this more realistic to something that gets shipped:

-CORS support. Deploy this to a non-local domain and try to reach it from a web browser and it will fail. I like https://github.com/rs/cors. I had rolled my own but then moved to that library.

- input validation. I like go-playground/validator.

The other big issue is the locking by hand around the task store. In reality usually there would be a database to handle concurrent read/writes. I use SQLite in production. I know this is just a demo and you want to use just stdlib, but serializing all data access is sort of unacceptable as a solution in a concurrent language like Go. When I'm not handling concurrency with SQLite I like to implement The actor pattern, having a persistent goroutine listen and respond to "taskstore" requests via channels.

View on HN

You are implying that "realistic" uses would be using multiple domains and have browser calls between them. Why would that be?

This is common. Web apps frequently fetch data from other domains, whether internal or third party.

Agreed, but a common extension does not mean it is required, nor that it should be demanded that an example of making a REST service needs to show how to do it.

The example is simply the beginning. It can be extended as needed depending on your use case. This is how most things Golang work. You start with the basics and add what you need on a case by case basis.

If you want something with every bell and whistle out of the box, Golang is going to be a disappointment generally as that is not the Golang mentality.

There are of course sufficient frameworks in Golang these days to provide such things though. Hence the article clearly says "standard library" to indicate that it isn't the last word on how to setup a REST service in Go.

I guess I have a deeper point to make, which is.. if you're going to compare golang web libraries it's the details that are going to end up making your decision. Superficial comparisons will be misleading. Implement auth, CSRF, a "real ip" Middleware, request logging, graceful restarts, yes CORS, and then do a few REST endpoints with it to see how much boilerplate VS useful code you have to write.

Maybe this is just my opinion as I started a significant golang app with just vanilla stdlib and then added each of these complexities in turn, before switching to libraries to solve most of the boilerplate better than my hand-crafted patterns

I opened the article to begin with to see if it contained some argument for why using the standard library instead of a framework makes sense.

It contained no explanation or reasoning to that end. It is purely what it is titled as: An explanation of how to do it with the standard library.

In that sense I don't think there is anything wrong with it. It doesn't make any claims; it simply provides the information it said it would.

Also, one of the main selling points of Golang is that it aims to deliver functionality with minimal additional cruft/add ons. Many of the standard library things are this way and don't provide the "extra stuff" you are desiring.

You mention auth, but many of the frameworks for Golang don't even implement auth and merely provided the ability to add auth if desired.

Logging is a debatable topic because the "standard" logging method is very inadequate, and so each of the various frameworks has to just choose a random logging system to use. ( or several )

While some frameworks do offer the ability to restart without killing active connections / requests, it is a more generalized issue with any service in Golang. It is also best addressed by writing your service in a scalable fashion and doing a rolling upgrade. Stop sending traffic to an instance, wait till current requests are done, then kill it. It doesn't need to be addressed within the service itself.

Reply on news.ycombinator.com