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

31–40 of 149 posts

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

#31

Post by swirepe »

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…

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

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

#32

Post by hardwaresofton »

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.

What you're pointing to is the need for better abstractions and Go is not the language for that (it will be more-so when generics arrive).

There is a language that has faster-than-go speed and better abstractions, but HN seems to be somewhat decided on whether they think it's awesome or terrible, and there was recently an blog post on front-page about how it was bad for APIs (which I heavily disagree with but I am biased so I opted not to comment on).

Go definitely does have some other web frameworks that make work like this simpler, but on the other hand, people sometimes shy away from those because the stdlib is more universal.

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

#33

Post by bpicolo »

Defining them all on a single server struct means once you're past a handful you start having a hard-as-heck to organize folder of handlers (or a bunch of massive code files).

How are folk managing Go endpoint as apps scale across number of endpoints? I'm skeptical that one struct in one folder leads to good app structure, and have seen this start to break down in a few cases in practice

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

#34

Post by rad_gruchalski »

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…

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

And before 1.16, there is statik: https://github.com/rakyll/statik. Creates an embeddable file system from files or directories. It’s awesome for packaging web front ends into binaries.

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

#35

Post by ithrow »

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.

Some prefer clear, flexible easy to debug code instead of coding to 15 layers of abstraction. For an HTTP API you have to discard more than half of Rails anyway.

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

#36

Post by ascotan »

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.

1. simpler architecture - python typically requires multiple systems to deal with concurrency (ioloops, celery, etc)

2. execution speed - Django's ORM comes to mind

3. concurrency

That being said there are alot of great features with python web frameworks that come out of the box. You need to a lightweight project like gin/echo or something to get these features. Naked net/http is sorta like the 'erector set' of web frameworks.

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

#37

Post by [deleted] »

swirepe wrote: post #31
laverya wrote: post #27

Earlier quoted context omitted.

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

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

[deleted]

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

#38

Post by tekstar »

permille42 wrote: post #18
tekstar wrote: post #12

Nice demo. A few things you could add to make this more realistic to something that gets shipped: -CORS support. Deploy this to a non-local domain and try to reach it from a web browser and it will fail. I like https://github.com/rs/cors . I had rolled my own but then moved to that library. - input validation. I like go-playground/validator. The other big issue is the locking by hand around the task store. In reality…

You are implying that "realistic" uses would be using multiple domains and have browser calls between them. Why would that be?

I guess I have a deeper point to make, which is.. if you're going to compare golang web libraries it's the details that are going to end up making your decision. Superficial comparisons will be misleading. Implement auth, CSRF, a "real ip" Middleware, request logging, graceful restarts, yes CORS, and then do a few REST endpoints with it to see how much boilerplate VS useful code you have to write.

Maybe this is just my opinion as I started a significant golang app with just vanilla stdlib and then added each of these complexities in turn, before switching to libraries to solve most of the boilerplate better than my hand-crafted patterns

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

#39

Post by anderspitman »

rad_gruchalski wrote: post #34
laverya wrote: post #27

Earlier quoted context omitted.

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

> 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! And before 1.16, there is statik: https://github.com/rakyll/statik . Creates an embeddable file system from files or directories. It’s awesome for packaging web front ends into binaries.

How does statik compare to rice, which is what I had assumed everyone was using: https://github.com/GeertJohan/go.rice

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

#40

Post by anderspitman »

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…

> I've had this a few times, most recently with "how do I add this data file to my binary"

Ok fair enough, that one bit me too, but honestly I only felt cheated because Rust makes it so easy. `include_bytes!` was like cheating the first time I used it.

Post reply on HN