MC-29319: graphql - Limiting configurable product options

[cpartica]

Problem

Configurable products options limiting and variations filtering.

Pulling all configurable products data in one query is a valid use case, for one product, that can result in quite a big payload if we have 2 options with each some hundreds of values.
This problem becomes multiplied by the number of products we're trying to query at a time, with related products, or category page. For simplicity a 9 products at a time can result in a payload of 30mb, consisting of 1.5 million lines of data and some 40 seconds wall time.
The difference on the PDP page and multiple products rendering, is that for multiple, you don't need as much detail.

Solution

Adding of limitation the configurable_options from the ConfigurableProduct type. This can be done by adding an optional parameter to keep schema backward compatible.

... on ConfigurableProduct {
                configurable_options {
                    id
                    attribute_id
                    label
                    position
                    use_default
                    attribute_code
                    values(limit: 3) {
                        value_index # usually value of the dropdown attribute
                        label
                        store_label
                        default_label
                        use_default_value
                    }
                    total_values # new field proposed
                    product_id # parent id (configrable product id)
                }
   }

Requested Reviewers

@paliarush
@akaplya

[nrkapoor]

@cpartica let's close this PR. This issue is addressed in the new PR (#394) for option selection optimization.

[cpartica]

@cpartica let's close this PR. This issue is addressed in the new PR (#394) for option selection optimization.

Not yet, because I don't see how https://github.com/magento/architecture/blob/master/design-documents/graph-ql/coverage/catalog/configurable-options-selection.graphqls

specifically
configurable_options_selection_metadata(selectedConfigurableOptionValues: [ID!])
doesn't align to how do you filter a full set of attributes:

... on ConfigurableProduct {
                variants(value_indexes: {in: [ [278,279], [280,281], [282,283] ... ]}) {
                                         # aka  [RED, S] [GREEN, M], [BLUE, L]

to my understanding we needed something like:

Query {
 ConfigurableProductVariants(value_indexes: {in: [ [278,279], [280,281], [282,283] ... ]})
}

[cpartica]

@cpartica let's close this PR. This issue is addressed in the new PR (#394) for option selection optimization.

Looks like the only difference is that I was using full groups and the other proposal goes for partial groups

 selectedConfigurableOptionValues: ["hash from selected option value"]
 selectedConfigurableOptionValues: ["hash from selected option value", "hash from another option value"]
selectedConfigurableOptionValues: ["hash from selected option value", "hash from another option value", "hash from another option value"]

until it becomes a full group