REST Servers in Go: Part 1 – standard library

Post by laverya » Sun, Jan 17, 2021, 1:35 AM UTC

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.

  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)
  }

Post by sagichmal » Sun, Jan 17, 2021, 1:40 AM UTC

jolux wrote: post #24

lostcolony wrote: post #19

Earlier quoted context omitted.

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.

Post by AWebOfBrown » Sun, Jan 17, 2021, 1:49 AM UTC

jrockway wrote: post #26

AWebOfBrown wrote: post #13

Earlier quoted context omitted.

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

Post by virmundi » Sun, Jan 17, 2021, 2:26 AM UTC

sagichmal wrote: post #42

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…

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

Post by oppositelock » Sun, Jan 17, 2021, 2:37 AM UTC

bpicolo wrote: post #33

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