gocardless / coach Goto Github PK

Dependabot can't resolve your Ruby dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

Bundler::GemNotFound with message: Could not find gem 'rspec-its (~> 1.2)' in any of the gem sources listed in your Gemfile.

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

You can mention @dependabot in the comments below to contact the Dependabot team.

Instead of coach.middleware.finish it should be finish.middleware.coach as in Rails itself, e.g render_template.action_view.

Dependabot can't resolve your Ruby dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

Bundler::GemNotFound with message: Could not find gem 'rspec-its (<= 1.2.0, >= 1.2)' in any of the gem sources listed in your Gemfile.

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

You can mention @dependabot in the comments below to contact the Dependabot team.

Problem

Let's say I have a large application, with many middleware. Some middleware are simply composition units of others, for example:

class Middleware::Authenticate
  uses Middleware::ExtractBearerToken
  uses Middleware::LookupBearerToken
  uses Middleware::LogBearerToken

  requires :bearer_token
  provides :user

  def call
    provide(user: bearer_token.user)
    next_middleware.call
  end
end

I think this is a use-case which isn't currently tested well:

• We have boot-time checking of the dependency tree (so we check that ExtractBearerToken provides :bearer_token)
• We have unit tests of each sub-middleware behaving in the correct way in isolation.
• We have request specs testing the overall route (including interactions of all the other middleware).

But there doesn't seem to be a simple way of saying, in a test, "run this smaller middleware chain" (i.e. invoke each sub-middleware and then run Middleware::Authenticate#call). The behaviours of this unit might vary depending on inputs/outputs of each sub-middleware in a way which isn't best expressed in isolated unit tests nor in the high-level request specs (which can be slow).

I think that endorsing this kind of testing to uncover interaction edge-cases would be incredibly valuable.

Proposal

Add a high-level API, either to coach/rspec or in the README, for running a full middleware chain like this.

The usage would look something like:

describe Middleware::Authenticate do
  subject(:instance) { Coach::Chain.new(described_class) } # this is the interesting bit
  
  it { is_expected.to call_next_middleware }
  it { is_expected.to provide(user: ...) }

  context "when a bearer token isn't in the request" do
    it "bails out before calling the main function"
  end
end

Dependabot can't resolve your Ruby dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

Bundler::GemNotFound with message: Could not find gem 'rspec-its (<= 1.2.0, >= 1.2)' in any of the gem sources listed in your Gemfile.

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

You can mention @dependabot in the comments below to contact the Dependabot team.

The code example of testing with coach+rspec starts with require 'spec_helper'. To help folks who are starting a new project to try out Coach, we should specify what needs to be defined spec_helper.

Dependabot can't resolve your Ruby dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

Bundler::GemNotFound with message: Could not find gem 'rspec-its (~> 1.2)' in any of the gem sources listed in your Gemfile.

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

You can mention @dependabot in the comments below to contact the Dependabot team.

Apparently routes registered with coach do not show as true by the Rails.application.routes.recognize_path method.
As a side effect, some gems that might use this method will not work for those endpoints.
e.g. https://github.com/openzipkin/zipkin-ruby -> https://github.com/openzipkin/zipkin-ruby/blob/master/lib/zipkin-tracer/rack/zipkin-tracer.rb#L43.

I've being trying different instrumentation tools and they all failed to report, this one (zipkin) was the first I dug in why, but I suspect this might be affecting others too.

I have an old endpoint I want to quietly combine with a new one. Here's what I tried to do:

Old router:

router.draw(
    Routes::Badges,
    base: "/badges",
    actions: [
      ci_status: { method: :get, url: "/ci_status" },
      compatibility_score: { method: :get, url: "/compatibility_score" },
    ],
  )

Attempted new router:

router.draw(
    Routes::Badges,
    base: "/badges",
    actions: [
      compatibility_score: [
        { method: :get, url: "/compatibility_score" },
        { method: :get, url: "/ci_status" },
      ],
    ],
  )

It would be rad if that worked. Any reason not to support it / preferred alternative?

So, this might be a slightly unusual use case here...

One flow that I'm investigating using this for fetches data from multiple backends before acting on some combination of that information. We currently do this asynchronously using concurrent ruby, which works nicely to avoid the latency of serial network requests.

Rather than writing a know-it-all middleware, I'd far rather have a composable flow, which would allow single-purpose middlewares to be called in parallel, each providing their own data to the downstream handler. Would you consider a PR that introduced some kind of uses_parallel or less monstrously named concept?

There would obviously be some issues around the concept of next_middleware in this case, and I could solve this without the extra class method by using a configurable AsyncInjectionMiddleware or the like, but thought I'd sound you out.

Should probably have a non-zero minor version before we blog!

There are a few soon-to-be deprecated features that we should drop in a 3.0 release:

• The duration field in our statistics logging (#52)
• The session_id field in our request.coach event (#59)

This issue tracks those, and any others that we accumulate.