It's a nice reference program to show you what's going on. I build stuff like this for a living. I'd recommend not re-inventing the wheel yourself and using a nice web framework, like Echo ( https://github.com/labstack/echo ) or Gin ( https://github.com/gin-gonic/gin ). I prefer Echo due to a cleaner, mockable design, but they're equivalent. You can throw up that web server in 1/10 the code to do the same thing, and…
Show HN: A simple Go web server with logging, tracing, health check
61–70 of 97 posts
Re: Show HN: A simple Go web server with logging, tracing, health check
#62Earlier quoted context omitted.
Why do you want to move off of Django?
Because we're all using Go for other projects (even if piecemeal) and would like to build the entire project in a single language.
The good side to it being simple to understand and maintain is that you won't pay a lot of debt if you're adding it to your stack.
There isn't a single language that fits all use case perfectly anyway, so we'd have to just go to the "best tool for the job" approach in the meantime.
Re: Show HN: A simple Go web server with logging, tracing, health check
#63This reminds me of an ongoing discussion I was having with friends about Golang web frameworks -- one side of the argument is that you can achieve so much with the standard library that frameworks are "unnecessary", but folk like me want an ORM(ish) layer and some kind of back-office scaffolding. https://beego.me and https://iris-go.com are nice, but we (all) have (as yet) to find a Django-like framework that comes w…
Re: Show HN: A simple Go web server with logging, tracing, health check
#64Here's a quick attempt at the same thing in Java (although note that the command line format is different): https://gist.github.com/tomwhoiscontrary/b4888b86057c74a636c... The main takeaway is that the JDK's built-in web server is poor: * There is no way to configure timeouts * Filters have to be added to each handler separately, by mucking with its filter list * Filters have to extend an abstract class with two meth…
Re: Show HN: A simple Go web server with logging, tracing, health check
#65Earlier quoted context omitted.
To do all of this in just over a hundred lines of code without having to import packages to do it is pretty incredible. It may be just an exercise but it is a very cool one.
I never said it is not a cool exercise. I meant more like it is not something one would download and compile and run it... like it is not a useful tool. Just a cool one. And that is fine.
Re: Show HN: A simple Go web server with logging, tracing, health check
#66Here's a quick attempt at the same thing in Java (although note that the command line format is different): https://gist.github.com/tomwhoiscontrary/b4888b86057c74a636c... The main takeaway is that the JDK's built-in web server is poor: * There is no way to configure timeouts * Filters have to be added to each handler separately, by mucking with its filter list * Filters have to extend an abstract class with two meth…
Nice. Does anyone have a server like this but with the addition of * serving of files and directories * LetsEncrypt certificates and SSL
Re: Show HN: A simple Go web server with logging, tracing, health check
#67Golang is self sufficient for a small scale web app. It has HTML templates library, decent error handling, rpc, logging, built-in http server. Many people choose golang for that reason.
What do you mean by small scale? I think requests per second. Our Go-backed API has handled 90k rps without batting an eye. Or do you mean small scale as in team size? It is my understanding that Go was specifically designed to work for large organizations ( cough Google cough ). Or do you mean single page JavaScript web sites? At which point Go would be the backing API? I don't see what qualifies Go for "small scale…
Re: Show HN: A simple Go web server with logging, tracing, health check
#68Here's a quick attempt at the same thing in Java (although note that the command line format is different): https://gist.github.com/tomwhoiscontrary/b4888b86057c74a636c... The main takeaway is that the JDK's built-in web server is poor: * There is no way to configure timeouts * Filters have to be added to each handler separately, by mucking with its filter list * Filters have to extend an abstract class with two meth…
Nice. Does anyone have a server like this but with the addition of * serving of files and directories * LetsEncrypt certificates and SSL
Re: Show HN: A simple Go web server with logging, tracing, health check
#69Earlier quoted context omitted.
I disagree, I will always prefer projects with the least dependencies given two options with the same feature set. We should always try to strive to lower dependencies when it makes sense.
> We should always try to strive to lower dependencies when it makes sense. Maybe, but I think 'when it makes sense', might be 'rarely'. There a 2 ways to avoid dependencies: 1. lean on a batteries-included standard lib as this gist does or 2. write it yourself. Problem with 1. is standard lib libraries aren't always great, see 'where modules go to die' [1], (examples: httplib/urllib in Python, or the string librarie…
I'd encourage developers, especially Nodejs devs, to look at their list of dependencies and ask the following two questions about each of them:
1. How long would it take me to replicate this functionality?
2. How often does this functionality need updating?
There is a threshold balanced between both of those questions where, once the numbers pass, it makes sense to bring in dependencies. But I truly believe the "instant gratification" primate part of our brains tends to overestimate the benefit of dependencies and underestimate the long term negatives of them.
Here's a common Nodejs example: Request. Request is used all over many projects. Did anyone who imports it even try to use http.request in the nodejs stdlib? Its actually pretty great. Now, you introduced a new dependency. You made your build process longer. You made your deploy artifact bigger. You've got to keep it up to date. You've got to make sure there aren't security breaches. You've got to learn a new API that, unlike the Nodejs stdlib, is just made by "some guy somewhere" and is horribly documented inside a Github README.
How long would it take me to replicate the functionality of request just using http.request? It depends what parts of request I'm using, but probably very little time. How often does this functionality change? Literally never. Literally never. HTTP/1.1 was finalized decades ago. Request, right now, has 48 open PRs, 560 open issues, was last "released" a couple months ago, and was fixing security issues which were definitely already fixed in stdlib.
But the primate part of your brain says "Eh fuck all that, I'll let future self deal with the negatives of a new dependency, what I want today is an API interface that's, like, 20% easier to use."
Re: Show HN: A simple Go web server with logging, tracing, health check
#70This reminds me of an ongoing discussion I was having with friends about Golang web frameworks -- one side of the argument is that you can achieve so much with the standard library that frameworks are "unnecessary", but folk like me want an ORM(ish) layer and some kind of back-office scaffolding. https://beego.me and https://iris-go.com are nice, but we (all) have (as yet) to find a Django-like framework that comes w…
Which means the server side would need a way to wrap the db for graphql (along with a way to set up authorization), and the front-end would need to be able to discover/generate the crud parts.
If you really want a "legacy"/"traditional" framework (fat appserver handling form input, rendering html, talking to db backend), I think the mature ones will be hard to beat (eg: django).