ECP-765: GraphQL Schema for Configurable Options Selection

[paliarush]

Edit by @DrewML: Added description from JIRA ticket for reviewers

Design GraphQL schema to address issue related to thousands of configurable option permutations.

It should allow to avoid fetching all variants on configurable product page and instead allow incremental retrieval of options available for selection. It should also be possible to add product to cart when all options are selected (simple product representing variant should be identifiable).

[kokoc]

Agree with the necessity to have a separate query/node responsible for progressive options load.

There were parallel discussions about product structure on the storefront. Here are some outcomes:

• We want to unify different type of options in "add to cart" scenario. This includes selected configurable product, selected downloadable link, selected custom options, etc. This mutation accepts selected options
• We thought about the unification of options on PDP page as well, so custom options, downloadable options could be a part of the same container as configurable options.
• We agreed on the following wording
  • Option - a choice customer may make on UI. E.g. any dropdowns, checkboxes, etc. This includes configurable options, downloadable options, custom options, etc.
  • Variation - more physical thing which is defined by set of selected options. Includes price, sku, qty, etc.

We also thought about two queries:

• Accepts current selection of options and returns other available options as a result. Empty selection is passed on the first request.
• When all required options are selected or the first query returns an empty result, the second query should be executed. This query accepts full selection only and provide variation(sku, prices, etc) as a result.

Overall our idea is to apply the proposal you have on more product types and make it a first-level citizen instead of product types.

@akaplya @melnikovi

[DrewML]

When all required options are selected or the first query returns an empty result, the second query should be executed

@kokoc This is more of a REST-style way of doing things. It's typically a smell with a GraphQL API anytime you need to run up to the server to check if something has a value before you run a separate query. Should be achievable in a single round-trip

[nrkapoor]

Agree with the necessity to have a separate query/node responsible for progressive options load.

There were parallel discussions about product structure on the storefront. Here are some outcomes:

• We want to unify different type of options in "add to cart" scenario. This includes selected configurable product, selected downloadable link, selected custom options, etc. This mutation accepts selected options
• We thought about the unification of options on PDP page as well, so custom options, downloadable options could be a part of the same container as configurable options.

• We agreed on the following wording

  • Option - a choice customer may make on UI. E.g. any dropdowns, checkboxes, etc. This includes configurable options, downloadable options, custom options, etc.
  • Variation - more physical thing which is defined by set of selected options. Includes price, sku, qty, etc.

We also thought about two queries:

• Accepts current selection of options and returns other available options as a result. Empty selection is passed on the first request.
• When all required options are selected or the first query returns an empty result, the second query should be executed. This query accepts full selection only and provide variation(sku, prices, etc) as a result.

Overall our idea is to apply the proposal you have on more product types and make it a first-level citizen instead of product types.

@akaplya @melnikovi

@akaplya @paliarush @DrewML is this something we have already done with Add to Cart single mutation design?

[kokoc]

When all required options are selected or the first query returns an empty result, the second query should be executed

@kokoc This is more of a REST-style way of doing things. It's typically a smell with a GraphQL API anytime you need to run up to the server to check if something has a value before you run a separate query. Should be achievable in a single round-trip

You are right, something like union type could be used in one query instead of multiple queries