Roadmap for Arturo 3.0

[jamesarosen]

After some reflection, I'd like to make Arturo more Rack-centric and less Rails-centric, but still make it easy to integrate with Rails. To that end, I'm recommending the following basic interface for v2.0:

use Arturo::Middleware do
  feature_recipient do |env|
    env['warden'].current_user
  end

  # require feature :foo for GET /foo, POST /foo, etc.
  require_feature :foo, '/foo'

  # require feature :bar for PUT /bar
  require_feature :bar, :put, '/bar'

  # require feature :baz for requests that have the X-Baz header set to 1
  require_feature :baz do |env|
    env['HTTP_X_BAZ'] == 1
  end
end

The middleware also sets env['arturo'], which has #feature_enabled?(Symbol) -> Boolean and #enabled_features -> Lazy Set. Use it like so:

class MyMiddlware
  def initialize(app)
    @app = app
  end
  def call(env)
    if ( env['arturo'].feature_enabled?(:foo) )
      @app.call(env)
    else
      some_error
    end
  end
end

Of course, we can still build all the Rails integrations on top of this. The only potential problem I see is that it might be hard for some people to turn feature_recipient into a method that runs against a Rack env Hash.

@plukevdh do you have any thoughts on this?

[plukevdh]

I could definitely see doing this. Would be a nice to have for Sinatra/Cuba apps as well, so I'm for moving it towards rack. I need to look over these examples a bit more and review the current code to evaluate the sugested changes more, but I like the idea of rack for sure. 
—
"We'll make it happen. We're bike racers" - Glenn S.

Sent from my phone

On Thu, Mar 21, 2013 at 5:01 PM, James Rosen [email protected]
wrote:

After some reflection, I'd like to make Arturo more Rack-centric and less Rails-centric, but still make it easy to integrate with Rails. To that end, I'm recommending the following basic interface for v2.0:

use Arturo::Middleware do
  feature_recipient do |env|
    env['warden'].current_user
  end
  # require feature :foo for GET /foo, POST /foo, etc.
  require_feature :foo, '/foo'
  # require feature :bar for PUT /bar
  require_feature :bar, :put, '/bar'
  # require feature :baz for requests that have the X-Baz header set to 1
  require_feature :baz do |env|
    env['HTTP_X_BAZ'] == 1
  end
end

The middleware also sets env['arturo'], which has #feature_enabled?(Symbol) -> Boolean and #enabled_features -> Lazy Set. Use it like so:

class MyMiddlware
  def initialize(app)
    @app = app
  end
  def call(env)
    if ( env['arturo'].feature_enabled?(:foo) )
      @app.call(env)
    else
      some_error
    end
  end
end

Of course, we can still build all the Rails integrations on top of this. The only potential problem I see is that it might be hard for some people to turn feature_recipient into a method that runs against a Rack env Hash.

@plukevdh do you have any thoughts on this?

Reply to this email directly or view it on GitHub:
#39

[jamesarosen]

@plukevdh the #enabled_features -> LazySet works best when using a hot cache (see #21). My suspicion is that people who use Arturo don't have thousands of features, but I could be wrong. Of course, since it returns a LazySet, those that have a huge number of features could just avoid using that method.

[plukevdh]

Would be nice to implement in such a way that we can turn it into middleware. I just did a conversion of a Rails plugin to rack + middleware so it was on my mind and I wanted to drop here.. Works really cleanly if done right.

[plukevdh]

Here's what I did for FayeRails: Also look over faye/faye and the RackAdapter class for how it works out.

jimsynz/faye-rails#44

[jamesarosen]

We could conceivably do the feature management pages as a pure Rack endpoint, but the Rails helpers sure are nice for that. Plus, it won't visually fit in with Rails apps that it's mounted in (since there's no "layout").

All the feature querying can be done in a Rack middleware, though. That's what I had tried to express above.

[plukevdh]

Ah damn. Totally forgot about the middleware shout out in the initial suggestion. Good call. You're way ahead of me :)

[plukevdh]

I'd be interested in starting on this one. I'll see what time I can work in and start a branch/PR to get this going. Any work done on this yet that I should know about?

[jamesarosen]

Let's do the work on the v2.0 branch. A proposed path:

1. update the README to reflect the move to more Rack, including configuring the middleware
2. enhance the existing Arturo::Middleware to support the DSL, above
3. change the Rails helpers to refer to the Rack middleware

[dasch]

We would very much like it if the management interface was separated into a another gem - we have an app that only reads the Arturo bits, and we're having some problems caused by Arturo being an engine rather than a normal library.

[jamesarosen]

I just published v2.0 with some minor API changes. This roadmap will be for v3.0, which I hope to start work on soon.