Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go in Production – Lessons Learned

tdom.dev

Post reply on HN
Print view View original

61–70 of 109 posts

Re: Go in Production – Lessons Learned

#61

Post by lelandbatey »

willsewell wrote: post #51
ldelossa wrote: post #4

The more you get to know Go's stdlib the less and less youll think a web framework is necessary. Youll find that utilizing http Round Tripper along with the Handler interface in the http library will make middleware easy. Youll eventually dig into filepath and path methods for extracting path parameters from url paths. And logging and recovery will be a concept youll need to extend outside of just http and into the r…

I see this sentiment a lot in the Go community. I think it is reasonable in some cases, but there are many use cases (vanilla CRUD web apps) where a web framework is really helpful. The standard library is very low level. Want sessions? DIY. Want user auth? DIY. Want CSRF protection? DIY. The list goes on. It feels like a waste of time implementing these "solved problems" from scratch, but the biggest problem is how…

I find that this is a totally fine trade off to make until it isn't, and by then you're completely confined by your choice of framework. Better to use libraries built to compose around interfaces taken from the standard library so you lose none of the control. I'll also emphasize that doing it this way does make discovering the initial pieces harder than if they're all in one framework together, but I find the slight increase in research yields orders of magnitude improved results once your code starts to age past the two year mark and you reap all the reliability and composibility of the standard library.

Also, here's a list of out-of-the-box library implementations for all the features you mentioned:

Sessions: https://github.com/gorilla/sessions

CSRF: https://github.com/gorilla/csrf

User auth: https://github.com/qor/auth

Re: Go in Production – Lessons Learned

#62

Post by waheoo »

marcus_holmes wrote: post #49
bsaul wrote: post #36

Earlier quoted context omitted.

There’s an ongoing debate among go dev if the stdlib is enough or not to perform « real world » work (which isn‘t the case in other languages). This article is from someone who think it’s not. That’s interesting.

It's not really a debate. It divides fairly neatly along the lines of "has been writing Go for a couple of years" vs "has come to Go fairly recently". There's a well-trodden path of developers who were trained in PHP/Rails/JS/Django/etc starting on Go. Their first question is always "what framework should I use?" (you can see this being asked at least once a week on r/golang). They then go down that path, and find (w…

Some of them move back to PHP once they realise the PHP standard lib is actually rediculously full of helpful tools for web development and the idea of treating individual PHP files and the directory hierarchy as the routing structure makes everything so bloody simple. Pair that with apache and the newer mod php and you have an extremely easy to up and running situation. Development feedback loop is rediculous and everything is simple again.

Frameworks need to die.

Re: Go in Production – Lessons Learned

#63

Post by Philip-J-Fry »

marcus_holmes wrote: post #49
bsaul wrote: post #36

Earlier quoted context omitted.

There’s an ongoing debate among go dev if the stdlib is enough or not to perform « real world » work (which isn‘t the case in other languages). This article is from someone who think it’s not. That’s interesting.

It's not really a debate. It divides fairly neatly along the lines of "has been writing Go for a couple of years" vs "has come to Go fairly recently". There's a well-trodden path of developers who were trained in PHP/Rails/JS/Django/etc starting on Go. Their first question is always "what framework should I use?" (you can see this being asked at least once a week on r/golang). They then go down that path, and find (w…

We use standard library in production. Never had a problem with it. It's performance is great, the http.Handler interface is a great pattern too.

I rarely find myself straying far from the standard library. If there's something that takes a bit more code but doesn't bring a dependency then that's what I'll do.

I definitely agree that there comes a day where you just see the light and realise that simple is good, the standard library is good, and that you don't need most of the stuff a framework gives you. But it gets really hard convincing others that Go is a great language because it's not Rust. Don't know what there's so much hate for it in this community. I've never fell in love with a language like this before. It's just incredibly productive for me and fits my thinking perfectly.

Re: Go in Production – Lessons Learned

#64

Post by masklinn »

davidbanham wrote: post #56
RedShift1 wrote: post #50

Earlier quoted context omitted.

GraphQL only uses two HTTP methods (GET and POST). But they actually don't differentiate in their function: you can do any type of reading/writing kind of queries in both GET and POST requests[1]. POST requests are used because they allow for larger bodies. GraphQL defines the format of the reponse in case of errors[1] GraphQL doesn't use HTTP status codes to communicate out-of-the-ordinary conditions. You can expect…

And when intermediate proxies happily retry your small “delete the most recent record” request because it was a GET which is, in the rest of reality, guaranteed not to alter state on the receiving server except in the corner of the internet you’ve defined as your own it’s destructive?

RPC over HTTP pretty much always goes through POST, sometimes with the option of using GET for querying as an optimisation.

For graphql specifically, if you allow GET-ing the GraphQL endpoint (which usually isn't the case by default), it's trivial to ensure only queries go through that method.

Re: Go in Production – Lessons Learned

#65

Post by brunoluiz »

Around the ORM choice, I would stay with raw SQL Queries and use sqlc with to generate the boilerplate (structs and the repository itself). I have been using it and it is amazing. Only issue it only supports postgres, although it has beta support for other DBs.

https://github.com/kyleconroy/sqlc

SQLx is good for simple read queries, but iirc for write operations you still need to map things manually and reads with JOINs are a bit tricky. Gorm might be good for simple CRUD applications, but it's magic has a performance cost.

Re: Go in Production – Lessons Learned

#66

Post by tekkk »

So does the 2nd part's example snippet use transactions or what? Seems pretty dubious, even for an example. With Node.js I pass a function as a parameter to a transactional exec and any failure should rollback the whole thing. Don't know if that's the same with Go.

Re: Go in Production – Lessons Learned

#67

Post by initplus »

dastx wrote: post #19
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.

A downside of "200 for everything, error in the body" is that it locks you out from using off the shelf API monitoring tools. Now you need some custom monitoring tool that can read & understand your custom error bodies.

Re: Go in Production – Lessons Learned

#68

Post by maccard »

lelandbatey wrote: post #3

I wouldn't describe this as good lessons for using Go in production, I would describe this as "opinions I came to after building my first real Go web project." 1. You probably do NOT need a framework Use the default Go HTTP libraries. For the other functionality that you'll need, use libraries. If you throw in with frameworks like Labstack Echo, you're forever coupled to the incredibly specific and one-note behavior…

> You will need to read more of other peoples code than you will need to write your own code,

Any examples of good go web projects to look at? All of the ones I've found have fallen into either "directory dump" or "I'm an mvc but not really".

Re: Go in Production – Lessons Learned

#69

Post by boomlinde »

willsewell wrote: post #51
ldelossa wrote: post #4

The more you get to know Go's stdlib the less and less youll think a web framework is necessary. Youll find that utilizing http Round Tripper along with the Handler interface in the http library will make middleware easy. Youll eventually dig into filepath and path methods for extracting path parameters from url paths. And logging and recovery will be a concept youll need to extend outside of just http and into the r…

I see this sentiment a lot in the Go community. I think it is reasonable in some cases, but there are many use cases (vanilla CRUD web apps) where a web framework is really helpful. The standard library is very low level. Want sessions? DIY. Want user auth? DIY. Want CSRF protection? DIY. The list goes on. It feels like a waste of time implementing these "solved problems" from scratch, but the biggest problem is how…

> The standard library is very low level. Want sessions? DIY. Want user auth? DIY. Want CSRF protection? DIY. The list goes on.

That's not the sentiment expressed here. To implement these things from scratch is not the only alternative to using a framework.

Post reply on HN