Vendure: Facets and Assets Channel Aware

[BeepLoveKarki]

Please make facets and assets channel aware. Needed for multivendor support.

[rohanrajpal]

This is something even we need at SevaShop. Probably after this feature, Vendure would be good enough for a lot of Multitenant use cases.

We first want to make the facets channel aware. How should we go about implementing this?

I did try to have a look at some commits that make customers channel aware
https://github.com/vendure-ecommerce/vendure/commit/0f7347336f1e107373202826b38cfceddb57b1b0

also had a look at some slack discussions

This is one of the hard things because it's such a complex thing and there are so many new considerations to handle up and down the codebase to deal with this correctly.  I myself would probably only discover 80% of the real pain points during implementation. What would probably be helpful to future efforts is if you document all of the parts that are challenging or overly complex. (edited) 

Links to some discussion (for future reference)

https://vendure-ecommerce.slack.com/archives/CKYMF0ZTJ/p1599156918038300
https://vendure-ecommerce.slack.com/archives/CKYMF0ZTJ/p1609732968204200
https://vendure-ecommerce.slack.com/archives/CKYMF0ZTJ/p1598783737011400
https://vendure-ecommerce.slack.com/archives/CKYMF0ZTJ/p1608026439009300

I do understand it's a tough thing to implement, but could you recommend some starting point or a blog/guide on how to get started? I'm confused about how to exactly get started on this

[michaelbromley]

I don't think I'd write a blog or guide on how to tackle this issue, since the work involved in writing a correct guide is similar to actually doing the work itself.

Off the top of my head, here are some considerations which need to be addressed by the implementation. Let's take just channel-aware assets for this discussion.

1. Implement the ChannelAware interface on Assets
2. Modify create and update service methods to also store the current channel
3. Implement "add to channel" and "remove from channel" mutations + resolvers & logic
4. When querying for entities which have Assets (Product, ProductVariant, Collection), ensure only Assets assigned to the current channel are returned
5. Any internal methods which return Assets must be checked and probably modified so that they take into account the current channel
6. What if a Product's featuredAsset is not available in the current channel? Should be be able to assign multiple featured Assets, one for each channel? If so, we need to re-architect the relation between Product.featuredAsset and Asset.
7. End-to-end tests for all of the above to ensure they work correctly.

For Facets, there are other additional issues to solve too:

1. Facets are often used as the basis of Collections, so now in our processing of CollectionFilters we need to be aware of whether the Facet is actually available in the current channel.
2. The search index used in the DefaultSearchPlugin and ElasticSearchPlugin stores facet info, so they will need to be modified to account for the channel that the facet belongs to.

If you want to attempt to solve all or some of this, you are welcome to. Just be aware that certain problems (like the "featuredAsset" issue) will require some discussion to make sure we all agree on the best solution.

Considerations re v1.0

I added this to the v1.0 milestone yesterday without thinking it though, but now that you made me enumerate all the changes needed, I don't think it is feasible! However, one possibility might be to at the very least define the DB relations (i.e. implement the ChannelAware interface on the Facet/Asset entities) before v1.0, which means that we _should_ be able to still work on the implementation post 1.0 without needing breaking changes which would then need to wait for v2.0.

[rohanrajpal]

I don't think I'd write a blog or guide on how to tackle this issue, since the work involved in writing a correct guide is similar to actually doing the work itself.

Off the top of my head, here are some considerations which need to be addressed by the implementation. Let's take just channel-aware assets for this discussion.

1. Implement the ChannelAware interface on Assets
2. Modify create and update service methods to also store the current channel
3. Implement "add to channel" and "remove from channel" mutations + resolvers & logic
4. When querying for entities which have Assets (Product, ProductVariant, Collection), ensure only Assets assigned to the current channel are returned
5. Any internal methods which return Assets must be checked and probably modified so that they take into account the current channel
6. What if a Product's featuredAsset is not available in the current channel? Should be be able to assign multiple featured Assets, one for each channel? If so, we need to re-architect the relation between Product.featuredAsset and Asset.
7. End-to-end tests for all of the above to ensure they work correctly.

For Facets, there are other additional issues to solve too:

1. Facets are often used as the basis of Collections, so now in our processing of CollectionFilters we need to be aware of whether the Facet is actually available in the current channel.
2. The search index used in the DefaultSearchPlugin and ElasticSearchPlugin stores facet info, so they will need to be modified to account for the channel that the facet belongs to.

If you want to attempt to solve all or some of this, you are welcome to. Just be aware that certain problems (like the "featuredAsset" issue) will require some discussion to make sure we all agree on the best solution.

Considerations re v1.0

I added this to the v1.0 milestone yesterday without thinking it though, but now that you made me enumerate all the changes needed, I don't think it is feasible! However, one possibility might be to at the very least define the DB relations (i.e. implement the ChannelAware interface on the Facet/Asset entities) before v1.0, which means that we _should_ be able to still work on the implementation post 1.0 without needing breaking changes which would then need to wait for v2.0.

Thanks a lot for the detailed reply! Perhaps I need to experiment/read much more about Vendure and its stack before diving into it. Right now does not seem the right time for me to work on it then, maybe sometime in the future.

[michaelbromley]

OK. Bear in mind that it _is_ possible to work around this limitation in your app. You can e.g. use custom fields on the Asset & Facet entities to store the ID of one or more channels. You could also create your own Admin UI list components to only list those with IDs matching the current channel. It would take a bit of work on both backend and front, but should be workable.

[rohanrajpal]

OK. Bear in mind that it _is_ possible to work around this limitation in your app. You can e.g. use custom fields on the Asset & Facet entities to store the ID of one or more channels. You could also create your own Admin UI list components to only list those with IDs matching the current channel. It would take a bit of work on both backend and front, but should be workable.

Yeahhh we are currently exploring such possibilities only. As we're just making something as a proof of concept, these workarounds seem to do the trick. Thanks.

[martijnvdbrug]

I have created a seperate issue for making Assets channel aware to keep things managable: https://github.com/vendure-ecommerce/vendure/issues/677

[michaelbromley]

I'm working on ChannelAware Facets now. Though there are some fairly complex implications with a full and complete handling (interaction between Products/Variants/Collections and Facets when they can exist in different Channels), I will first of all implement the most simple version, which will at least get the breaking DB changes out of the way. Complex edge cases than then be handled later.

[michaelbromley]

Now implemented for Facets, so I'm closing this issue as the Assets already has its own dedicated issue (#677)