FR: get rid of Product Union in assortment tree

[macrozone]

Introduction

Product is a union of SimpleProduct, ConfigurableProduct, BundleProduct and PlanProduct.

This leads to one of the most annoying and irritating aspects to work with the unchained graphql api.

Is your feature request related to a problem? Please describe.

Your app probably just needs some of these types. You will always need the SimpleProduct, because that is what ends in your cart and in orders. Its the thing with a sku. But you will always have to deal with all of these union types:

• you need to use ...on SimpleProduct and such even if you know that you only have one type
• type generators will also generate unions, so you have to add additional type-guards to be safe.

Let's ignore BundleProduct and PlanProduct for the moment and take a look at ConfigurableProduct:

a ConfigurableProduct is there to show you options that lead to variants (SimpleProduct), so there is a strict hierarchy:
a ConfigurableProduct contains 1 or multiple SimpleProduct.

That shows us that they should not be on the same level at all.

Describe the solution you'd like

in the assortment tree (or on search) you should always get ConfigurableProduct (or lets call it ProductWithVariants). Each ProductWithVariants has 1 or multiple SimpleProduct.

In the edge case where you don't really need to have ConfigurableProduct, this would still work fine. If you need the sku, you just fetch this one variant as well.

in the probably usual case where your assortment tree has products with multiple variants, this is of course straight forward and probably as you would expect.

In fact if you look at an other graphql-headless shop, https://www.vendure.io/, you see that they do it exactly like that.

Describe the design of the solution in detail

This is a breaking change of course. Maybe its wise to create completly new assortment-types as well that have resolvers that only return ConfigurableProducts (or better a new type of product).

I think the underlying database model can stay the same. At least in a first iteration.

I think BundleProduct can be deprecated and can be emulated in user space. Or maybe there is a way to do that with configurable products as well. Maybe a configurable product can lead to multiple SimpleProducts.

No idea about PlanProduct though, i guess that is probably a variant of a SimpleProduct.

Describe alternatives you've considered

You could override all resolvers to always return the types that you need, but that's more a hack.

Additional context

Its probably also a good opertunity to rethink variants and options as well as these types also lead to certain confusions.

[pozylon]

Yeah I was thinking a lot about this and we should explore how this could look like schema-wise. A lot of the e-commerce projects from Magento, Craft Commerce, Vendure etc. make strict assumptions on how articles and variants work but then they kind of get limited because product composability only works to a certain degree.

Right now Unchained theoretically supports cases like these:

1. Request Quote for "Bid Super Gamer Limited Set" with Code "BLACK_ACCESS_CODE"
   will return a Quotation that is orderable with color=black configuration, user-specific price and a lease time of 5 minutes

2. Add Quotation to Cart
   resolves to: Super Gamer Limited Set ConfigurableProduct color=black

Super Gamer Limited Set ConfigurableProduct color=black:

• SuperGamer Limited Set Black BundleProduct
• • 12 x Playstation Subscription Monthly PlanProduct,
• • 1 x Black Free Goodie SimpleProduct
• SuperGamer Limited Set White BundleProduct
• • 12 x Playstation Subscription Monthly PlanProduct,
• • 1 x White Free Goodie SimpleProduct

So as you can see if done right this is pretty cool and unique in Unchained.

you need to use ...on SimpleProduct and such even if you know that you only have one type
type generators will also generate unions, so you have to add additional type-guards to be safe.

The graphql query style using ... on is crap, I'd love to have some casting features built into graphql query syntax.
It's the problem of the type generator that it creates unions in these cases, protocols/interfaces are much better suited, the generator should create an abstract type "Product" and not only a union of concrete types.

Both of these issues are currently discussed here in a spec draft: graphql/graphql-spec#733

[pozylon]

graphql/graphql-spec#825

graphql is still actively working on ideas to make this all much simpler, they have a close to merge solution with the oneOf feature for input object but before they have a better solution for output objects I guess this will take a while and we should resurrect it once new graphql spec with alternative solutions comes out, it's not worth the schema change for now.