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

21–30 of 149 posts

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

#21

Post by omginternets »

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…

What makes something a "real" DI framework? Wouldn't go.uber.org/fx qualify?

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

#23

Post by ankurpatel »

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.

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

#24

Post by jolux »

lostcolony wrote: post #19
permille42 wrote: post #17

Earlier quoted context omitted.

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…

By DSL...you mean XML/JSON? Because that's literally the only thing I've ever seen used for DI purposes. And then invariably there's still just two versions of any given injectable interface; the one used in production, and the one used in testing.

DI is a decoupling technique. You might only have two interfaces to begin with, but the rough idea is that writing to interfaces and using IoC allows you to make many changes by adding code without having to change old code.

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

#25

Post by lmarcos »

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.

I guess it's subjective. For me the clear advantage of building HTTP endpoints using Go (framework-less) over DRF, Swagger and others is: no magic, no annotations, no dependencies; I know exactly what's happening and I can build a tailored system that is adjusted to my needs. This leads to very performant systems that are highly independent of the current trends and, most importantly, to a high degree of ownership of the systems you are building.

The act of writing these kind of systems is IMHO, somehow, liberating.

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

#26

Post by jrockway »

AWebOfBrown wrote: post #13
jrockway wrote: post #3

Good introduction. A few thoughts: 1) Be careful with locks in the form "x.Lock(); x.DoSomething(); x.Unlock()". If DoSomething panics, you will still be holding the lock, and that's pretty much the end of your program. ("x.Lock(); defer x.Unlock(); x.DoSomething()" avoids this problem, but obviously in the non-panic case, the lock is released at a different time than in this implementation. Additional tweaking is re…

In the latter example, the question is really one of how tightly you wish to couple the application layer to that of the infrastructure (controller). Should the application logic be coupled to a http REST API (and thus map application errors to status codes etc), or does that belong in the controller? I don't disagree that it's more practical, initially, as you've described it. However, I think it's important to poin…

I don't think it's the worst thing in the world if you test your http.Handler implementation:

   w := httptest.NewRecorder()
   req := httptest.NewRequest("GET", "/foo", nil)
   ServeHTTP(w, req)
   if got, want := w.Code, http.StatusOK; got != want {
      t.Errorf("get /foo: status:\n  got: %v\n want: %v", got, want)
   }
   if got, want := w.Body.String(), "it worked"; got != want {  
      t.Errorf("get /foo: body:\n  got: %v\n want: %v", got, want)
   }
It leaves very little to the imagination as to whether or not ServeHTTP works, which is nice.

Complexity comes from generating requests and parsing the responses, and that is what leads to the desire to factor things out -- test the functions with their native data types instead of http.Request and http.Response. I think most people choose to factor things out to make that possible, but in the simplest of simple cases, many people just use httptest. It gets the job done.

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

#27

Post by laverya »

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 just be the normal map implementation. Maybe eventually with generics... (This is more of a language gripe than a stdlib gripe, though, and I'm sure that once generics come out we'll see a sync.Map that doesn't use interface {})

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

#28

Post by geodel »

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.

I think most people are expecting zero traffic so they do not need to waste even one min to write any REST server.

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

#29

Post by skjfdoslifjeifj »

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.

He could build it in Go much faster just by using a couple of additional libraries but he's purposely limiting himself to just the standard library for the purpose of these articles.

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

If you don't care that's fine, but there are lots of us that do. This is subjective, but I find the memory use and overall performance of Rails/Django/Spring Boot applications to be completely unacceptable and there are far too many breaking changes.

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

#30

Post by cwackerfuss »

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?

This is common. Web apps frequently fetch data from other domains, whether internal or third party.
Post reply on HN