[Story] Support for Configurable Product variants in Storefront App

[magento-engcom-team]

Acceptance Criteria

• New schema should be sufficient to complete "Add Product To Cart" request
• configurable variants must be exposed to SF API

What To Demo

• New product variants successfully passed to SF and can be fetched via gRPC call

Scenarios

• merchant creates configurable product
• product variations propagated to storefront
• variations can be fetched from SF application using new API

Notes

• design document https://github.com/magento/architecture/blob/4f28fde7aa0e24b6e0b834cd35591637b40f60b6/design-documents/storefront/catalog/product-options-and-variants.md#storefront-api
• details of implementation: https://github.com/magento/catalog-storefront/blob/develop/dev/docs/designDocuments/Configurable-products-option-variants.md
• more details can be found in subtasks
• All changes should be covered by integration tests and REST API tests if required.

Subtasks:

1. [326.1] Variants update in proto scheme #327 Variants update in proto scheme
2. [357.2] Configurable variants saving to cache  #330 Configurable variants saving to cache
3. [357.3] Import data to SF Application  #331 Sync exported data with SF Application
4. [357.4] GetProductVariants service #332 GetProductVariants service
5. [357.6] DeleteProductVariants service #335 DeleteProductVariants service

[magento-engcom-team]

The issue was exported from the internal JIRA. The link to the original JIRA issue: https://jira.corp.magento.com/browse/SFAPP-50

[m2-assistant]

Hi @magento-engcom-team. Thank you for your report.
To help us process this issue please make sure that you provided sufficient information.

Please, add a comment to assign the issue: @magento I am working on this

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

[bricht]

Current process:
Currently the product variant indexer recieves parent product id as input.
The indexer retrieves the variants of that product, currently saved in the feed table. (list1)
The indexer retrieved the new variants of that product from the providers. These providers generate a full list of variants currently available for this product. (list2)

The indexer compares these two lists. Variants which are in list1, but not in list2 are outdated, and are to be deleted from the catalog storefront. (outdated variants)

The indexer marks outdated variants in feed table.

The indexer sends out:

1. List of outdated variant ids to be deleted from catalog storefront storage.
2. List of variant ids to be imported in catalog storefront storage.

Issues with current approach:

1. We need to manually compare the two arrays in order to determine the deleted variant ids.
2. We reindex all the product variants every time a new variant is created / deleted.
3. The indexer is currently launched mostly by plugins which is not particularly efficient. Mview doesnt work on catalog_product_relation, because https://stackoverflow.com/questions/26328570/on-delete-cascade-not-firing-trigger.

Some ideas for improvement:

1. Ideally the indexer should be triggered by more granular info on what was changed/deleted/added, not just parent id.

2. Might try to make the indexer more flexible and also work with child product ids. Or other information (for customized options). Also obviously need to modify the plugins then and integration with mview.

3. Add a better mechanism for marking deleted variants. Perhaps a query which marks deleted variants at the beginning of the process. Then markedDeleted variants are sent out to catalog storefront. After that, the markDeleted variants are deleted from the feedTable.