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

REST Servers in Go: Part 1 – standard library

eli.thegreenplace.net

Post reply on HN
Print view View original

51–60 of 149 posts

Re: REST Servers in Go: Part 1 – standard library

#51

Post by qudat »

ankurpatel wrote: post #23

Looking at such articles makes me feel we are going back in time rather than improving efficiencies for developers to build RESTful server. If you look at Ruby on Rails you can build the server shown here in one min that is scalable and backed with database. I know people will complain about speed of execution of language and framework but do you really care if you are not expecting Google like traffic.

“Setting up a server” has to happen only once. I’d rather spend a couple days setting something up that I have complete control over rather than using a one-line setup solution that I’ll have to rip out months later.

Re: REST Servers in Go: Part 1 – standard library

#52

Post by skjfdoslifjeifj »

virmundi wrote: post #48
sagichmal wrote: post #43

Earlier quoted context omitted.

Sure, but you don't need a framework or DSL for this in Go.

I don't need them in Java or Typescript. The benefit is that I don't have to write these boring, but necessary pieces. As applications grow larger, especially with Go's desire to have an interface with only one method/function, DI requires a lot of boilerplate. If there was a DI for go that used generate, then I would have compile time checking of dependencies. This would satisfy the community's sense of purity while…

> The benefit is that I don't have to write these boring, but necessary pieces.

The "boring, but necessary pieces" are usually just a call to a constructor. In my opinion it's almost never worth using a DI system that obfuscates dependency resolution and usually can't be checked at compile time just to avoid that.

Re: REST Servers in Go: Part 1 – standard library

#53

Post by earthboundkid »

alchermd wrote: post #20

I'm an API developer working with Python and Django. I did dabble with Golang for quite some time, but I just can't seem to justify the effort (in terms of lines of codes and static typing) of writing a ReST API with Go when I can build a similar one with Django and co (DRF, Swagger, etc). Can someone chime in? There must be an obvious advantage that I might be missing.

Every time I use DRF, I end up making some huge and horrible abstraction that I hate after its creation, like Dr. Frankenstein. So far, this has not happened to me with Go. I don’t know if the problem is just me or what, but I find Go easier to just define a data type, grab some JSON from the request, send some other JSON back without making myself crazy.

Re: REST Servers in Go: Part 1 – standard library

#54

Post by sagichmal »

virmundi wrote: post #48
sagichmal wrote: post #43

Earlier quoted context omitted.

Sure, but you don't need a framework or DSL for this in Go.

I don't need them in Java or Typescript. The benefit is that I don't have to write these boring, but necessary pieces. As applications grow larger, especially with Go's desire to have an interface with only one method/function, DI requires a lot of boilerplate. If there was a DI for go that used generate, then I would have compile time checking of dependencies. This would satisfy the community's sense of purity while…

> The benefit is that I don't have to write these boring, but necessary pieces

The component graph of your application isn't boring, it's the most important part of the thing, and the starting point for anyone trying to build a mental model of the thing. It should be front and center, never hidden away behind generated code.

Re: REST Servers in Go: Part 1 – standard library

#55

Post by erichanson »

laverya wrote: post #27
anderspitman wrote: post #8

I think I've managed to get by with less dependencies in Go than any other language. It somehow walks the line between JavaScript leftpad and Python "stdlib is where modules go to die". I don't think there's been a single instance where I've thought "why can't stdlib do this?" nor "why the heck is this in stdlib?"

> I don't think there's been a single instance where I've thought "why can't stdlib do this?" I've had this a few times, most recently with "how do I add this data file to my binary". At least that one made it to master now, and will be in 1.16! Another gripe is the lack of a proper parallel safe map (no, map[interface{}]interface{} like sync.Map is just not acceptable) which would be a godsend and should honestly ju…

This is so frickin' cool.

Re: REST Servers in Go: Part 1 – standard library

#56

Post by swirepe »

laverya wrote: post #41
swirepe wrote: post #31

Earlier quoted context omitted.

>I've had this a few times, most recently with "how do I add this data file to my binary". At least that one made it to master now, and will be in 1.16! Wait, how?? I've done some unholy things.

The best example for the new '//go:embed' directive I've seen so far is this: package main import ( "embed" "net/http" ) //go:embed assets/* var assets embed.FS func main() { fs := http.FileServer(http.FS(assets)) http.ListenAndServe(":8080", fs) } For the next month, the list of options here [0] will have to suffice. 0: https://go.googlesource.com/proposal/+/master/design/draft-e...

That's beautiful.

Re: REST Servers in Go: Part 1 – standard library

#57

Post by sagichmal »

virmundi wrote: post #47
sagichmal wrote: post #42

Earlier quoted context omitted.

The things you describe are pretty strongly understood as antipatterns in Go.

I hope to spur conversation on this. I've seen many in the Go community argue against abstractions. Many say, "Pass the database connection in the params." Or "make the DB pool a global variable". How can you write tests for logic without having to instantiate a DB? Many gophers appear to say I should have essentially a giant transaction script for each handler ( https://martinfowler.com/eaaCatalog/transactionScript.…

> Many say, "Pass the database connection in the params." ... How can you write tests for logic without having to instantiate a DB?

You define and use an interface to model the DB, and use that as the mock point. Basic stuff.

Re: REST Servers in Go: Part 1 – standard library

#58

Post by hit8run »

I’ve written a full stack web app with payment integration multi tenancy etc. in plain go. I learned a lot on that journey and what I learned made me value full stack frameworks like rails again. If you want to build something competitive you will need to write lots of things in plain go that you wouldn’t need to bother with when using rails or something similar with sane conventions.

Re: REST Servers in Go: Part 1 – standard library

#59

Post by throwaway894345 »

permille42 wrote: post #17
throwaway894345 wrote: post #15

Earlier quoted context omitted.

I've never understood the value proposition of a DI framework. Why would I want one when I can initialize my objects in main()? Is XML or JSON or whatever really that much more pleasant than wiring together Go objects?

The purpose of DI is to allow the use of a DSL to instantiate and connect objects, with configuration for those objects embedded into the DSL so that the setup and the way things work can be changed quickly without altering code. Mocking objects for testing purposes and swapping them for the real objects is also something commonly done that is helpful. There is no "real" DI for Golang as far as I've seen. The only DI…

I guess maybe this would be useful for a language like C or old-school C++ where you had to imperatively build your maps and lists and allocate memory and explicitly type your variables and so on, but Go memory allocation and typing are implicit and maps and lists have a nice literal syntax so I don't see any value in a DSL.

As for testing, you can already swap out real objects for test objects--that's a property that interfaces provide; I don't see how a DI framework (e.g, the DSL) helps you here.

I will say that when I've had to operate a Java application, trying to do even the smallest bit of debugging had me digging through all sorts of layers of XML nonsense (Spring, various Spring plugins, and who knows what else) to figure out where the logs were being written. Note that my objection isn't "XML" (versus some other format/DSL), but rather the pointless indirection. I'm sure someone proficient in Java would have no problem, but now your sysadmins need to be Java developers in addition to system administrators (maybe not such a big deal if your shop is already a Java shop and you have people you can ask, but for people operating third party software this is a real pain point). And again, all of that tedium for no apparent value.

Re: REST Servers in Go: Part 1 – standard library

#60

Post by throwaway894345 »

sagichmal wrote: post #57
virmundi wrote: post #47

Earlier quoted context omitted.

I hope to spur conversation on this. I've seen many in the Go community argue against abstractions. Many say, "Pass the database connection in the params." Or "make the DB pool a global variable". How can you write tests for logic without having to instantiate a DB? Many gophers appear to say I should have essentially a giant transaction script for each handler ( https://martinfowler.com/eaaCatalog/transactionScript.…

> Many say, "Pass the database connection in the params." ... How can you write tests for logic without having to instantiate a DB? You define and use an interface to model the DB, and use that as the mock point. Basic stuff.

To add to your answer for those who aren't familiar with the basics of mocking, here's a StackOverflow answer that I've shared with others--maybe it will help elucidate things: https://stackoverflow.com/questions/19167970/mock-functions-...
Post reply on HN