Questions about facets

[matish]

I am doing this in a separate Laravel project. Aimeos installation is not part of it. I am accessing Aimeos only over the API and customer sees this as a single request. Actual API requests are hidden from the customer.
I am assuming that PHP is making those requests one after another.
One solution, that I am thinking about: is to allow comma separated aggregations.

For example:

Code: Select all

/jsonapi/product?
include=attribute,media,price,product,product/property,text,catalog,supplier,stock,property,product/property/type,attribute/type
&filter[f_oneid][vendor][0]=15
&filter[f_oneid][vendor][1]=16
&aggregate=index.attribute.id,index.catalog.id,price:min,price:max

But that one requires code changes on the Aimeos end.

[matish]

Ok, I have played around with prices a bit.
I would say, that min price works, max price works, but range filter does not work.

Raw URL:

Code: Select all

https://aimeos.priit.yt.lan/jsonapi/product?include=attribute%2Cmedia%2Cprice%2Cproduct%2Cproduct%2Fproperty%2Ctext%2Ccatalog%2Csupplier%2Cstock%2Cproperty%2Cproduct%2Fproperty%2Ftype%2Cattribute%2Ftype&page%5Blimit%5D=6&page%5Boffset%5D=0&filter%5B%26%26%5D%5B0%5D%5B%3E%5D%5Bindex.price%3Avalue%28%22EUR%22%29%5D=1332&filter%5B%26%26%5D%5B0%5D%5B%3C%5D%5Bindex.price%3Avalue%28%22EUR%22%29%5D=1716

Decoded

Code: Select all

/jsonapi/product?include=attribute,media,price,product,product/property,text,catalog,supplier,stock,property,product/property/type,attribute/type
&page[limit]=6
&page[offset]=0
&filter[&&][0][>][index.price:value("EUR")]=1332
&filter[&&][0][<][index.price:value("EUR")]=1716

It should return products that are priced between 1332 and 1716 EUR, but it returns products that are visible on the picture:


Am I doing something wrong or is this a bug?

One solution, that I am thinking about: is to allow comma separated aggregations.

When I was working with aggregations today I discovered that when calculating price:min and price:max, then I should not pass the price filter for it. So it is good to keep those requests separate. But still, if comma separated aggregation would be possible, then I could reduce the number of requests needed.

[aimeos]

I am doing this in a separate Laravel project. Aimeos installation is not part of it. I am accessing Aimeos only over the API and customer sees this as a single request. Actual API requests are hidden from the customer.
I am assuming that PHP is making those requests one after another.

Your approach combines the worst of both worlds because you need several requests to get the data and you have to perform them all for every single request. If you don't execute the requests in parallel, you get an incredible slow frontend with lots of data transfered between the Aimeos API and your frontend server. We strongly recommend to take a different approach to avoid a bad user experience and a disappointed client.

One solution, that I am thinking about: is to allow comma separated aggregations.
For example:

Code: Select all

/jsonapi/product?
include=attribute,media,price,product,product/property,text,catalog,supplier,stock,property,product/property/type,attribute/type
&filter[f_oneid][vendor][0]=15
&filter[f_oneid][vendor][1]=16
&aggregate=index.attribute.id,index.catalog.id,price:min,price:max

Combining aggregations like this is not possible because the different data would be merged into a single array where you might not know which is included for what reason.

[aimeos]

Code: Select all

/jsonapi/product?include=attribute,media,price,product,product/property,text,catalog,supplier,stock,property,product/property/type,attribute/type
&page[limit]=6
&page[offset]=0
&filter[&&][0][>][index.price:value("EUR")]=1332
&filter[&&][0][<][index.price:value("EUR")]=1716

The filter part has wrong indexes and must be:

Code: Select all

&filter[&&][0][>][index.price:value("EUR")]=1332
&filter[&&][1][<][index.price:value("EUR")]=1716

[matish]

The filter part has wrong indexes and must be:

Thanks for the correction. I got it working now. Documentation is a big vague on the indexing. It is just saying '[]' but no specific numbers inside.

Your approach combines the worst of both worlds because you need several requests to get the data and you have to perform them all for every single request. If you don't execute the requests in parallel, you get an incredible slow frontend with lots of data transfered between the Aimeos API and your frontend server. We strongly recommend to take a different approach to avoid a bad user experience and a disappointed client.

Maybe you are right.
Well, I am not doing it for the client. I am doing it for myself, to see if there is a way to achieve results faster than with Magento. If I can, then maybe I will offer this solution to my clients.
For that specific component I need all that data anyway. Other components are already separated.
Now I am getting all that data within 572ms, which is about the same as the exact same thing on Magento after caching (hardware is exactly the same). Without cache Magento loads that component out in 1.2 seconds.
If you say that with parallelization I could improve that number further, then I will look into it later. My logic is, that those multiple requests should happen as close to the Aimeos API as possible (or even as close to the actual database).
There is another improvement too. On Magento it takes 130 requests to load that page. My implementation cuts the amount of requests by 90% and I have not yet done any optimization or minification. All of that with no loss in usability. I would even say that the usability is actually better.

Combining aggregations like this is not possible because the different data would be merged into a single array where you might not know which is included for what reason.

If we talk about combining aggregations, the at first glance I think they can be combined. Each returned result has "type" attribute. Based on that I can easily differentiate them.
Here is the picture:

[matish]

I am working with categories now and already I have a question.

Code: Select all

https://aimeos.priit.yt.lan/jsonapi/catalog?id=5&include=catalog%2Cmedia%2Ctext

Consider this picture as a response to the URL above:


I can clearly see that the category "Lenovo sülearvutid" has no children. But what about parents? On Magento there is a "path" column for the catalog_category_entity database table (example value: 0/2/5) from which I can easily locate the parents. Do you have something similar on the API too?
I need this information so I could build out the breadcrumbs.

On Aimeos default application breadcrumbs work as long as the customer is under category view, but once product view is opened, the breadcrumb does not work.
It did not work on default Magento 2 too, but I have fixed it for some customers and it has brought them more customers as a result of that.
Here is another picture that clarifies what I mean:

[aimeos]

The filter part has wrong indexes and must be:

Thanks for the correction. I got it working now. Documentation is a big vague on the indexing. It is just saying '[]' but no specific numbers inside.

Yes, because "[]" assigns a consecutive number automatically in PHP.

Your approach combines the worst of both worlds because you need several requests to get the data and you have to perform them all for every single request. If you don't execute the requests in parallel, you get an incredible slow frontend with lots of data transfered between the Aimeos API and your frontend server. We strongly recommend to take a different approach to avoid a bad user experience and a disappointed client.

Maybe you are right.
Well, I am not doing it for the client. I am doing it for myself, to see if there is a way to achieve results faster than with Magento. If I can, then maybe I will offer this solution to my clients.
For that specific component I need all that data anyway. Other components are already separated.
Now I am getting all that data within 572ms, which is about the same as the exact same thing on Magento after caching (hardware is exactly the same). Without cache Magento loads that component out in 1.2 seconds.
If you say that with parallelization I could improve that number further, then I will look into it later. My logic is, that those multiple requests should happen as close to the Aimeos API as possible (or even as close to the actual database).
There is another improvement too. On Magento it takes 130 requests to load that page. My implementation cuts the amount of requests by 90% and I have not yet done any optimization or minification. All of that with no loss in usability. I would even say that the usability is actually better.

Further optimization in your setup seems to be only possible by fetching the data from the JSON API in parallel. Normally, I would suggest to use the aggregation endpoints from Javascript code in the frontend but your domains for HTML and API are different, which would result in doubling the requests due to browser sending CORS pre-flight request for each real request. The only solution for that would be to "mount" the JSON API into the same domain as the HTML generating code.

Combining aggregations like this is not possible because the different data would be merged into a single array where you might not know which is included for what reason.

If we talk about combining aggregations, the at first glance I think they can be combined. Each returned result has "type" attribute. Based on that I can easily differentiate them.

From that persective, you may be right. The JSON:API spec says you can but you shouldn't do that.

[aimeos]

I can clearly see that the category "Lenovo sülearvutid" has no children. But what about parents? On Magento there is a "path" column for the catalog_category_entity database table (example value: 0/2/5) from which I can easily locate the parents. Do you have something similar on the API too?
I need this information so I could build out the breadcrumbs.

The parent categories are not available explicitely because
- Products can be assigned to multiple categories
- Aimeos doesn't have a "main" category
- Retrieving categries up to the root category can be costly

But you can display the current category by passing the category ID to the product detail view if you fetch the categories for the menu nevertheless. You only have to set the canonical URL correctly to avoid duplicate content.

[matish]

The parent categories are not available explicitely because
- Products can be assigned to multiple categories
- Aimeos doesn't have a "main" category
- Retrieving categries up to the root category can be costly

Thank you for your response. I had to make a bit of custom development because of that.
I did a procedure, that imports all categories and indexes them accordingly. Now I can retrieve all I need quickly. Response is still 0.550ms, so all is good.


Rendering this kind of category menu is really easy. Only the top level nodes are loaded initially and each subsequent sublevel content loading happens on "onmouseover once". This kind of approach should check all the boxes regarding to speed and minimum amount of data.
If there is no "main" category, then you can make a arbitrary root. It is just an extra database entry, nothing else.

If the same product can belong to multiple categories, then at the product view it is possible to render 2 separate breadcrumbs, each one indicating a separate path.
If only one breadcrumb is possible and it is not known where the user came in from, then I have rendered the breadcrumb which has the longest path.
Merchants definitely love breadcrumbs and they say, it is 21st century, time of AI, how are you saying that breadcrumbs are not possible?
They have a good reason too. Most of the customers find products from the advertisements. But it may be so that they do not like the initial product, maybe they want a different color of the same kind of product and if there is no breadcrumb, then this customer will most likely leave with no purchase, since there are trillion items in the shop and this will just confuse the customer. Especially if the merchant has not invested enough to make the search good enough to be actually useful. Good breadcrumbs are always cheaper to implement than a good search.

Playing around categories revealed that Aimeos category rendering is different from my expectations.
First of all, there is no way to access "Second home" category over the API.
Initial starting point:

Code: Select all

https://aimeos.priit.yt.lan/jsonapi/catalog?include=catalog%2Cmedia%2Ctext

Secondly, categories deeper than level 4 are never loaded. (Over the API I managed to get all levels, except for the "Second home" category)
And thirdly, if there is a product available in subcategory (like T2-2-1) and customer is viewing its direct parent (like T2-2) then this product is not findable in it. On Magento this behaviour is different via "is_anchor" attribute.
Picture:


For now you can consider those findings as information. Those things do not affect my development, except for the third issue, that affects category view implementation when certain category is chosen. I guess one way is to supply ID-s of all subcategories with OR condition, but I may need to index that separately.