feature/ using searchQuery object as a search layer + GraphQl support

[yuriboyko]

Related issues

no related issues

Related pull requests

vuestorefront/vue-storefront-api#94

Short description and why it's useful

This update applies 2 big features:

1. New search library which uses searchQuery object as a search layer with ability to apply filters and search text instead of creating Elasticsearch request from the beginning. This will allow VSF be more flexible in terms of using different search engines

2. New search adapter uses graphQl as an API

Screenshots of visual changes before/after (if there are any)

Visually no changes

Screenshot of passed e2e tests (if you are using our standard setup as a backend)

Contribution and curently important rules acceptance

• [ X] I read and followed contribution rules
• [ X] I read the TypeScript Action Plan and adjusted my PR according to it
• [ X] I read about Vue Storefront Modules and refactoring plan for them

[pkarw]

@yuriboyko Please do resolve conflicts + let me know when it’s ready to be merged in. I’ll merge it in next week into develop

[pkarw]

@yuriboyko - is it ready togo?

[yuriboyko]

I think yes

[pkarw]

Shouldn't it be final_price either - line 44 replacement removed - to just operate on the same field?

[pkarw]

I believe we should have a more general way to create full-text queries. I mean it would be great if the SearchQuery class can support constructing the text queries like this one to not have this logic centralized as it currently is

[pkarw]

This is important

We must add the way to extend this logick - I belive there should be a way to extend the graphQL queries support for new entities without modifying the core

Would be great if from the Extension or Theme level developer could do sth like:

const factory = new SearchAdapterFactory()
factory.registerEntityType('graphql', 'category', { 
 gql: require('./queries/categories.gql'),
 queryProcessor: (query) => {
  // function that can modify the query each time before it's being executed
  return query
 }
 resultPorcessor: (resp, start, size) =>  {
  const response = {
    items: map(resp.hits.hits, hit => {
      return Object.assign(hit._source, {
        _score: hit._score,
        slug: (hit._source.hasOwnProperty('url_key') && rootStore.state.config.products.useMagentoUrlKeys)
          ? hit._source.url_key
          : (hit._source.hasOwnProperty('name') ? slugify(hit._source.name) + '-' + hit._source.id : '')
      }) // TODO: assign slugs server side
    }), // TODO: add scoring information
    total: resp.hits.total,
    start: start,
    perPage: size,
    aggregations: resp.aggregations
  }

})

for the api adapter it could be sth like this:

const factory = new SearchAdapterFactory()
factory.registerEntityType('api', 'category', { 
 queryProcessor: (query) => {
  // function that can modify the query each time before it's being executed
  return query
 }
 resultPorcessor: (resp, start, size) =>  {
  const response = {
    items: map(resp.hits.hits, hit => {
      return Object.assign(hit._source, {
        _score: hit._score,
        slug: (hit._source.hasOwnProperty('url_key') && rootStore.state.config.products.useMagentoUrlKeys)
          ? hit._source.url_key
          : (hit._source.hasOwnProperty('name') ? slugify(hit._source.name) + '-' + hit._source.id : '')
      }) // TODO: assign slugs server side
    }), // TODO: add scoring information
    total: resp.hits.total,
    start: start,
    perPage: size,
    aggregations: resp.aggregations
  }

})

So we should have store the processor, queryProcessor and gql somewhere per entity type * driver. I think that good place is a kind of Vue.prototype.$searchContext OR rootStore.state - up to You

[pkarw]

This is important

We must ensure that graphQL driver is taking care of _sourceInclude and _sourceExclude as they are key to optimize the bandwidth of data requests:

we’re running two queries in that case - here You have the result on Elastic (demo): (https://www.dropbox.com/s/acu4l0f868ovndf/Screenshot%202018-09-11%2017.31.23.png?dl=0)

and in graphql - the result is exactly the same in size because _excludeFields parameter is not being used (https://www.dropbox.com/s/znwfqrbvfn8llas/Screenshot%202018-09-11%2017.30.41.png?dl=0

In first case you see the difference: 123 vs 320kb - in second case the excludeFields are ignored