Go in Production – Lessons Learned • Hacker News Board

Re: Go in Production – Lessons Learned

#11

Post by jwcrux » Sat, Nov 07, 2020, 4:28 AM UTC

You almost certainly don't need a web framework. Over the long term, it's easy to find yourself boxed in with how opinionated many of them are.

Instead, if you build on the standard library, you can compose your application from there- a good muxer, some standard middleware that are generic http.Handler's, a session library, etc.

Re: Go in Production – Lessons Learned

#12

Post by tsjq » Sat, Nov 07, 2020, 4:47 AM UTC

chimen wrote: post #2

This article has almost nothing to do with Go in particular. Just...general stuff to follow when writing code. What is it here that talks specific things about "Go" + "in production"?

Haha. Just to attract more clicks

Re: Go in Production – Lessons Learned

#13

Post by idolaspecus » Sat, Nov 07, 2020, 4:48 AM UTC

> I recently got a DevOps job that mostly involves writing a new backend system in Go completely from scratch.

If this wasn't on the front page of HN I'd have stopped reading here, but it is, so I didn't, then I regretted it.

Re: Go in Production – Lessons Learned

#14

Post by vishnumohandas » Sat, Nov 07, 2020, 4:50 AM UTC

For configuration management, I've found viper[1] to be quite handy.

[1]: https://github.com/spf13/viper

Re: Go in Production – Lessons Learned

#15

Post by TheDong » Sat, Nov 07, 2020, 4:57 AM UTC

partiallattice wrote: post #9

tomohawk wrote: post #5

> silently handling panics That has a bad smell

Especially since caught panics amount to exceptions and most Golang code isn't exception safe. It's a recipe for leaking database connections, deadlocks, etc.

Go error handling is awful, but this isn't a fair.

In go, if you write code like the following:

    conn, err := db.Connect()
    defer conn.Close()

That defer will be run during a panic. Same thing as 'defer mutex.Unlock()'

Yes, like most of go, it's manual and painful and poorly thought out, but most people do follow these patterns, so for the most part go code will safely unwind from a panic.

Re: Go in Production – Lessons Learned

#16

Post by ampdepolymerase » Sat, Nov 07, 2020, 4:59 AM UTC

kortilla wrote: post #8

nsomaru wrote: post #6

Earlier quoted context omitted.

What path to this enlightenment would you recommend to one who has cut his teeth and delivered many projects (over many years) in Rails/Django?

This is a side effect of go’s lack of meta programming to be honest. So much magic that is possible in rails/django/etc is just not possible in golang. This leads to go web frameworks being sort of semi-hard mountainous turds of code generation. You’ll want to stick to stdlib after sifting through them and deciding they aren’t worth it.

After Django, writing database code manually in Go is not fun at all.

Re: Go in Production – Lessons Learned

#17

Post by jeffbee » Sat, Nov 07, 2020, 5:16 AM UTC

Why would you want to serve a 200 with an error message in a JSON response body?

Re: Go in Production – Lessons Learned

#18

Post by didip » Sat, Nov 07, 2020, 5:39 AM UTC

I personally like this combo as my "framework":

* go-chi/chi

* rs/zerolog

* html/template

* spf13/viper

* raw SQL

Re: Go in Production – Lessons Learned

#19

Post by dastx » Sat, Nov 07, 2020, 5:43 AM UTC

jeffbee wrote: post #17

Why would you want to serve a 200 with an error message in a JSON response body?

I've seen this pattern before, and one can argue that it is the correct one. Your options are your http status are your application's status, which I think is what most of us are used to.

The other one is http status codes are http status codes. As in the http request was done correctly, but the application code wasn't. More specifically, http layer was executed successfully, but the application layer was not.

Re: Go in Production – Lessons Learned

#20

Post by vasachi » Sat, Nov 07, 2020, 5:49 AM UTC

jwcrux wrote: post #11

You almost certainly don't need a web framework. Over the long term, it's easy to find yourself boxed in with how opinionated many of them are. Instead, if you build on the standard library, you can compose your application from there- a good muxer, some standard middleware that are generic http.Handler's, a session library, etc.

So, you chose a good muxer. Now, which of hundreds of logging, cors, sessions, jwt and permissions middlewares work with said mud and with each other best?

Or, and bear with me here, you can outsource those decisions to other folks, and just write your business logic.