[New platform] Extend request handler with request scoped core capabilities

[mshustov]

Description

Updated:
New implementation should be based on RFC #36509

Outdated

Reactive nature of core services implies that core capabilities can be updated during the lifecycle. ```js setup(core){ const client = core.elasticsearch.adminClient$.pipe(first()).toPromise(); ... handler(request){ // - client can be outdated // - we have to bind a scope manually // - we provide full access to raw request const result = await client.asScoped(request, '...') }) ``` To prevent core capabilities from stalling we can provide an alternative mechanism that - always exposes the fresh version of core capabilities - binds them to the current request automatically

setup(core){ 
  ...
  // NOTE: passing core with scoped functionality as an additional argument is not final proposal
  handler(request, …, core){
     const scopedClient = core.elasticsearch.scopedAdminClient;
     const result = await scopedClient('...')

Besides of scoped core services we may want to provide request scoped plugin capabilities.

setup(core, plugins){ 
  plugins.XXX.registerScopedCall({
    handler(..., core){
      const scopedClient = core.elasticsearch.scopedAdminClient;
    }
  });
  ...  
  // NOTE: passing core & plugins with scoped functionality as an additional arguments is not final proposal
  handler(request, …, core, plugins){
     await plugins.scopedCall(...

Implementation

TBD

Related discussions

The previous discussion about request-scoped services with examples is in the umbrella issue #12464

[elasticmachine]

Pinging @elastic/kibana-platform

[epixa]

To clarify, in your handler example, wouldn't it just be core.elasticsearch.scopedAdminClient rather than an observable? Basically, it would be based on the result of core.elasticsearch.adminClient$.pipe(first()).toPromise() at request-time.

[mshustov]

@epixa right, fixed