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

SearchUI PoC implementation #1666

Closed
Tracked by #1600
palaciosjeremias opened this issue Jul 28, 2021 · 3 comments
Closed
Tracked by #1600

SearchUI PoC implementation #1666

palaciosjeremias opened this issue Jul 28, 2021 · 3 comments
Assignees
Labels
docs Add or improve documentation

Comments

@palaciosjeremias
Copy link
Contributor

As part of the Epic 1600, we will use SearchUI as the main tool to index, filter, and display the documentation content of Wazuh QA.
The input for SearchUI will be created in the Epic 1536.
After the investigation done in 1627, we should implement a PoC capable to:

  • Ingest the DocGenerator output as an input.
  • Display the documentation blocks.
  • Filter and select the information provided.
@MiguelazoDS
Copy link
Member

MiguelazoDS commented Jul 30, 2021

Findings


As a continuation of the previous analysis #1627, in this POC we are trying the full integration between the DocGenerator scripts that creates the JSON files that feed elasticsearch with new data.
The motivation to do this is to find as fast as possible any inconvenience in the design and implementation so far that would interfere with the progress of this development.

To start with this POC a simple script that deletes an index and adds new data was created. It looks for JSON files that are the output of the DocGenerator and uses the elasticsearch client to make a request to the bulk API.

The entry point of this project that imports us the most is the App.js script that is in charge to create the states of the webpage according to the information collected from elasticsearch. We can ignore for now how and the purpose of the ServiceWorker.

Once elasticsearch is ready to receive a request and make a response, the buildRequest.js script will create a request where the main components used here are _source and aggregations. With the first one we parse the information we want to show in the body of the page, and with the second one, we obtain the facets that are located in the left side and are used to filter the information.

One thing we notice is that it seems the required field in the documents is an id, otherwise the code fails.
The result.js in the class ResultContainer, method view. It expects a result.id where id is a field in the JSON output that we get later from elasticsearch. That's why the only field required in _source is the id one.

Taking the previous comment into account, we need to include in our JSON output from the DocGenerator an id, this is already implemented since we are using an id to correlate information.

As a conclusion, we could say that as in the previous analysis, that the generated scripts won't interfere in this development, once we receive the response from elasticsearch the limitation seems to be only related to the expertise in JS development.

As stated above, it is needed to understand better how JS/React syntax is and the tools it provides.

2

One thing about this that we need to fix is that the selected boxes don't filter out the information.

The implementation is going in this branch https:/wazuh/wazuh-qa/tree/dev_1666_search-ui_poc

@MiguelazoDS
Copy link
Member

It is possible now to filter out the results by the fields we have in our left panel as is shown in the following images.

1
2
3
4

We still need to figure out how to parse the information coming from elasticsearch to show the JSON objects' content.

Related to #1641 (comment), the names used to build a filter request are the variables we use to build the facets, and those names should match to the key defined in the aggs section when we query elasticsearch.

It's needed to define the schema #1626 to have a better understanding of how the information will be shown, so that we can have a more descriptive title and also new fields to filter the information.

@MiguelazoDS
Copy link
Member

MiguelazoDS commented Aug 3, 2021

Conclusion


We conclude this POC with some ideas to do as a part of the following issue, and also doubts that were cleared while performing this development.

Related to the previous images we need to implement a complex parser, probably recursive, to obtain the information in nested JSON objects. As of now, the JSON object was converted to string just to show the information, the function buildResults is the one that converts the hits array response from elasticsearch into a format that is understandable by search-ui. As far as we see, it needs to have the field values in a JSON object with a raw key.
To fix that we should re-implement that function. Also is needed to provide better titles and format to the information displayed on the body page.

5

Before the page was not automatically loaded at the start, which was fixed in the latest changes. But currently, the search bar does not do what is supposed to do. It is not returning any result searching for words or partial words.

Also, will be desirable to implement some autosuggestion and auto-completion feature to the search bar.

About the snack case convention, we decided to use, we need to reconsider the idea to go back to the previous format and modify the JS scripts to manage the name keys instead of modifying them directly in the JSON output.

The script that indexes the data will be integrated as a module to the current development of the DocGenerator project, so it will be possible to show locally the rendered documentation.

Link to the branch: https:/wazuh/wazuh-qa/tree/dev_1666_search-ui_poc

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Add or improve documentation
Projects
None yet
Development

No branches or pull requests

2 participants