[data.search] Expose SearchSource on the server.#78383
[data.search] Expose SearchSource on the server.#78383lukeelmers merged 6 commits intoelastic:masterfrom
Conversation
There was a problem hiding this comment.
@lukasolson Let me know if I got this abort logic right. I tested and AFAICT it all works as expected.
There was a problem hiding this comment.
This got simplified to a helper which could also be called outside of a route handler
There was a problem hiding this comment.
@lukasolson @lizozom @ppisljar We should discuss the fakeRequestHandlerContext here -- I added it to our list to cover offline.
There was a problem hiding this comment.
i am fine moving forward with this but lets open an issue for refactoring we want to do
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Here's the issue for discussing changes to the low-level search API: #78461
There was a problem hiding this comment.
loadingCount$ isn't really necessary on the server, so we just initialize BehaviorSubject that never changes
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
relocated to top-level before that loads before both index patterns and search
|
Pinging @elastic/kibana-app-arch (Team:AppArch) |
5203671 to
f48dda8
Compare
|
@elasticmachine merge upstream |
1 similar comment
|
@elasticmachine merge upstream |
|
merge conflict between base and head |
5fca711 to
b75a84b
Compare
b75a84b to
5aebda3
Compare
💚 Build SucceededMetrics [docs]@kbn/optimizer bundle module count
distributable file count
page load bundle size
History
To update your PR or re-run it, just comment with: |
# Conflicts: # src/plugins/data/server/server.api.md
|
|
||
| export interface SearchSourceDependencies extends FetchHandlers { | ||
| search: ISearchGeneric; | ||
| search: (request: IEsSearchRequest, options: ISearchOptions) => Promise<IEsSearchResponse>; |
There was a problem hiding this comment.
@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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
(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)
There was a problem hiding this comment.
PR adding the generic type params: #79608
Closes #65069
Summary
This is the final PR which exposes
SearchSourceon the server:await data.search.searchSource.asScoped(kibanaRequest);, which returns the same API as is available on the client.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
SearchSourceis now available on the server. Usage: