Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[data.search] Expose SearchSource on the server. #78383

Merged
merged 6 commits into from
Sep 29, 2020

Conversation

lukeelmers
Copy link
Member

@lukeelmers lukeelmers commented Sep 24, 2020

Closes #65069

Summary

This is the final PR which exposes SearchSource on the server:

  • Refactors msearch route that's used in the legacy "default" search strategy so that the business logic is extracted into a helper function which can be reused in SearchSource
  • Adds contract to search service on the server
    • API is await data.search.searchSource.asScoped(kibanaRequest);, which returns the same API as is available on the client.
  • Adds a plugin functional test suite to verify the service on the server

Testing

This PR relies on the added functional tests to validate that everything works, as there is not currently anywhere in Kibana which uses this service on the server.

Dev Docs

The high-level search API SearchSource is now available on the server. Usage:

function async myRouteHandler(context, request, response) {
  const searchSource = await data.search.searchSource.asScoped(request);
  searchSource.createEmpty(); // API after calling `asScoped` matches the client-side service
}

@lukeelmers lukeelmers self-assigned this Sep 24, 2020
@lukeelmers lukeelmers added Feature:Search Querying infrastructure in Kibana release_note:plugin_api_changes Contains a Plugin API changes section for the breaking plugin API changes section. release_note:enhancement v7.10.0 v8.0.0 review labels Sep 24, 2020
Comment on lines +86 to +88
if (params.signal) {
params.signal.addEventListener('abort', () => promise.abort());
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lukasolson Let me know if I got this abort logic right. I tested and AFAICT it all works as expected.

Comment on lines +62 to +66
const callMsearch = getCallMsearch({
esClient: context.core.elasticsearch.client,
globalConfig$: deps.globalConfig$,
uiSettings: context.core.uiSettings.client,
});
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This got simplified to a helper which could also be called outside of a route handler

Comment on lines +171 to +197
/**
* Unless we want all SearchSource users to provide both a KibanaRequest
* (needed for index patterns) AND the RequestHandlerContext (needed for
* low-level search), we need to fake the context as it can be derived
* from the request object anyway. This will pose problems for folks who
* are registering custom search strategies as they are only getting a
* subset of the entire context. Ideally low-level search should be
* refactored to only require the needed dependencies: esClient & uiSettings.
*/
const fakeRequestHandlerContext = {
core: {
elasticsearch: {
client: esClient,
},
uiSettings: {
client: uiSettingsClient,
},
},
} as RequestHandlerContext;
return this.search(fakeRequestHandlerContext, searchRequest, options);
},
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lukasolson @lizozom @ppisljar We should discuss the fakeRequestHandlerContext here -- I added it to our list to cover offline.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i am fine moving forward with this but lets open an issue for refactoring we want to do

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Takeaway from our offline discussion: we will keep as-is for now as @ppisljar suggests, and discuss the proposed low-level search service changes separately.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's the issue for discussing changes to the low-level search API: #78461

globalConfig$: this.initializerContext.config.legacy.globalConfig$,
uiSettings: uiSettingsClient,
}),
loadingCount$: new BehaviorSubject(0),
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

loadingCount$ isn't really necessary on the server, so we just initialize BehaviorSubject that never changes

@@ -140,6 +152,58 @@ export class SearchService implements Plugin<ISearchSetup, ISearchStart> {
) => {
return this.search(context, searchRequest, options);
},
searchSource: {
asScoped: async (request: KibanaRequest) => {
Copy link
Member Author

@lukeelmers lukeelmers Sep 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Accepting a KibanaRequest was pretty much my only option for the API since it's what index patterns require on the server. The question (as outlined in the code comment below) is whether it's necessary to also require RequestHandlerContext for the low-level search, when all of those items can already be derived from a KibanaRequest

const router = core.http.createRouter();

router.get(
{ path: '/api/data_search_plugin/search_source/as_scoped', validate: false },
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These tests create a few dummy routes that can be called from the client to execute various pieces of the searchSource service on the server.

Comment on lines -30 to -36
before(async () => {
await esArchiver.loadIfNeeded(
'../functional/fixtures/es_archiver/getting_started/shakespeare'
);
await PageObjects.common.navigateToApp('settings');
await PageObjects.settings.createIndexPattern('shakespeare', '');
});
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

relocated to top-level before that loads before both index patterns and search

@lukeelmers lukeelmers marked this pull request as ready for review September 24, 2020 04:43
@lukeelmers lukeelmers requested a review from a team as a code owner September 24, 2020 04:43
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-app-arch (Team:AppArch)

Copy link
Member

@ppisljar ppisljar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

code LGTM

@lukeelmers
Copy link
Member Author

@elasticmachine merge upstream

1 similar comment
@lukeelmers
Copy link
Member Author

@elasticmachine merge upstream

@elasticmachine
Copy link
Contributor

merge conflict between base and head

@lukeelmers lukeelmers force-pushed the feat/ssource-server branch 2 times, most recently from 5fca711 to b75a84b Compare September 29, 2020 16:23
@kibanamachine
Copy link
Contributor

💚 Build Succeeded

Metrics [docs]

@kbn/optimizer bundle module count

id value diff baseline
data 569 +1 568

distributable file count

id value diff baseline
default 45826 +2 45824
oss 26576 +2 26574

page load bundle size

id value diff baseline
data 1.3MB +949.0B 1.3MB

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@lukeelmers lukeelmers merged commit ccb789d into elastic:master Sep 29, 2020
@lukeelmers lukeelmers deleted the feat/ssource-server branch September 29, 2020 18:38
lukeelmers added a commit to lukeelmers/kibana that referenced this pull request Sep 29, 2020
# Conflicts:
#	src/plugins/data/server/server.api.md
lukeelmers added a commit that referenced this pull request Sep 30, 2020
# Conflicts:
#	src/plugins/data/server/server.api.md
@@ -108,7 +101,7 @@ export const searchSourceRequiredUiSettings = [
];

export interface SearchSourceDependencies extends FetchHandlers {
search: ISearchGeneric;
search: (request: IEsSearchRequest, options: ISearchOptions) => Promise<IEsSearchResponse>;
Copy link
Contributor

@lizozom lizozom Sep 30, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lukeelmers why did you do this change here?
ISearchGeneric is the exact equivalent of this more explicit typescript.

Was the intention here to limit the usage of SearchSource to DSL only?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not quite the exact equivalent -- ISearchGeneric returns an observable, however on the server, the low-level search returns a promise.

In order to ensure the same behavior of SearchSource on both client & server, I had to wrap the dependency into something that always returns a promise.

That said, I did not include the ability to provide generic type params like ISearchGeneric does, and probably should have. I will open a PR to update this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Also per our offline discussion, if low-level search on the server eventually moves to returning an observable as it does on the client, we can come back and adjust this)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR adding the generic type params: #79608

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Search Querying infrastructure in Kibana release_note:enhancement release_note:plugin_api_changes Contains a Plugin API changes section for the breaking plugin API changes section. review v7.10.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[data.search.searchSource]: Expose SearchSource on server
5 participants