Support config via query params

[zoidyzoidzoid]

Closes #12

• Add support for query parameters
• Add tests for them
  • Make sure we use the right API key / host / dataset

[zoidyzoidzoid]

I have a feeling this might not actually work.

I need to check what libhoney.Init does, since it might do some global state stuff.

[catouc]

I have a feeling this might not actually work.

I need to check what libhoney.Init does, since it might do some global state stuff.

I think I found out what libhoney.Init() does - there is a package level variable dc and package level functions like NewEvent() (see the actual code). The package level libhoney.Init() basically does a bunch of shenanigans around the config you passed, setting up transmissions and right at the end calls dc, err = NewClient(clientConf).

Unfortunately there is no Init() method implemented on the actual client struct so to make this possible we'd need to figure out what client we realistically need and build it up ourselves. Apart from that the rest of the exercise becomes straight forward because we could then just hold a HoneyClient *libhoney.Client in our Hook struct, then in the createEvent() function we call the NewEvent() function on our held client instead of the package level one.

The only problem I see currently is that we'd still have to create one client per incoming unique combination of the 3 query params since else we'd run into concurrency bugs and started writing stuff to other peoples honeycomb instances, which seems bad 🙃 We could hold them in a map indexed by the three URL params and have some GC running in the background? Definitely a bit of complexity here.