Right way to altering search results and categories

Hello to all,
I don’t know if I’m writing in the right section, in case I’m wrong I ask you the courtesy to move the thread, thanks.

I have a question to ask the community:
I need to show in the listings and research only some products compatible with an address that the user will insert in a box on the homepage. What is the correct way to do this development?

Investigating a bit I found these links:

  1. First question: I understand that I need to create an extension on Vuestorefront API, is this the right way?
  2. My idea was to do the development like this:
  • Expose a Magento-side API that returns all salable products based on the user’s address that is passed to them.

  • Create a Processor as described above in the two links.

  • Intercept the category listing and search (they probably work the same, but I’m not sure) and delete the results that have a different product_id from those listed in the API response.

  • Display all products, except those that have been eliminated. If the count of products is zero, show the default component that is displayed when there are no products (maybe this part comes for free).

Is this the correct way? Are there better ways?


I also thought of another way, perhaps “cleaner”, but I still have some doubts about it:
The idea would be to modify the Magento 2 VSBridge Indexer module to report this information (an array containing the zip codes which these products can be shipped to) within the product index. At that point, however, I should just modify the search logic from VSF or VSF API on Elasticsearch of the products. Can you tell me which file would need to be modified (probably extended) to do this?

Which solution is the recommended one?

Thank you all,
Michael

Adding new field with zip codes to products in ES sounds more promising for me. Could you show me how query would look like? I wonder if it would be a scope query or rather equals.

Another thing you must know is that you won’t be able to use Redis Cache in PWA for these listings as they might be a different depending on user. Also, user’s token is stored in localStorage, so you can fetch it only client-side - no SSR for these listings.

Hi Fifciuu, thanks for the reply!

The development would consist of this:
As long as the visitor does not enter his address in the frontend (which through a Google API will be complete, from which we can therefore derive his postal code), he will see the listings and searches normally.

From the moment the user enters his address, we will have to derive his zip code, forward it to the API (VSF API) I suppose, and filter only for products that have that zip code, both within categories, and both within the search area.

  1. From what you told me the user token is stored only in localStorage, do you think it is feasible to forward it to VSF API?

In reality, the project deals with a marketplace: Magento has been modified to allow the registration of resellers. Each reseller can assign himself products as salable from the main catalog. Furthermore, he will be able to configure postal codes to which he will carry out the deliveries.
At this point the idea would be to extend and modify the magento2-vsbridge-indexer module to ensure that its dealers are set for each product and the zip codes in which it ships for each dealer.

  1. Does it all make sense up to here?

So, having done this, we should understand at what point to extend or modify (maybe it is a module of the core?) The logic for the display of the products, both in the categories and within the research.

  1. Should the change be made only on VSF, VSF API, or both? In which files or modules?

As for the fact that I will not be able to use redis I suspected it, in fact I think it will take an instance of ElasticSearch big enough to handle all the calls.

  1. Do you think it is sustainable? Or could the infrastructure costs be very high? I still don’t have the perception of how stressed elasticsearch is.

  2. Can you tell me exactly how to disable Redis cache? At the moment it is not working on my infrastructure, perhaps because I am using Redis 6, but I would still like to understand what are the steps to enable or disable it in the correct way (I would like to do an article with associated code on Gitlab in which I explain how to configure everything with Docker and AWS Fargate)

Thank you very much,
Michael

  1. Sure, but only from the client-side. It is impossible to access localStorage on the server. For that purpose, you would need to change storage from the localStorage to something shared between client & server - e.g. cookies.

  2. It makes sense. It is important to remember about difference between customer’s accounts and merchants accounts. Another thing, makes me wondering is, wouldn’t it be a better to develop own VSF Next integration for your case? Please consider it. Maybe there is no Magento integration for next nowadays. However, it is much more scalable than VSF1 and it will have a great close future.

  3. Yes, I am pretty sure it will require changes in both VSF & VSF-API. I cannot really say in which files. You have to analyze code of your version on your own. There will be changes to make in many places.

  4. Elasticsearch is pretty good at caching itself. However, we access Elasticsearch via Node.js app which might be a bottleneck. We prefer to use Redis and Nginx extension to server SSR Output/API Response directly from the Redis - omitting Node’s app.

  5. Simply in config of the both PWA & API set these 2 properties to the false:

"useOutputCacheTagging": false,
"useOutputCache": false,

Another thing worth to check is configuration of your magento2-vsbridge-indexer - make sure you disabled Redis purge cache there.

Please consider using VSF-Next (VSF2), I am pretty sure you would be much more satisfied in long-term perspective.