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

31–40 of 109 posts

Re: Go in Production – Lessons Learned

#31

Post by jchw »

alexchamberlain wrote: post #29
jchw wrote: post #24

Earlier quoted context omitted.

Admittedly I liked Django's database layer but using it in Real World production has also left me feeling kind of... eh. Having automigrations and an ORM is fantastic 90% of the time. The other 10% of the time almost ruins the magic entirely. The ORM is not a panacea like SQLAlchemy nearly is. Issues with migrations in production can get surprisingly tricky surprisingly quick. The rest though I do not miss at all. Mi…

Using SQLAlchemy has been my biggest (technical) regret in my current project; it was great at first, but overtime it's made testing a lot harder and session/object management has led to subtle bugs.

I feel like it’s a great tool to have available because it has solutions for everything you might want, but I found myself preferring it more for scripting than for application servers. Never quite figured out how to properly handle database sessions, really.

Re: Go in Production – Lessons Learned

#32

Post by papaf »

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.

Your options are your http status are your application's status, which I think is what most of us are used to.

I used to use HTTP status codes in this way because I understood it was the correct REST way of doing things.

However, one day, a sysadmin contacted me to tell me that we had broken a release because our API was returning a 404. Actually it was a problem in the checking script that was checking for data that was no longer in the DB.

By making application codes equal to HTTP status codes, we had removed any way to distinguish between fatal errors and API results.

Re: Go in Production – Lessons Learned

#34

Post by buzzerbetrayed »

krainboltgreene wrote: post #25
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…

It sounds like what you've done is used a bunch of tools that weren't designed with web development in mind and made them do those things. That seems like not only a security issue but also an absolute mess to get into after you're done.

100% correct. That sounds like a nightmare. Most backend web devs don't have the desire/expertise to handle all the intricacies of web security.

Re: Go in Production – Lessons Learned

#35

Post by goatinaboat »

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.

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.

It's pretty infuriating actually. On a similar note I have to use certain command line tools provided by a third party vendor that exits 0 on failure, and writes something to STDERR (on success it exits 0 and writes something to STDOUT). The Unix conventions evolved over decades because they were consistent and useful.

Re: Go in Production – Lessons Learned

#36

Post by bsaul »

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"?

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.

Re: Go in Production – Lessons Learned

#37

Post by [deleted] »

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.

[deleted]

Re: Go in Production – Lessons Learned

#38

Post by thiht »

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've been writing Go services in production for ~5 years and I don't really agree. Go Web frameworks are usually what used to be referred as micro frameworks. They're great because they embed the bare minimum making the writing experience tolerable.

What you say is true, it's easy to do with stdlib, but it's neither enjoyable not readable. A router lib and a validation lib are realistically still needed.

The same applies for the sql package, it's basically unusable without at least something like sqlx.

Re: Go in Production – Lessons Learned

#39

Post by thiht »

idolaspecus wrote: post #13

> 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.

Can you at least explain why?

Re: Go in Production – Lessons Learned

#40

Post by pjmlp »

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…

Here is the thing, I have been doing Web development alongside native for a couple of decades now.

This Go enlightment seems to only touch those that don't realize that programming to interfaces was already a thing back in Objective-C and WebObject days, or using Smalltalk categories (later formalized as traits in Pharo).

Also that languages like Java and .NET also have a similar Http server on their standard library since Java 6 (2006) and .NET 2.0 (2002).

The reason we don't use them beyond toy examples, is that they don't scale when things start getting hard and something like IIS, ngix or similar is called into action.

Post reply on HN