Extend request handler with request scoped core capabilities#43103
Extend request handler with request scoped core capabilities#43103joshdover merged 11 commits intoelastic:masterfrom
Conversation
|
Pinging @elastic/kibana-platform |
fe1f58a to
140bed8
Compare
There was a problem hiding this comment.
tests that plugin has access to the route handler context functionality provided by the core.
There was a problem hiding this comment.
tests that plugin has access to the route handler context functionality provided the dependency
src/core/server/http/types.ts
Outdated
There was a problem hiding this comment.
we will have to change the signature if we want to use the same context declaration for route handlers and request interceptors.
request interceptors are out of the scope of the current PR.
💚 Build Succeeded |
| import { Plugin, CoreSetup } from 'kibana/server'; | ||
| import { PluginARequestContext } from '../../core_plugin_a/server'; | ||
|
|
||
| declare module 'kibana/server' { |
There was a problem hiding this comment.
note: this is necessary, as core_plugin_a is not a part of compilation setup
| createRouter: (path: string) => { | ||
| const router = new Router(path, this.log); | ||
| createRouter: (path: string, pluginId: PluginOpaqueId = this.coreContext.coreId) => { | ||
| const enhanceHandler = this.requestHandlerContext!.createHandler.bind(null, pluginId); |
There was a problem hiding this comment.
I like the enhance name, maybe we should consider renaming IContextContainer.createHandler to IContextContainer.enhanceHandler
we have to import Context type from 'server' file to be able to reference extended type. otherwise, TS considers it empty
| core.http.registerRouteHandlerContext('pluginA', context => { | ||
| return { | ||
| ping: () => | ||
| context.core!.elasticsearch.adminClient.callAsInternalUser('ping') as Promise<string>, |
There was a problem hiding this comment.
TODO later: core context is always defined in plugin setup phase
There was a problem hiding this comment.
This is because of this type? https://github.com/elastic/kibana/blob/master/src/core/utils/context.ts#L42
I was a little conflicted on how this should work since plugins can also create ContextContainers, it's not clear that core will always be present. The only idea I have is adding an additional type parameter that defines which keyof TContext are always present.
💔 Build Failed |
💔 Build Failed |
|
retest |
💔 Build Failed |
💚 Build Succeeded |
💚 Build Succeeded |
Summary
Closes #33783
Introduces
RequestHandlerContextpassed to a request handler as the very first argument.Currently extended only with
elasticsearchservice, which provides cluster clients scoped to the current request.Use
strikethroughsto remove checklist items you don't feel are applicable to this PR.[ ] This was checked for cross-browser compatibility, including a check against IE11[ ] Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support[ ] Documentation was added for features that require explanation or tutorials[ ] This was checked for keyboard-only and screenreader accessibilityFor maintainers
Dev docs
Kibana facilitates new Handler context pattern to provide core services API to plugins. The central purpose of this pattern is to hide some implementation details and provide a set of API specific for the current context. For example,
RequestHandlerContextcontains tailored elasticsearch service API, letting a plugin to perform a request to elasticsearch on behalf of the user requesting Kibana.RequestHandlerContextis exposed to the route handlers as the very first argument.