The problem with Go’s default HTTP handlers

Re:The problem with Go’s default HTTP handlers by morelisp on Tuesday August 09, 2022 @07:03PM (#32405752)

Now do a body that requires literally any transformation or generation at all. Say, a series of DB query results as a CSV. (Oh, and make sure to cancel work when the request disconnects!)

Or heck, just try adding some error handling from the `io.Copy` result to what you have.

[ Parent | on HN ]

Re:The problem with Go’s default HTTP handlers by suremarc on Tuesday August 09, 2022 @08:28PM (#32406478)

Just return an io.Reader that wraps the DB cursor and outputs CSV data... I fail to see what makes this so difficult. If the "mutable" approach involves passing down a mutable *http.ResponseWriter, then the dual approach of passing an io.Reader upstream is equivalent.

[ Parent | on HN ]

Re:The problem with Go’s default HTTP handlers by int_19h on Wednesday August 10, 2022 @02:03AM (#32408257)

This all is much more straightforward in languages with syntactic sugar for iterators, such as "yield" in C# and Python:

https://flask.palletsprojects.com/en/2.2.x/patterns/streamin...

[ Parent | on HN ]

Re:The problem with Go’s default HTTP handlers by morelisp on Wednesday August 10, 2022 @05:16AM (#32409482)

Love too make those async thunks!

[ Parent | on HN ]

Re:The problem with Go’s default HTTP handlers by morelisp on Wednesday August 10, 2022 @05:15AM (#32409476)

Try to write this, really. It’s such an unergonomic mess compared to for loop in the handler. It will also allocate a very complex reader that the actual version doesn’t need to.

[ Parent | on HN ]