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

71–80 of 109 posts

Re: Go in Production – Lessons Learned

#71

Post by InvOfSmallC »

papaf wrote: post #48
stouset wrote: post #43

Earlier quoted context omitted.

404 is literally the correct response for this behavior, per the HTTP spec. There was no server-side error. The requested resource was unable to be located because it no longer existed. You should return a 404 here, and not just for non-HTML API clients. Application-side fatal errors are in the 500 block. So yes, you absolutely can distinguish this case.

The requested resource was unable to be located because it no longer existed. I should have mentioned that the API was behind a reverse proxy. This leads to the following questions: Which requested resource is missing? The API itself or the item requested from the API? How does a client distinguish between these?

404 is a normal response code. Something is wrong in the infrastructure if you have this doubts.

Re: Go in Production – Lessons Learned

#72

Post by st1x7 »

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…

I'm not a backend developer and I can't comment on the actual framework vs no framework in Go discussion. What I want to say it looks a bit arrogant to portray yourself as this enlightenened person who has seen what would take other people years to understand, and to tell them that you won't bother to convince them but they'll understand one day.

There has to be a better way to communicate your point.

Re: Go in Production – Lessons Learned

#73

Post by sudhirj »

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 general advice is not DIY everything by using the stdlib, it's to use packages that conform to the stdlib interface, because doing so gives you infinite composability. All of the concerns that have been pointed out have good, testing and rock solid implementations available that you can just drop in, with mix and match from different authors and frameworks. All because they use the same interface.

This isn't even a new idea. Many Ruby on Rails plugins are actually Rack plugins (even to the point of Rails itself being implemented as a collection of Rack middleware). Rack is the interface that defines how a request is to handled, similar to the Go stdlib interface.

It's definitely true that idiomatic Go tends towards copying being better than dependencies, but the standard interfaces make it much easier to use and swap tried and tested dependencies because they all share the same interface.

Re: Go in Production – Lessons Learned

#74

Post by papaf »

davidbanham wrote: post #53
papaf wrote: post #48

Earlier quoted context omitted.

The requested resource was unable to be located because it no longer existed. I should have mentioned that the API was behind a reverse proxy. This leads to the following questions: Which requested resource is missing? The API itself or the item requested from the API? How does a client distinguish between these?

I can’t imagine any way a reverse proxy would generate a 404 or indeed any 4xx error within itself. Any such error would be coming from the upstream application server. If the API itself was not found that’s one of 502, 503 or 504. 200 responses with an error property is an antipattern precisely because of things like reverse proxies. They have no way to unpack and interpret every developers pet error format. They _d…

I can’t imagine any way a reverse proxy would generate a 404 or indeed any 4xx error within itself.

What if the configuration changes and the API path/URL is no longer in the reverse proxy config? What if the reverse proxy is dynamically configured and our application didn't register itself properly?

They _do_ understand http status codes and can act accordingly, like retrying requests, not caching responses, etc as appropriate.

Of course applications should return HTTP codes when appropriate e.g 500. The principle is that using HTTP codes for application specific information e.g item not found in DB, is a blunt instrument.

They have no way to unpack and interpret every developers pet error format.

I would argue that they don't need to. The conversation is between client and API at higher level than HTTP. HTTP codes are great for information such as "its broken", "please authenticate", "its busy". But HTTP codes are not so useful for things such as "item not in db", "parameter x is missing", "unsupported API version" because this information is nothing to do with HTTP.

Re: Go in Production – Lessons Learned

#75

Post by mmgutz »

SPBS wrote: post #59

To those who say frameworks are needed because the stdlib is not enough: No, the stdlib defines very clear interfaces that libraries can implement. The result is that you can drag and drop middlewares from multiple packages into your codebase, because they all conform to the universal middleware signature `func(http.Handler) http.Handler`. Want CSRF? Want Sessions? Want Auth? They all exist as separate packages (chec…

A much needed interface in stdlib is logging.

Re: Go in Production – Lessons Learned

#76

Post by cdent »

SPBS wrote: post #59

To those who say frameworks are needed because the stdlib is not enough: No, the stdlib defines very clear interfaces that libraries can implement. The result is that you can drag and drop middlewares from multiple packages into your codebase, because they all conform to the universal middleware signature `func(http.Handler) http.Handler`. Want CSRF? Want Sessions? Want Auth? They all exist as separate packages (chec…

Agree. I wasn't at all convinced by the examples showing the Echo was somehow better than using the "built in" signatures, especially since there's quite a bit of handling that Echo (and things like it) makes implicit that you'll probably want to be explicit in some edge case.

Coming from WSGI, I found go's middlwares familiar and positively pleasant.

I too ended up on Chi as the router that worked well without getting in the way.

Re: Go in Production – Lessons Learned

#77

Post by flarg »

st1x7 wrote: post #72
marcus_holmes wrote: post #49

Earlier quoted context omitted.

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…

I'm not a backend developer and I can't comment on the actual framework vs no framework in Go discussion. What I want to say it looks a bit arrogant to portray yourself as this enlightenened person who has seen what would take other people years to understand, and to tell them that you won't bother to convince them but they'll understand one day. There has to be a better way to communicate your point.

Learning over time isn't arrogance, it's just the truth

Re: Go in Production – Lessons Learned

#78

Post by tim44 »

st1x7 wrote: post #72
marcus_holmes wrote: post #49

Earlier quoted context omitted.

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…

I'm not a backend developer and I can't comment on the actual framework vs no framework in Go discussion. What I want to say it looks a bit arrogant to portray yourself as this enlightenened person who has seen what would take other people years to understand, and to tell them that you won't bother to convince them but they'll understand one day. There has to be a better way to communicate your point.

When given. I can't not be late. scrope

Re: Go in Production – Lessons Learned

#80

Post by bokwoon »

pjmlp wrote: post #40
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…

Could you explain what you mean by things start getting hard? Why did the languages you mentioned stop using their HTTP interfaces?
Post reply on HN