Introduce 2-way mapping on GQL resolver

[mslabko]

As a developer, I want to have only one mapping, that can be used for

• transform GQL query to Storefront APP request
• transform Storefront App response to GQL response

Due to we going to have support for webonyx GQL client (PHP) and NodeJS GQL client (javascript) we can build this mapping in json format to reuse between systems

{
        "DownloadableProduct.downloadable_product_samples": {
            "sample_url": "samples.resource.url",
            "sort_order": "samples.sort_order"
        },
        "CustomizableRadioValue": {
            "uid": "options_v2.values.id" // or better use type like "ProductOption.ProductOptionValue.id"
            "price" : "ProductVariant.price" // how to refer to another entity? (varinats instead products)

        }
}

Example

{
    products(filter: {price: {from: "2"}}) {
        items {
        sku
        name
          ... on DownloadableProduct {
            downloadable_product_samples {
              sample_url
            }
          }
  }
}

in this example (taking into account mapping above) we can:

• transofrm request "DownloadableProduct.downloadable_product_samples.sample_url" to "samples.resource.url"
• transform response "samples.resource.url" to GQL schema "DownloadableProduct.downloadable_product_samples.sample_url"

Open questions:

• how to tell that we work with another entity: variant instead product, see examples with CustomizableRadioValue.price" (Leaky abstraction?)

[m2-assistant[bot]]

Hi @mslabko. 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.

[DrewML]

As a developer, I want to have only one mapping, that can be used for

transform GQL query to Storefront APP request transform Storefront App response to GQL response

I think this user-story needs an explanation for the why, rather than just the what. My understanding was that it was not an explicit goal of this project for the shape of the data in proto messages to match the shape of the GraphQL data. I think that would need to be a prerequisite for this project if we want to go down that path, so shapes don't diverge.

For the time being, there haven't been any plans for automatic mapping between proto/gRPC and GraphQL schemas. I'd love to avoid creating this kind of mapping abstraction early on until it's needed.

Ideally, we'll do the most basic integration strategy possible from the node.js server, and we can look at a configurable mapping layer when/if we find the simpler strategy unwieldy.

If we try to invent something this early on we'll likely end up with an ill fitting abstraction (GraphQL stuff can get complicated on its own pretty fast).

[mslabko]

we still need a mapping between GQL and Storefront APP ("proto") due to we not going to introduce new GQL schema

And my idea was to create pretty simple abstraction that will allow "just write mapping". In other case we will have N different solutions (answer for why) for mapping from GQL to Storefront and vise-versa

[DrewML]

we still need a mapping between GQL and Storefront APP ("proto") due to we not going to introduce new GQL schema

Can you clarify what you mean here? That's what resolvers are for in GraphQL. Field gets invoked, then you fetch the data you need to satisy the schema.