ruby-grape / grape / 33755485219

97%

push

github

Resolve an API instance's cascade setting once instead of per request (#2888)

`Grape::API::Instance#call` asks whether the API cascades on the way out of
every request:

    def call(env)
      status, headers, response = @router.call(env)
      unless cascade?
        ...

and `cascade?` answers it by walking the settings:

    def cascade?
      setting = self.class.inheritable_setting
      return setting.cascade if setting.cascade_defined?
      return setting.version_options.cascade if setting.version_options

      true
    end

`cascade_defined?` and `version_options` each resolve through
`InheritableSetting`, which walks the scope chain until a scope has the key —
so a request pays for two full walks of it, and the deeper the API nests the
more they cost.

The answer cannot change while the instance is alive. It is read off the same
`inheritable_setting` the routes were built from, and `#initialize` has already
compiled and frozen the router against it; a settings change has to go through
`change!`, which drops the instance so the next request compiles a new one.
So resolve it in the constructor, next to the router it is consistent with.

On an API with a prefix, path versioning and three nested namespaces:

    resolve per request  323.5 ns  ->  memoized reader  41.0 ns   7.90x

End to end, a minimal versioned GET (`Benchmark.ips`, median of 5 interleaved
runs against master, Ruby 4.0.5): **+4.0%** bare, **+8.4%** with params and
validations.

`cascade?` keeps its name and its meaning — it is public and grape-swagger
reads it — it just reports what was resolved rather than resolving again.

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

1238 of 1332 branches covered (92.94%)

Branch coverage included in aggregate %.

7 of 8 new or added lines in 1 file covered. (87.5%)

3939 of 4008 relevant lines covered (98.28%)

27052.37 hits per line