Split router out of core into it's own gem

[dj2]

Remove the router and make it plug-able. Move current router implementation to a goliath-http_router gem, or something similar.

[igrigorik]

This is nice in theory, but I'm not sure its practical in well, practice.. To support all of the use cases to make a fully functional router, you need access to the guts of Goliath. The current gotchas we're running into have nothing to do with http-router specifically.

[schmurfy]

The nice thing is that it may open the way for other interesting "plugins", the bad thing is that it would requires the core to provide some sort of api for them to use.

I know the router code mainly from my patches so I have not a clear idea yet how much support the core would need to provide and if this is feasible but I want to give it a try to see if I can come up with something that makes sense.

PS: I also think some the patches made to make router related stuff work with the core will still be needed in the core even if the router part can be itself extracted to an external gem.

[schmurfy]

I managed to extract the router part without too much troubles (I thought it would be way more difficult), but there are some problems:

• A lot of examples depends on the router features, for now what I did was to move them to the goliath_router gem
• What happens with websocket ? Can they work without the router part ?

I needed a way to change the Router.build method, what I did was to add yet another class attribute to tell what is your builder class but I really hate this implementation.

We could have a nicer implementation if Instead of this (current code):

class Builder
  def self.build(klass, api)
    # [....]
  end
end

class Application
  def run!
    # [...]
    runner.app = Goliath::Builder.build(klass, api)
    # [...]
  end
end

We had this (just moved the build method on the API class and renamed it):

class API
  def self.build_router(klass, api)

  end
end

class Application
  def run!
    # [...]
    runner.app = api.build_router(klass, api)
    # [...]
  end
end

The goliath_router gem can be implemented by using a subclass of Goliath::API and a new router which for now is called RouterBuilder, With the change above only the subclass of API would be needed.

Here what a router application currently looks like:

require 'goliath'
require 'goliath_router'

Goliath::Application.builder_class = RouterBuilder

class APIOne < Goliath::API
  def response(env)
    [200, {}, "first"]
  end
end

class APITwo < Base
  def response(env)
    [200, {}, "second"]
  end
end

class Router < RouterAPI
  map '/first', APIOne
  map '/two', APITwo
end

The goliath_gem is currently only files on my hardrive until we decide what to do with it and you can check my changes in the goliath gem here: https://github.com/schmurfy/goliath/tree/router_less

I have all the tests passing on my goliath branch except the echo_test I am not sure why but it hangs and require a Ctrl+C to finish, pretty weird, I also removed some tests which were router related.

Now it is up to you what's next :)
If you want to take a look at the gem I can publish it on github.

[igrigorik]

@schmurfy yes, please push your router up to github.. It helps to see the all the code.

First, as a preamble to this: the motivation behind "splitting the router" should not be simply to extract code into a another gem dependency. If that's all we accomplish then I'm not sure its worth the effort. Here's what we actually need to solve for.. Current router introduced a whole number of interesting complications and regressions (nobody's fault, only way to discover it was to actually use it and discover these things):

1. Routing and streaming (request, response) turned out to be broken (although I think its mostly fixed now)
2. Multi-part posts are broken with the router still
3. Router introduces "hierarchy" into processing: router middleware needs to process dispatch response (complicated..)
4. We lost the "mount a proc" semantics we had originally
5. We are rebuilding the app on every execution! Perf regression.

Some of the above are fixable, others need to be investigated, and others introduce some major API complications. I'm still trying to wrap my head around it all, but part of me wants to say: take it out and simplify. The routing is a very nice feature, but if it has to come at a cost of all the complexity above, then I'm not sure its worth it. After all, you could build a "poor man's" router directly in your response method with a switch statement. And if one of the core tenets of Goliath is down to the metal and performance.. then that seems like a reasonable tradeoff.

[igrigorik]

FWIW, he're a sampling of bugs (not a complete list) we've had to resolve associated with the router (some of which are still open):

open: #124, #127 / #128, #137
closed: #109, #108, #80, #54, #36, #33

[schmurfy]

Yes I know extracting the router code to an external is just the first step, what I currently did is nothing heroic I mostly just moved code around but it gives a base to work on wherever we go from here :)
I pushed the gem code here: https://github.com/schmurfy/goliath_router

I would be really sad to see the router features go away completely, as I mentioned I am currently using it to implement some REST services (they work really well !) and I don't really see an easy way to do that without the router (each operation currently has its own set of validations cleanly defined in the specific class).
I first started to implement the first service using one middleware with a case to select the wanted operation but when I started adding selective validations in this it became really messy and unpleasant to work with.

I am curious as to how the router broke multi part post, what happened ?

[igrigorik]

Right, the router does give you some nice behaviors.. If we can simplify the use cases and make it work - great. If not, then I think we should keep the "nuclear" option on the table.

Re, multi-part post: haven't investigated it yet, but it came up on the mailing list last week.

[igrigorik]

Closing, cutting router from 1.0.