Scroll refactor

[klizhentas]

I like this library as it simplifies our development a lot, however it is too tightly coupled, I would suggest to split it into the following set of independent packages with the following interfaces:

package fields //package that extracts parameters from the request and does error checking
package trace // package that wraps http.Handler and emits metrics and logs
package vulcan // wrapper that heartbeats the presence to vulcand when called
package response // wrapper that helps responding with errors and other responses
package service // wrapper that glues it all toghether.
package handlers // functions to create new http handlers
package app // package that glues it all toghether
package testutils // package for testing

Ideally these packages should be loosely coupled and only glued together as the last step.
In addition to that packages should try to be useful when working with standard library primitives and not require additional interfaces to be useful.

Here's an example of well thought interface:

https://github.com/codahale/http-handlers

[jeremyschlatter]

I'm a little resistant to this, and want to make sure we actually expect to use the packages separately. If we end up thinking of this library as one logical unit, which I do now, then I worry that splitting it into multiple packages will make it harder to understand and not provide much benefit. For example, I find Dragnet hard to understand because of how many packages it has. Package net/http on the other hand is quite large but I find it very easy to work with and appreciate that all of its godoc lives on a single page.

I like the suggestion of making the package work better with standard library primitives and would feel better about splitting it if that happened.

[klizhentas]

For example, in Vulcand I need packages:

package fields //package that extracts parameters from the request and does error checking
package trace // package that wraps http.Handler and emits metrics and logs
package response // wrapper that helps responding with errors and other responses
package handlers // functions to create new http handlers
package testutils // pa

and don't need:

package vulcan // wrapper that heartbeats the presence to vulcand when called
package service // wrapper that glues it all toghether.

How about this, to avoid package bloat we can just have three packages:

package service // functions for service infra, like heartbeat
package testutils // functions for tests
package handlers // responses, handler makers, tracers etc.

WYT?

[jeremyschlatter]

I like the three package suggestion.

[klizhentas]

looks like it's dead, closing for now